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).
