| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Now, outside of sprites, every pixel on the screen is draw at most
once. Hoorah. Unfortunately things still seem to be a little slow,
perhaps its the z_buffer access or the fact that vertical floor slice
drawing is bad?
|
|
But it's very inefficient right now
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
For whatever reason, we /can/ compensate for the TERRIBLE linear
interpolation hacks on direction (and so distance) computations for
the walls and floors. We do this by scaling the otherwise exact and
correct computations for the perp_distance and centre of an object by
the magic number
FOV_SCALE = 2 * tan(FOV / 2)
Why? Who knows. This is a little frustrating, because it means i don't
understand some part of the rendering process.
|
|
Except that i'm not satisfied. It would appear that we're computing
various distances more-or-less exactly in the sprite rendering
process, but this is at odds with the walls and floors which -- by
virtue of the linear interpolation garbage -- don't agree about where
things are.
The net result is that there are at least two fudge factors:
- to account to for the incorrect height of the floors i shift the
sprites up by 0.2
- to account for the incorrect wall distances i add 1 to the z_buffer
comparison
These fudges are ugly and empirical.
Still to do: for more than one object we have to sort by distance first!
|
|
|
|
The way floors are currently rendered the textures will always
appear ``under'' the walls. This is not intended for shorter walls,
the floor should be atop them.
I might be able to fix this by switching to vertical scan-line
rendering of floors -- although i understand that that is less
efficient -- and doing this at the same time as wall rendering.
|
|
Also bumped up the textures to 32x32
|
|
|
|
|
|
|
