3 ms·
For floors the perspective divide is once per row, just like for walls it's once per column. The BSP may have led to some floor subdivisions, especially as it
by Jare 4mo ago
For floors the perspective divide is once per row, just like for walls it's once per column.
The BSP may have led to some floor subdivisions, especially as it needs convex sectors. I don't remember if the engine would coalesce adjacent floor spans into a single one, but I hope it did.
- torginus 4mo agoThat would only be true if a row (by which I mean a scanline) would be equidistant in view-space depth across its whole length, which is not quite true. While a column of pixels for a wall is (as long as you dont tilt the camera).
- tadfisher 4mo agoThe code exists! https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.10/r_plane.c#L107-L178 https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.... And it looks to me like we are mapping each row with a constant y, calculating the "distance" (thus scale factor) only once using just the vertical slope for the row.
- torginus 4mo agoYeah sorry, you are right - I got it mixed up.
- Jare 4mo agoFor the record, there were constant-Z full 3D engines in the late 90s, which would find the correct axes on screen to render perspective-correct textured triangles using oblique spans of pixels. They were incredibly complicated and prone to holes at the slightest numerical accuracy, but they were a sight to behold. Constant-Z meant not just saving on perspective divides, but also easy Z-buffer and depth-based fog.