DelphiDoom progress in 3d perspective in software mode, now with voxel support

[jval]

kb1 said:

jval:

So what exactly (mathmatically) is "3d perspective"? How does it differ from standard software rendering?

DelphiDoom's fake 3d is a compination of zaxisshift, aspect ratio changing depending on the look up/look down angle, panning and stretching of horizontal lines depending on the line Y position and finally a trapezoid to rectangle stretch.

Stroggos said:

Ken Silverman did actually describe the format in the readme file of another project of his called Slab6. So you can just use what he describes there without the need to tear apart the BUILD engine and use that license.

That was the guideline I've used to make the KVX loader, but DelphiDoom reads only the first mip of the KVX file and convert the data to an internal structure. Then it generates mip levels at loadtime.

[kb1]

jval said:

DelphiDoom's fake 3d is a compination of zaxisshift, aspect ratio changing depending on the look up/look down angle, panning and stretching of horizontal lines depending on the line Y position and finally a trapezoid to rectangle stretch.

So, if I understand you correctly, you are doing the following transformations: Assuming you're looking upward:

* Increase the view point along the up-down axis (I'll call it Y), like Heretic does.

* Adjust FOV on a per-scanline basis (higher FOV near the top of the screen, which makes the top of walls closer to the horizontal center (X) of the screen).

* Apply a scale factor for flats (think ceilings) when rendering them from top to bottom, effectively reducing the amount that they are visually stretched.

If that's what's happening, that's quite impressive, and has the benefit that it doesn't slow down the render much at all. Nice! I imagine that it's also limited to a certain view angle - does it start to look bad past 45 degrees?

[jval]

kb1 said:

* Increase the view point along the up-down axis (I'll call it Y), like Heretic does.

Yes, the zaxistshift is from Heretic/Hexen.

kb1 said:

* Adjust FOV on a per-scanline basis (higher FOV near the top of the screen, which makes the top of walls closer to the horizontal center (X) of the screen).

Not excactly, I adjust FOV depending on look up/down angle (bigger angle, bigger FOV) for all the rendering context and also adjust floorclip or ceilingclip to avoid overdraw.

kb1 said:

* Apply a scale factor for flats (think ceilings) when rendering them from top to bottom, effectively reducing the amount that they are visually stretched.

If you look the 3rd picture of the first post the horizontal scanlines are stretched to fit "windowwidth" and also the Y positions of each scanline are altered in a way that if you are looking up the small Y values are getting smaller and the bigger Y values are closer to their original position.

kb1 said:

If that's what's happening, that's quite impressive, and has the benefit that it doesn't slow down the render much at all. Nice! I imagine that it's also limited to a certain view angle - does it start to look bad past 45 degrees?

A transformation lookup table is created for each of look up/look down angles to avoid doing all the above calculations in each frame. When "viewwidth" changes the lookup tables are recalced. The procedure does not slow down the renderer because the extra time needed fot the calculations is gained by the modified floorclip/celingclip (less drawing) and by using multithreading. Look up is limited to 45 degress and look down to 37 degress.

[entryway]

Maes said:

in fact, in Heretic shifting view means recomputing the yslope table every time

I knew z-shiftting mlook should not be hard for implementing, but never thought that full implementation is about 10 lines of code. I added mlook to software mode to prboom-plus this night. Sky stretching code was taken from ZDoom.

[Memfis]

ZDoom also has a useful button that enables mouselook while you're holding it. Normally I play without ML but if I really need it in some situation, I can enable it for a moment by pressing and holding right mouse button. Would be nice to see this in prboom+ as well!

[jval]

entryway said:

I knew z-shiftting mlook should not be hard for implementing, but never thought that full implementation is about 10 lines of code. I added mlook to software mode to prboom-plus this night. Sky stretching code was taken from the ZDoom.

Indeed, it took me by suprise when I first checked with Heretic/Hexen source code.

[Maes]

entryway said:

I knew z-shiftting mlook should not be hard for implementing, but never thought that full implementation is about 10 lines of code. I added mlook to software mode to prboom-plus this night. Sky stretching code was taken from the ZDoom.

I have added it to Mocha Doom from v1.5 and onwards (though it's undocumented, and uses PgUp/PgDown/Home/End). Yeah, it really is an easy hack, and it only cross-cuts other code in very few places, where the lookdir variable is used. The only potentially demo-breaking part is when the lookdir is used to bias/aid player autoaim.

[Da Werecat]

Memfis said:

ZDoom also has a useful button that enables mouselook while you're holding it. Normally I play without ML but if I really need it in some situation, I can enable it for a moment by pressing and holding right mouse button. Would be nice to see this in prboom+ as well!

GLBoom+ already has a button to toggle mlook. It also toggles the sky rendering method.

[kb1]

entryway said:

I knew z-shiftting mlook should not be hard for implementing, but never thought that full implementation is about 10 lines of code. I added mlook to software mode to prboom-plus this night. Sky stretching code was taken from ZDoom.

Yep, it may look a little crappy, but, you're right: for 10 lines of code, it's hard to justify not adding it.

Now, it gets a bit more tricky to do some other things, like weapon aiming. You *could* leave it original, but, with orignal code, you can see the monster, but not be able to hit it, with extreme mlook angles. Of course, that happens without mlook sometimes as well :)

Another issue is the non-vertically-wrapping sky. I seriously wish someone with artistic abilities would make a set of super-tall skies that look original. :) Please! (or did I miss them?) I know there are some slightly-larger ones out there (240 pixels tall vs. 200, but that's not enough.) Of course, the port must have 'tall wall' support.

One last thing: Killough's renderer optimizations and mlook don't quite jive - I remember having to modify some Killough clipping code to prevent sprites from disappearing. Like if you're at the top of the stairs in E1M1, I had shotgunners disappearing below me intermittently, when they should have been visible. I don't have the code in front of me now, so I can't tell you what I did to fix it - but, just test it - maybe it's not a problem for you anyway. But, if you fix it wrong, Doom wants to render sprites that are way above or below the screen boundaries, and it's caught much later in the pipeline, so to speak, right before rendering, which slows things down a bit (per row clipping vs. per-sprite).

[entryway]

kb1 said:

One last thing: Killough's renderer optimizations and mlook don't quite jive - I remember having to modify some Killough clipping code to prevent sprites from disappearing. Like if you're at the top of the stairs in E1M1, I had shotgunners disappearing below me intermittently, when they should have been visible. I don't have the code in front of me now, so I can't tell you what I did to fix it - but, just test it - maybe it's not a problem for you anyway.

It would be nice to fix it, but without rewriting too much of code. If you already know how to do it, send me a patch, please.

[Gez]

kb1 said:

Another issue is the non-vertically-wrapping sky. I seriously wish someone with artistic abilities would make a set of super-tall skies that look original. :) Please! (or did I miss them?) I know there are some slightly-larger ones out there (240 pixels tall vs. 200, but that's not enough.) Of course, the port must have 'tall wall' support.

For ZDoom (and so apparently PrBoom+ now) the sky needs to be 544-pixel tall to a void tiling entirely. Though most of that (344 pixels) will be below the horizon line; so 200 should be enough when you don't have sky floors.

[kb1]

entryway said:

It would be nice to fix it, but without rewriting too much of code. If you already know how to do it, send me a patch, please.

Does your source actually exhibit the problem? Here's my fix, which is not so great, I just pre-clip using a taller window, and expect the sprite to be culled later:

In R_ProjectSprite:

// killough 4/9/98: clip things which are out of view due to height
// [kb] add +1 so sprites are shown even with the extended freelook
if (thing->z > viewz + FixedDiv(viewheight << (FRACBITS + 1), xscale) ||
   gzt < viewz - FixedDiv((viewheight << (FRACBITS + 1)) - viewheight, xscale))
  return;

It could be greatly improved by devoting some thought to the matter, but, whatever is done must be faster than the clipping that occurs later, or you haven't saved any time. The above code DOES work, though, even with an extreme mlook (screen.height * 3), in that sprites never disappear unexpectedly, and far-out-of-range sprites do still get rejected, so it's seems like a good compromise between simplicity and speed.

If you think of a better algorithm, please let me know.

[entryway]

kb1 said:

In R_ProjectSprite:

Thanks.

http://pastebin.com/0QfimPHn