wolf3d

Yes, I played it at the time on both a 286 and a 386. You might be right, although you're describing an algorithm more like what Duke3d used rather than raycasting in that case. I was talking purely about raycasting. So it sounds like a misunderstanding on my part. It's true that Carmack has said several times, including in the readme to the source release of Wolf3d [0], that a BSP-based renderer might be faster than raycasting. He used a BSP tree based renderer for the SNES port of Wolf3d because the CPU was even slower, so I suppose that answers it! There's also a note in the GEBB page 164 from Carmack where he says it was slower than "looping through a few long wall segments". [1] Early alpha versions of DOOM used a sector-based rendering technique, maybe like what you're describing, which ultimately was too slow [2]][3]. Then Carmack

(equivalent C file: https://github.com/id-Software/wolf3d/blob/master/WOLFSRC/WL... ) > Was this translated automatically from C? I'll note that when I convert code between languages, I often go out of my way to minimize on-the-fly refactoring, instead relying on a much more mechanical, 1:1 style. The result might not be idiomatic in the target language, but the bugs tend to be a bit fewer and shallower, and it assists with debugging the unfamiliar code when there are bugs - careful side-by-side comparison will make the mistakes clear even when I don't actually yet grok what the code is doing. That's not to say that the code should be left in such a state permanently, but I'll note there's significantly more changes in function structure than I'd personally put into an initial C-to-Rust rewrite. The author of this rewrite appears to be t