Do you like my hacking? If so, please consider leaving something in the
Fediverse (Mastodon etc): @Sprite_tm@social. spritesmods.com
While Bad Apple looks nice and is something no Vectrex has done before, it only exploits the fact that the cartridge has a lot of flash: except for maybe fetching data every now and then, it does nothing special. How can I show the power of this beast, in a way that befits the Vectrex?
Pretty simple: do something with 3d. Why not try to port Doom to it?
The Vectrex itself has a few demos and games that already do 3d, so it's perfectly well possible to do that, even without a special cart with a processor on it. The models they use always have been simple, and more important, they've always been wireframe in the sense that you can look straight through it: I know of no example of a 3d object actively obscuring another object on a Vectrex cart. That's because drawing solids is hard: you either need a lot of math or some memory where you can put a Z-buffer in.
Doom renders its levels from front
(near the camera) to back (away from the camera), and the way the levels are stored makes it easy for
me to fo the same. That, again, makes a Z-buffer-like approach feasible. I do this by defining
a 256x256 1-bit Z-buffer that overlays my screen. As soon as I draw a face of an object, I set
every bit in the Z-buffer it overlaps to 1. Now, if I draw later faces, I can clip the lines at
the places where the Z-buffer has 1. For example:
Here, I've drawn the front 3 faces of the first cube and marked them in the Z-buffer (the 'pixels' of the Z-buffer are red). When I now draw the faces of the second cube, I make sure to clip the lines where the Z-buffer is marked. This neatly obscures the part of the second cube that's behind the first one. It's not perfect and has some small artifacts sometimes, but it's quick and not too complex.
With this technique, I built a small bit of C that runs on the STM32F411 and can render Doom levels and convert the result to a list of 2D lines. I can then write those lines into cartridge space and signal the Vectrex a new frame is ready. The Vectrex will then render the lines, read the joystick and pass the data from that back to the cartridge, which then can render another frame. The end result looks pretty good, and the people who've played the original Doom can probably easily recognize E1L1 of Doom1 in what you see. Excuse the flickering, that's mostly because of the interaction of the framerates between the Vectrex and the camera.
And to crush your hopes: As cool as this looks, don't expect a fully-functional version of Doom on the Vectrex any time soon. The 3d engine works but is still somewhat buggy (especially when doing motion clipping) and Doom is a lot more than just the 3d engine: it also has level mechanics, enemy AI, weapon logic etc and that's all not implemented in my code.