5 ms·
> Also, you want to render each ray/vertical screen line one at a time, rather than running each single step of the ray for all rays/vertical lines. This may r
by ant6n 6y ago
> Also, you want to render each ray/vertical screen line one at a time, rather than running each single step of the ray for all rays/vertical lines.
This may require more performance. Remember, this algorithm was used for an early Nineties game.
The advantage of drawing along a line of same-distance (i.e. constant z) is that per pixel, there are no divisions, only additions and one multiplication (which could perhaps be optimized away?). Drawing vertical screen lines, you get the z-division for each step.
(Then again, perhaps the division could be removed with a look-up-table)
- Jare 6y agoI wrote the code for this in late 1993 https://www.youtube.com/watch?v=9KoUyFhddIs&t=102 https://www.youtube.com/watch?v=9KoUyFhddIs&t=102 . You can find the C + assembly source code in https://archive.scene.org/mirrors/hornet/code/effects/land/ign_land.zip https://archive.scene.org/mirrors/hornet/code/effects/land/i... Yep, we used a lookup table with built-in levels of detail. Since rays always sample the terrain at the same Z distances from the camera, the lookup was trivial. Rendering vertical lines had additional benefits back then, including faster use of paged VGA video modes and, as described, doing circular projection to avoid deformations on the sides of the screen.
- ant6n 6y agoInteresting. It looks very nice! I could imagine mixing in "normal" polygons with this approach may not be trivial, though. I couldn`t find much information about this circular projection online, some napkin-math tells me that straight lines in world-space don't project into straight lines in screen-space. just drawing a triangle is not trivial.