46 minutes ago, Jeffrey said:
The ray direction is simply an index: for every possible angle I have an index. This is used for lookup in sine, cosine, tan and invtan tables.
The ray starting position is a 16 bit position (tile pos + pos in tile).
And i use the same kind of variables like Wolf3D for stepping/intercepting. So that part is pretty similar I think. But my 286 is also very rusty ? I used the video to inform me about how Id did it and figured out a way to implement on the 6502/X16/Vera.
OK. How many possible directions can the player face? If it's only 16, you could have 16 sets of lookup tables for a bunch of variables, one set of lookups for each variable, and just look up values rather than looking up sin, cos etc and multiplying. If you could just look up the xtilestep etc. for each direction and pixel column you'd be able to save a ton of time.
I mentioned before using Hscale and Vscale to give yourself a 256x128 main display. That's the same aspect ratio as the 304x152 original - it occurs to me that they were probably using a screen with a 16:9 aspect ratio and used the bottom 1/9 of the screen for the health bar etc. With a 256 "pixel" wide and 192 "pixel" high screen (Hxcale and Vscale both $33) a two byte variable could be stored on one bank of RAM: 16 tables of 256 (one for each direction and pixel column) bytes for the low byte of the variable, another 16x256 bytes for the high byte of the variable. So if you had four such variables (perhaps xpartialup, xpartialdown, ypartialup, ypartialdown? I need to look at the code more), you'd need four banks of RAM to store the lookups and could avoid a bunch of multiplication.