Commander X16

Another thing I was thinking about was the Wolf3D textures.  The originals are 64 x 64 bitmaps.  I just imported that PNG into Paint, resized it horizontally by 50% and then resized again by 200% and saved as a 256 color bitmap, attached.  Now the images are all still 64 x 64 but every second column is identical. and this can be resized horizontally to give 32 x 64 images (the second attached image), doubling the number of textures that can be stored in VERA at one time.

edited to add: tried again squashing the images vertically instead, and it looks better (wolf3dwalls3.bmp)

one more: tried again in IrfanView, which resized and resampled using better methods than Paint.  wolf3dwalls5 is squashed vertically by 50%, and 5a is the same file stretched back out to 64 pixels per image again to give a comparison to the original images.  So, the drawing routines could be smaller (LDA a maximum of 32 times for a wall column rather than 64, plus one LDA for the ceiling and another for the floor, and only 128 STA instructions if Vscale is $22) and hence faster.

wolf3dwalls.bmp wolf3dwalls2.bmp

wolf3dwalls3.bmp

wolf3dwalls5.bmp wolf3dwalls5a.bmp

OK, tried once again with IrfanView, but this time I decreased the color depth to 256 colors first and then did the resizing.  wolf3dwalls6 is squashed vertically to 32 pixels high per texture, and 6a is the same image with every row of pixels doubled.  There's not much difference visually between the original image and 6a.

 

Edit: oops. That didn't work any better nevermind.

wolf3dwalls6.bmp wolf3dwalls6a.bmp

OK, I think this is the best one yet, the wolf3d textures at half height in 256 colors.  Using these would increase the speed and double the number of textures stored in VERA at once, at the expense of making everything kinda blurry in the y axis.


wolf3dwallsA2.bmp

Hi Jeffrey. This is impressive and congratulations on your achievement. It must have been quite a ride for you to achieve this result. Kudos!

I have nothing to add to this ?, I am just here to say it is very impressive what you achieved so far and I am looking forward to more progress.

On 3/17/2021 at 3:23 PM, ZeroByte said:

It's a shame that OPL and OPM are totally different animals, otherwise the AdLib sound is also right there for the playing, too. I DL'd the Wolf3d source to look into that possibility, but haven't come up with any ideas for how to convert between the two on the fly.

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 ? 

11 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 ? 

I didn't get all that deep into it but I did get to where I was reading some portion - I can't recall whether it was the high-level calls from the main loop, or the low-level stuff that actually wrote data to the chip - lol. I am actually interested in digging deeper on that front. I've done some research on OPL, and the good news is that it's probably easier to translate OPL -> OPM than going the other way, because OPL was only a 2-operator synth while the OPM has 4 - but the OPL has more voices, and can work in a mode where many of them are drums - don't know which way Wolf3d worked, but I'm thinking they probably used the 9-voice mode because there wasn't a lot of percussion in the music as I recall, and they also used FM voices for SFX in addition to music.

I suspect that the SFX data files themselves live in the game's MAP files or other data files - they're obviously not going to be in the source.  So I just downloaded the shareware installer and am about to go take a gander.

Interstingly enough for the record, the stated system requirements for Wolf3d are 286/12 with 570K RAM

I don't really know how to use it, but have you thought about using the floating point library in the kernel to do multiply with fraction part? It's possible it might be faster than your implementation.  Although it might involve costly conversions which would balance it out anyway... (I honestly have no idea, I haven't done any research into it, just throwing it out there).

1 hour ago, Ender said:

I don't really know how to use it, but have you thought about using the floating point library in the kernel to do multiply with fraction part? It's possible it might be faster than your implementation.  Although it might involve costly conversions which would balance it out anyway... (I honestly have no idea, I haven't done any research into it, just throwing it out there).

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.

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 ?