|
Post by ghost gauze on Oct 31, 2018 23:18:34 GMT -5
great! A binary available? Thanks the binary only runs on VecFever, if you have one mail Thomas.
|
|
|
Post by Rapetou33 on Nov 2, 2018 7:40:49 GMT -5
thanks GG!
|
|
|
Post by gtoal on Nov 14, 2018 18:05:08 GMT -5
great! A binary available? Thanks Just to reiterate, this is an ARM binary that runs on the VecFever. And until Thomas adds the feature to the VecFever that allows arm binaries to be loaded on demand, there's no point in releasing the ARM binary as no-one would be able to run it. in the meantime, vecfever owners can get an updated firmware from Thomas that has tailgunner built in. As a heads up... the way this works is that the ARM does all the game calculations and the 6809 does the display from vector data sent from the ARM. With tailgunner, that is primarily just simple vectors although there are a couple of higher-level display procedures implemented where whole objects can be drawn by the 6809, such as the shield pattern. You can expect in the future that more and more support for arcade roms might migrate to the 6809 side, especially for Atari games where a lot of the work was being done by the Atari Vector Generator which was effectively an independent graphics processor. G
|
|
|
Post by gtoal on Jul 16, 2019 21:41:34 GMT -5
It's time for another update in the Tailgunner saga: some time back I listed several alternative ways I might implement a Tailgunner cartridge - one of the suggestions hasn't been covered here but it did spin off another thread elsewhere... which was to design a cartridge which halts the 6809 CPU and uses an ARM in the cartridge to drive the Vectrex's VIA as if it were its own peripheral... well, with help from ComputerNerdKev, Pelrun, and now Malban (names I'm sure you'll recognise) we now have a cartridge called the "PiTrex" that interfaces a Raspberry Pi Zero to the Vectrex. And as of today, the PiTrex runs Tailgunner! (Thanks, Malban!) There's still some work to be done but at this point we know we have working hardware, and software that will definitely work! And most importantly, it's hardware that we can and will build in quantity: Graham
|
|
|
Post by gtoal on Oct 12, 2019 20:10:31 GMT -5
just in case I lose these links, I'll use proboards as a cloud bookmark manager ;-) www.helixsoft.nl/articles/circle/sincos.htmcoderwall.com/p/fukypa/minsky-s-circle-algorithm-in-shoes-rb-hackety-hackI can't help but think there is something slick still to be done combining minsky's code for generating a circle (ie an approximation to sin/cos that is stable over many iterations) and the polar graphics code in sincos above, with Margolin's "magic angles". I.e. some sort of 3D animation using extremely cheap operations. Especially if it can all be done in mostly 8-bit code with 16-bit products at most, coupled with 8-bit tricks such as constant division by multiplication that we were talking about in another thread this week.
|
|
|
Post by kokovec on Oct 15, 2019 12:13:07 GMT -5
I wonder if Bresenham's circle algorithm would be efficient enough in this case.
|
|
|
Post by gtoal on Oct 20, 2019 10:37:06 GMT -5
I wonder if Bresenham's circle algorithm would be efficient enough in this case. It's awkward to do a full circle incrementally with Bresenham's - the original algorithm used a lot of symmetry and I'm not sure that you could modify it to move past the X > Y segment (1/8 of the circle) without storing all the values for the first 45 degrees. The iterative part of the implementations I've seen all start on the X or Y axis and end at the 45 degree diagonals. On the other hand, Minsky's is not a true circle, it's an ellipse. On the other other hand, sometimes an ellipse is what you want :-) Also it may be possible to convert an ellipse back to a circle by shearing, as long as it can be done without an expensive divide... G
|
|