I was going to let this bake for a while more, but I want to get this in under the wire.
POINT ONE: Doom (1993) is not a raycaster.
Doom isn’t a raycaster because it doesn’t cast rays. To render a wall, it will go to the nearest visible wall according to the BSP tree, calculate where the endpoints (vertices) are in screen space by their angle to the player, subtract their vertex position from the player position to get each endpoint’s distance to the player, use the inverse distance to get the height of the wall endpoints and draw them at their screen space x coordinates, then linearly interpolate between the tops of the wall, getting the slope of the line connecting the two tops, and use this slope to draw all columns in between at the correct heights. It would then go to the next closest wall according to the BSP tree and repeat etc... One caveat is that the walls would be clipped against an occlusion array before being drawn, so there was no overdraw. At no point does Doom ever cast a ray to figure out column height or to determine visible surfaces like Wolfenstein did. Instead Doom used BSP Trees to solve the VSD (Visible Surface Determination) problem. The Doom engine is actually a much more efficient engine than a raycaster like Wolfenstein 3D, which was why an early version of it was used to make the SNES port of Wolfenstein.
POINT 2: Doom (1993) isn’t 3D either.
Doom is not 3D because it has no 3D representation, polygonal or otherwise. The level data is represented in a 2D map consisting of sectors. Each sector and its metadata (wall height, visplanes, etc…) is put through the above BSP algorithm to achieve a 3D look in screen space. This way the cpu only has to consider math in 2D and not 3D. I.e. GL(2) not GL(3). This is at the core of what makes it only “2.5D.”
I hope this helps with some people’s understanding of the Doom engine. Thanks for reading.
Primary Source: r_segs.c in the Doom Source code.
Log in to comment