nathanielbabiak 2021-12-20 11:44 (Edited)
I had mentioned on my racing upload here that I wasn't proud of the 3D polygon code. It uses my sprite expansion library to display the polys, and the frame update code is just so ugly and slow! (It's really tough to clear polys at stale locations.) So, a few polys are shown in one of the preview screen shots, but I never actually uploaded the code itself.
Anyway, as I woke up this morning, I realized there's a much better way to structure the sprite expansion library. The array used within the raster subprogram can be replaced with a RAM buffer. It's not a huge change to the library, but it'll run a few pct faster for drawing instructions, and a bunch faster for the instruction that clears the screen.
The important benefit of the change isn't as easy to describe, but it allows for
double triple buffering! (Edit 2021-12-21: I should mention page-flipping works too - that's why I was so excited - it's finally possible.)
With the super-chip-8 stuff finished, I had planned to return to the racing upload and polish it off... However, with actual
double triple buffering, I finally have enough libraries developed for:
... wait for it ...
The 3D racing upload here requires any 3D object to be aligned at a right-angle to the camera, and requires the camera to be aligned parallel to the road directly beneath it. The 3D maze uploads here and here require any 3D object to be aligned at a right-angle to the floor, and require the camera to be aligned parallel to the floor.
These early uploads were 2.5D, not truly 3D. It's a bit faster for retro hardware, and discussed here if anybody wants to read about it.
The next upload I'm planning is truly 3D, meaning six-axis degree-of-freedom. There's enough speed in the system for
eight 24 colors of polygons, a planar (flat) ground with checkerboard pattern fading out into the horizon, and even a skybox!
It'll be here around February. More to come!
McPepic 2021-12-20 19:08
Super exciting! I’m always blown away by the programs you make and am confident that this new one is no exception. Keep up the good work!
nathanielbabiak 2021-12-22 02:19 (Edited)
Also, as I work through the details of the
double-buffer triple-buffer page-flip implementation, I realized two MAJOR things:
It'll work with the 3D maze upload
s (the earlier one), even though it uses an entirely different display system. (It'll work with any of the raster scanline display systems I've developed.) It's pretty cheap too, it only costs 2% CPU to modify the raster interrupt (2 clock cycles), and it means I can finally eliminate screen tearing from the 3D maze!
I've discovered a new optimization for raster display systems. (I verified it hasn't appeared in any uploads by anybody else before, even!) It's only optimal in displays showing 121 or fewer raster scanlines per frame, although the specific raster scanlines can be updated at any time (meaning it's not applicable to the 3D maze uploads, which run full-screen, 128 raster scanlines every frame). With this optimization enabled, the raster interrupt CPU usage is significantly reduced! And it only adds a single clock cycle to the raster interrupt.
With these two things figured-out, my CPU budget calculations indicate it's possible to update 10 polygons at once, at 20 to 30 fps (it's great they'll be drawn to a buffer, so the user won't see partially updated screen data). I finally have a real poly-count!!! I don't have a proof-of-concept .nx file I can upload yet, just some math in Excel. It's going to take the better part of a month to work out the structure and syntax, but the math says it'll work.
More to come!