Ragstaff wrote:Amazing stuff!! I can't wait to get home and try running some of those STRay demo's. I'm gobsmacked looking at the screenshots!
Ragstaff wrote:I've always been intrugued by first-person engines on the ST, from Midimaze, Legends of Valour, through to Hellgate, Substation, Imminent Destruction, Defjams screen in the Checkpoint demo (which you could control with the keys if you hit... esc, I think?), Rays Wolf3d, and now this.
Of course I'm also eager to see if you have been able to get back onto this project since putting your attentions back onto Badmood!
TBH still busy on BM finishing off the audio & music, which has quietly grown into a project of its own - complete with bugs and extra work to go.
There is work remaining on the ST project which needs to come off the shelf but I need to put BM to bed first.
Ragstaff wrote:FYI, I recall you made one comment in this thread wondering how much CPU Ray uses clearing the floor and ceiling, even if it was none. Ray's todo list for v0.9 (never released) included "* a delta clear to draw floors/ceilings more quickly". Doesn't apply to you as your floors and ceilings are textured obviously, but thought I'd throw that in to answer your question a little!
Yes it probably would make sense for him to try that although the clear time is probably minor compared with the rest, so it would be a small improvement.
I'd be fascinated to see if you, having done this detailed study into first-person rendering techniques and features, could find any other optimisations to Ray's already-amazing Wolf3D engine. Or vice versa. You two should collaborate some time
It's hard to find meaningful optimizations for that
I did find a few but they are small.
Wolf has several advantages which help simplify - textures don't need to tile vertically, and all walls are the same height. These two facts mean you can generate a unique bit of code for every possible z - (more realistically: every possible steprate). If the eye height can't move (I forget, but I think it is fixed in Wolf?) then you have another advantage - the starting y for each column is also fixed according to z. So you get clipping for free, by simply omitting the right bits of each generated column at each given z. Job done!
I'm not sure how Ray does y-clipping, but I bet it looks something like the above. It is popular to reserve some margin/dead area above and below the framebuffer and let stuff spill over - but that has its limits in 3D because stuff up close gets bigger faster
(using a margin is more technically called 'guardband clipping') and it wastes fillrate in the worst case.
So Doom (and STRay) break the 'Wolf rules', and code-generating columns in that way won't work. There are too many things going on at once - vertical start/end positions, steprate, tiling offsets - and restricting the combinations just puts more limitations on the drawing and before you know it you are back to Wolf3D. These requirements also break the clipping trick I describe above - so I had to find a different way, while still avoiding waste pixels.
So most of the effort I spent on the walls wasn't on improving the speed of scaling, but on all that other stuff - preserving those capabilities without paying the price of making it slower.
I found a tidy solution to tile textures while using fast code-generated columns, to recover sub-pixel texturing precision for the starting coordinates of each column, and arbitrary height columns - using what I think are some 'new' techniques. I say new because they depend a lot on mipmapping arithmetic and I don't think anyone else bothers with mipmaps because its just more complexity and effort for normally not much extra use
I found some ways to make it very useful in the math to save memory and cycles, which is nice.
In the end, I managed to make the scaling a little bit faster than Wolf (cycles per texel), but only by using a wider variety of codegen patterns. Something Ray had already done to an extent, from what I can see - I just took it a bit further to save more cycles, at the cost of making the code generator much more complicated (and so, more debugging and testing). There are no particularly new ideas introduced in that optimization, just more work. The actual saving from this is probably small - a few %.
So any 'new stuff' which lurks in there will be related to:
- better precision from generated code
- better reuse of generated code
- variable height columns with generated code
- tiling with generated code
...and not on new ways to fill pixels (which is just more generated code). I think that's a fair summary of that thing.
Thanks - I missed a lot of stuff from that time and still catching up with it - esp. the ones without YT links and which don't like my default STE TOS
I moved machines recently and still to copy over a lot of Atari related things like ROMs!
L.O.V - I remember the game quite well from the mag reviews etc. but know very little about the tech. I don't remember if I saw the game running. Will look when I get a chance.