Cyberdemon
Register | User Profile | Member List | F.A.Q | Privacy Policy | New Blog | Search Forums | Forums Home
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Classic Doom > Source Ports > DelphiDoom progress in 3d perspective in software mode, now with voxel support
Pages (2): « 1 [2]  
Author
All times are GMT. The time now is 11:25. Post New Thread    Post A Reply
jval
Junior Member


Posts: 192
Registered: 09-05



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.

Old Post 06-21-13 15:44 #
jval is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit || Quote
kb1
Member


Posts: 416
Registered: 11-06



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?

Old Post 06-21-13 22:40 #
kb1 is offline Profile || Blog || PM || Search || Add Buddy IP || Edit || Quote
jval
Junior Member


Posts: 192
Registered: 09-05



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.

Old Post 06-22-13 07:33 #
jval is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit || Quote
entryway
Forum Staple


Posts: 2739
Registered: 01-04



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.

Last edited by entryway on 06-22-13 at 19:29

Old Post 06-22-13 10:41 #
entryway is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit || Quote
Memfis
Forum Spammer


Posts: 5800
Registered: 04-07


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!

Old Post 06-22-13 15:49 #
Memfis is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit || Quote
jval
Junior Member


Posts: 192
Registered: 09-05



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.

Old Post 06-22-13 16:50 #
jval is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit || Quote
Maes
I like big butts!


Posts: 12754
Registered: 07-06



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.

Old Post 06-22-13 17:24 #
Maes is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit || Quote
Da Werecat
Senior Member


Posts: 1419
Registered: 11-09



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.

Old Post 06-22-13 17:28 #
Da Werecat is online now Profile || Blog || PM || Search || Add Buddy IP || Edit || Quote
kb1
Member


Posts: 416
Registered: 11-06



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).

Old Post 06-25-13 01:54 #
kb1 is offline Profile || Blog || PM || Search || Add Buddy IP || Edit || Quote
entryway
Forum Staple


Posts: 2739
Registered: 01-04



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.

Last edited by entryway on 06-25-13 at 10:10

Old Post 06-25-13 08:51 #
entryway is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit || Quote
Gez
Why don't I have a custom title by now?!


Posts: 11390
Registered: 07-07



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.

Old Post 06-25-13 09:06 #
Gez is online now Profile || Blog || PM || Search || Add Buddy IP || Edit || Quote
kb1
Member


Posts: 416
Registered: 11-06



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:
code:
// 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.

Old Post 06-26-13 00:54 #
kb1 is offline Profile || Blog || PM || Search || Add Buddy IP || Edit || Quote
entryway
Forum Staple


Posts: 2739
Registered: 01-04



kb1 said:
In R_ProjectSprite:

Thanks.

http://pastebin.com/0QfimPHn

Old Post 06-26-13 08:25 #
entryway is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit || Quote
All times are GMT. The time now is 11:25. Post New Thread    Post A Reply
Pages (2): « 1 [2]  
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Classic Doom > Source Ports > DelphiDoom progress in 3d perspective in software mode, now with voxel support

Show Printable Version | Email this Page | Subscribe to this Thread

 

Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is OFF
vB code is ON
Smilies are OFF
[IMG] code is ON
 

< Contact Us - Doomworld >

Powered by: vBulletin Version 2.2.5
Copyright ©2000, 2001, Jelsoft Enterprises Limited.