Voxel Space[1] could have used this, would that multicore had been prevalent at the time. I recall being fascinated that simply facing the camera north or south would knock off 2fps from an already slow frame rate.
Many of our maps' routes would be laid out in a predominately east or west-facing track to max out our staying within cache lines as we marched our rays up the screen.
So, we needed as much main memory bandwidth as we could get. I remember experimenting with cache line warming to try to keep the memory controllers saturated with work with measurable success. But it would have been difficult in Voxel Space to predict which lines to warm (and when), so nothing came of it.
Tailslayer would have given us an edge by just splitting up the scene with multiprocessing and with a lot more RAM usage and without any other code. Alas, hardware like that was like 15 years in the future. Le sigh.
>Many of our maps' routes would be laid out in a predominately east or west-facing track
That's fascinating to find out! I grew up a fan of Nova Logic, so I'll have to pay attention to this the next time I revisit their games.
Was this done for Comanche or did you also do this for Delta Force?
Delta Force's programmer was really boss (Daniele Gaetano), a physics guy turned coder if I remember correctly. He rewrote Voxel Space to be true'ish 3D and not fakey 2.5D. He explained the innovative backtracking he had to do on the ray caster to make that work, implemented mipmaps in the voxels, very very clever guy. One of the friendlier guys I've known in videogames.
I did the first version of the matchmaking for the network play in Delta Force but didn't make it into the credits because I quit before it shipped. My psycho coworker built a custom web browser(!) that integrated directly with my from-scratch matchmaking server. At least they let me work in C for that project; most everything else I had to do for them was assembler because that was not a "sissy" programming language. That server code was by-far the coolest thing I wrote for many years afterward.
Unfortunately, my server code couldn't handle more than like 32 concurrents because the Windows NT 3.0 kernel would BSOD with more. My (extremely grumpy) manager and the Sega Saturn coder called me a few days after I had quit to ask how the code worked. I suspect I left data in the socket buffers too long (was trying to batch up my message broadcasting work at regular intervals) and the kernel panicked over that.
I recall learning later the TCP/IP stack was homegrown in NT by Microsoft at that time and they licensed a good one for later versions, so I can't be blamed, it wasn't me! :D
I was just the lowly build-master/installer/utility developer, but I got tapped for testing and debugging and performance because I was just a sponge for coding knowledge because I wanted to be a game developer so baaaad at the time. I didn't get to do any of the game coding, and my experiments were just fruits of conversations with benevolent sages.
The reason facing east-west (or was it north-south, now I'm unsure) made such a difference in framerate was the color and height maps were ray marched in straight lines up from the bottom of the screen to the horizon. This meant you were zipping through the color map in straight lines, wrapping around to the other side if the ray went far enough.
When those straight lines lined up with the color and height map (north-south), life was good (and when a ray marched up a sheer canyon wall, life was VERY good.) But, when those straight lines went perpendicular (east-west) to the color and height map, you were blowing through the L2 cache constantly and going to main memory very often. I imagine on modern hardware these cache misses wouldn't amount to much measurable time, but on a 386dx with 8megs of RAM, the impact was very clear.
Novalogic was the only programming job I ever had where I got my own office with a door. ;) When I was with them, they had a policy of one game developer per game which I never saw again. Maximum cowboy coder energy, good times.