MaxCoderz

Three years later I decided to spend a weekend working on a little 3D engine for the TI-83+.
This project lives on in name, anyhow! I'm not sure whether I'll do much more on it; it uses a simple BSP tree structure to sort the geometry for rendering. More information and a download of the binary can be found on my website.

(This project is still officially discontinued, but I thought I'd check if anyone was paying attention to MaxCoderz any more).

Ah so there is still life here...you guys are about as active as RS ha. Looks good though Ben.

Heh, cheers. Someone has to log in to delete the spam bot accounts, after all.

WOW!

Thats fantastic Ben. I was thinking about this project the other day for some reason (in particular the one with the scrolling background) and here we go, you've worked on it! .

Thank you, tr1p1ea! I'm glad to see you're still with us.

I once had a good PDF that described DOOM-style rendering, with a particularly interesting bit on a good way to handle multiple-height sectors and how to efficiently render them (including the floor or ceiling between them). I haven't been able to find it again, though, and my experiments haven't ended up working very well. I wish I could find it! Unfortunately, work has not left me much time to do any more work on this (a recurring trend, I fear).

I found the PDF - A Brief Summary of DOOM-style Rendering by Robert Forsman and Bernd Kreimeier. Leafing through it gave me a few nudges in the right direction, and the engine now has limited support for variable-height floors and ceilings.
More information and downloads for the TI-83+ and TI-83 can be found, as before, in my journal.

Wow Ben, that looks great! Good to see you're still z80 coding

Thanks, I'm sure you'd be able to write a much faster engine but it's been a fun learning experience for me.

  One of the above screenshots is from DOOM, the other is from Nostromo (I'm not telling you which is which). More information about the changes and a new demo binary can be found on my website.

Ha ha ha Ben I cracked up at that.

I'll have to check out the new binary. I didn't see you got the variable height working. Very cool man.

Hehe, thank you. I've been doing some heavy optimisation work over the weekend and managed to boost the performance when looking at the stairs on the TI-83+ to the target 10 FPS (from 6 FPS). It certainly feels a lot smoother, in any case. The engine also only needs 3 clipping buffers instead of 5 (saving 512 bytes of RAM) and moved all temporary buffers (clipping buffers and transformed vertices) to dynamically-allocated RAM rather than baking them into the binary. The result was a binary that had a lot more useful code in it but was much smaller than the previous version!

I've since slowed the engine down considerably and inflated its size by adding "Things" (objects represented with sprites):
The 14 FPS is when running at 15MHz. The sprite is supposed to be a lamp (based on a similar sprite in DOOM). There's currently a limitation of one Thing per subsector (they are drawn back-to-front in order of subsector, so if there are multiple Things in a subsector these also need to be sorted from back-to-front before rendering). The sprite rendering code is also very clumsy, having a habit of exploding and drawing nonsense when you get very near to the sprite (when the projected width or height is greater than 128 pixels) and not stretching the sprite especially smoothly (it sometimes goes a little too far underneath the sprite, drawing junk pixels). These things need fixing.

More pressingly, if you stand in one particular spot in the above level and look in one particular direction one of the far walls is drawn incorrectly; if you imagine the lines connecting the top and bottom edges of a wall usually looking like an equals sign '=' then this seems to be flipping the top and bottom coordinates on one end, looking like an 'X'. I'm not sure why this is or where the bug can have come from; I only noticed it when running at 15MHz, presumably because the higher frame rate means finer movement and so you're more likely to hit the problem spot (whereas at 6MHz you tend to move much further each frame).

I've written a fairly rough description of how I'm handling occlusion (clipping of geometry so you can't see through walls) and how that has been expanded to support sprites in my latest journal post. I also fixed the mysteriously flipping wall (a careless 32-bit to 24-bit integer truncation) and the ugly sprite scaling. There is a new demo which uses a larger two-room map - the 6MHz TI-83 and TI-83+ struggle with it a bit, I'm afraid, so for those with more advanced calculators don't forget to hit Zoom to switch to 15MHz (I hope to get it running fairly smoothly on a 6MHz calculator as that's all I own myself).
The above image is a link to an animated screenshot.

I ran the demo on my TI-84+SE, nice work! I can't use it in 15MHz though, because there is not a sufficient delay when updating the LCD. The display becomes completely garbled.

Whoops, sorry about that, I'm using the code for ionFastCopy. I'll replace it with something a little more robust!

i've always wondered about occlusion in 3d. i'll have to check back in a couple of years when your source is cleaner and i can actually understand it.
nice work, ben