New demo uploaded: Wolfenstein 3D - raycasting demo with textures

[kelli217]

16 minutes ago, Jeffrey said:

Thanks for the idea. ?



I'm pretty sure though that doing floating point math on a 6502 CPU (for this purpose) is slower than doing fixed point processing. The 6502 is not well optimized for doing floating point math.



Floating point numbers are (in general) probably easier to deal with, since handling fixed point 8 or 16 bit numbers means a lot off fiddling to make everything fit and not "break". Floating point numbers have a real advantage when it comes to conveniency. And if the CPU (or GPU) is hardware-optimized for it, its most definitely the better solution.

Maybe a minifloat would work? ?

[ZeroByte]

21 hours ago, Jeffrey said:

Where did you find the originel sound files? Do hou have and tips to rest about these kinds of FM systems/chips? I sound probably use some help on the sound/music front ? 

Well, after spending hours reading the sources, I didn't make a hell of a lot of progress because everything's so abstracted - there's a memory manager and a file cacheing engine and it's hard to get down to the nitty gritty of what exactly the header format is and what exactly the music format is. They also seem to have migrated to a music system called MUSE because several routines are #ifdef'd out of the build.

So a little while ago, I decided that the modding community has obviously cracked that nut decades ago, so why not approach from that angle? The music is stored in a format called IMF (Id sure did have a big ego - heh) and from what I've learned thus far, it's essentially a conversion of MIDI but sounds a lot like VGM. I found a file with the actual IMF tracks ripped as individual files, so I think I'm going to spend some time playing around with those and see if I can make something vaguely resembling the music come out of the emu with some boostrapped translation routines. If I get anything cool, I'll post to the forums.

[Ed Minchau]

7 hours ago, Jeffrey said:

Short update



The latest release (version 1.2.0) ran at 5 fps.



My local version now runs at 7.5 fps ?? Around a 50% gain in speed.



I'm currently optimizing the dda-algorithm. So far I did two things:

• 
  Using zero page addresses for pretty much all my variables (10% gain) 
  


• 
  Now I use fast multipliers that use "square" tables: https://codebase64.org/doku.php?id=base:seriously_fast_multiplication (40% gain)
  

Still more speed to be gained ?

Just curious, what sort of math are you doing?IIRC Id used some sort of 2 byte fixed point notation. 

[Jeffrey]

27 minutes ago, Ed Minchau said:

Just curious, what sort of math are you doing?IIRC Id used some sort of 2 byte fixed point notation. 

I essentially use 2 byte fixed notation. I use one byte for the tile position and one byte for the position within a tile.

For multiplication of a 8-bit fraction (like sine and cosine) and a 16-position (tile + position within it) I temporarily extend to 24 bits and keep only the highest 16 bits. All unsigned numbers.

In order to prevent negative numbers as much as possible I normalize every ray direction as if it was within the frist 90 degrees. I currently have 4 maps in memory to accomodate for that. 

From what I understand from the video mentioned earlier Id used 2 bytes for both the tile position and the position within the tile (so double what I use).  But the precision I get seems enough for now. ?

 

[Ed Minchau]

20 minutes ago, Jeffrey said:

I essentially use 2 byte fixed notation. I use one byte for the tile position and one byte for the position within a tile.



For multiplication of a 8-bit fraction (like sine and cosine) and a 16-position (tile + position within it) I temporarily extend to 24 bits and keep only the highest 16 bits. All unsigned numbers.



In order to prevent negative numbers as much as possible I normalize every ray direction as if it was within the frist 90 degrees. I currently have 4 maps in memory to accomodate for that. 



From what I understand from the video mentioned earlier Id used 2 bytes for both the tile position and the position within the tile (so double what I use).  But the precision I get seems enough for now. ?



 

Ok, makes sense.  So what does a ray look like in this notation?  I'm looking at this right now:

https://github.com/id-Software/wolf3d/blob/master/WOLFSRC/WL_DR_A.ASM

and wondering how you're representing variables such as xintercept, yintercept, xtilestep, ytilestep, etc.  My 286 assembly is a little rusty but I've seen a few videos about their technique and I think I get the gist of their code.  Depending on how you're representing those variables I might have some speedups.

[Jeffrey]

11 minutes ago, Ed Minchau said:

Ok, makes sense.  So what does a ray look like in this notation?  I'm looking at this right now:



https://github.com/id-Software/wolf3d/blob/master/WOLFSRC/WL_DR_A.ASM



and wondering how you're representing variables such as xintercept, yintercept, xtilestep, ytilestep, etc.  My 286 assembly is a little rusty but I've seen a few videos about their technique and I think I get the gist of their code.  Depending on how you're representing those variables I might have some speedups.

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.

[Ed Minchau]

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.

[Jeffrey]

52 minutes ago, Ed Minchau said:

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.

There are 304 ray directions in a single screen. The FOV is 60 degrees. So there are 6*304 possible ray directions. For tan and invtan i use tables the size of a quarter of that.

I will have to look into their code in more detail to figure out what they do exactly regarding the resolution/angles/aspect ratios etc.

Edit: when looking at their code it seems  they use 3600 possible "fine" directions (for their tan-table lookup). Which is about double what I use.

[Ed Minchau]

9 hours ago, Jeffrey said:

There are 304 ray directions in a single screen. The FOV is 60 degrees. So there are 6*304 possible ray directions. For tan and invtan i use tables the size of a quarter of that.



I will have to look into their code in more detail to figure out what they do exactly regarding the resolution/angles/aspect ratios etc.



Edit: when looking at their code it seems  they use 3600 possible "fine" directions (for their tan-table lookup). Which is about double what I use.

I'm not being clear. Can the player be pointing in any of those 3600 directions? Or is he limited to 16 (ie N, NNE, NE, ENE, E, etc)? Because if it's the latter, you can avoid doing a bunch of multiplications by looking up variables (indexed by player direction and pixel column) rather than calculating them each time. 

[Ed Minchau]

Another alternative if the above won't work for you: as long as the player doesn't turn, the xstepsize/ystepsize for every column of pixels will stay the same from one frame of image to the next, so you can save these variables in an array and only recalculate them if the player turns.