QZDoom - ZDoom with True-Color (Version 1.3.0 released!)

Game Engines like EDGE, LZDoom, QZDoom, ECWolf, and others, go in this forum
Forum rules
The Projects forums are ONLY for YOUR PROJECTS! If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.

Got a cool project idea but nothing else? Put it in the project ideas thread instead!

Projects for any Doom-based engine are perfectly acceptable here too.

Please read the full rules for more details.
User avatar
Rachael
Posts: 13913
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: QZDoom - ZDoom with True-Color (Version 1.0 released!)

Post by Rachael »

That is a pretty cool effect, isn't it? I would like to see something like that, myself. :P

It should actually be possible, especially since in the base renderer (the Doom one) wall offsets are calculated per-column anyway, so it shouldn't be too hard to add in slope information to that line. The problem comes with how GZDoom will handle it because it will do that totally differently. Graf may have an idea of how to do that anyway, though.

I looked at your spinning gears it looks like that was done with a midtex polyobject. I don't know if those are supported yet. Also - bugs can be reported here - I'll put that in the first post. :)
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine

Re: QZDoom - ZDoom with True-Color (Version 1.0 released!)

Post by ZZYZX »

In OGL you'd just not offset right (v2) side of quad's UV coordinates by the slope difference. It's easier to "implement" this feature accidentally than to fix it later, since it's natural to how polygons are assigned textures.
dpJudas
 
 
Posts: 3163
Joined: Sat May 28, 2016 1:01 pm

Re: QZDoom - ZDoom with True-Color (Version 1.0 released!)

Post by dpJudas »

Eruanna wrote:The poly renderer does a complex type of sorting for the polygons (It renders the BSP tree back-to-front) and like ye olde tried and true Carmack renderer, lacks Z-depth information.
Actually, nowadays it renders the BSP front-to-back. It uses a stencil buffer as a poor-mans zbuffer to clip stuff behind a wall, and then it clips sprites by subsector in its translucent pass.
Eruanna wrote:That happens any time a texture coordinate exceeds 8192 or -8192. I suspect it has something to do with the floating point numbers being incompatible between LLVM and MSVC++.
Oh, you found the connection for when the texture coordinates fail. Always assumed it was some flag or scaling issue on the line or similar. About why it happens, I'm not sure. Maybe something overflows when converting floats to integers.
ZZYZX wrote:Also, particles are Y-billboarded. These are XY-billboarded in GZDoom.
It is funny how nothing goes unnoticed by the ZDoom community. :D Okay, so I was a bit lazy and grabbed the sprite billboarding code and used it for the particles!
User avatar
Rachael
Posts: 13913
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: QZDoom - ZDoom with True-Color (Version 1.0 released!)

Post by Rachael »

For the texture coordinate issue, I think the thing to try is converting to doubles. In fact, I noticed that you use floats in a lot of the r_poly code, and that does not seem to be advisable between two different compiler types. (ZDoom has had issues in the past with compiler incompatibilities between MSVC and GCC - using float types for some structures, this caused netgame desyncs out the wazoo due to the way floats were calculated. They went away when the floats were converted to doubles - I suspect a similar issue exists with LLVM, except maybe with actual float struct incompatibility rather than just math since numbers are being passed between MSVC and LLVM)
dpJudas
 
 
Posts: 3163
Joined: Sat May 28, 2016 1:01 pm

Re: QZDoom - ZDoom with True-Color (Version 1.0 released!)

Post by dpJudas »

I use floats because if they are good enough for GPUs, they are good enough for me. :) Unfortunately, unlike GPUs, I have to convert my floats to integers once in a while for performance reasons. :(

The playsim may need the higher precision, but for 3D rendering the trick is to just keep all numbers near zero. I don't think this is a precision issue, although ideally it shouldn't use texture coordinates that large when it could just use a 0-1 range instead for that wall. It is probably more because I cast the floats to integer using this patent-pending equation:

Code: Select all

uint32_t texU = (uint32_t)(int32_t)(u * 0x01000000);
uint32_t texV = (uint32_t)(int32_t)(v * 0x01000000);
uint32_t texelX = (((texU << 8) >> 16) * textureWidth) >> 16;
uint32_t texelY = (((texV << 8) >> 16) * textureHeight) >> 16;
uint32_t texel = texture[texelX * textureHeight + texelY];
It overflows every 256 units, but more importantly, LLVM's intrinsic function for casting float to integer says the behavior in such a situation is 'undefined'. They want me to clamp or fmod the float first, but I don't have time for that! Need this triangle rendered ASAP! So I ignored that - undefined be damned. Maybe at 8192 that undefined behavior started to matter. ;)
User avatar
Rachael
Posts: 13913
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: QZDoom - ZDoom with True-Color (Version 1.0 released!)

Post by Rachael »

It never was a precision issue per se - it was an issue of number incompatibility. It's like passing an MSB argument to a function that expects it to be LSB. It'll compile, you'll get no errors, but 1 becomes 65536, 2 becomes 131072, etc. Different systems, different structures. What I was saying was I don't think MSVC's float is the same as LLVM's float.

But the issue you brought up is a very different issue - and may have something to do with that. It's possible at 8192 the float starts to lose precision, and because of that it reaches that "undefined behavior" you were talking about because the float's decimal is being assigned to a higher point.
dpJudas
 
 
Posts: 3163
Joined: Sat May 28, 2016 1:01 pm

Re: QZDoom - ZDoom with True-Color (Version 1.0 released!)

Post by dpJudas »

Yes, it is probably something like that - LLVM doing some bit tricks for speed that only works before it loses precision.

I'm not too keen on making the triangle drawer's inner loop deal with this, for performance reasons. But a simple solution could be to grab one of the vertices, calculate its integer value and then 'normalize' the texture coordinates before feeding them to the drawer. Something like this:

Code: Select all

float u_origin = floor(v1.varyings[0]);
v1.varyings[0] -= u_origin;
v2.varyings[0] -= u_origin;
v3.varyings[0] -= u_origin;

float v_origin = floor(v1.varyings[1]);
v1.varyings[1] -= v_origin;
v2.varyings[1] -= v_origin;
v3.varyings[1] -= v_origin;
Add that just before PolyTriangleDrawer::draw_shaded_triangle calls the drawfunc for the vertices will probably do the trick.

Edit: rats, doing it exactly like this will break the sky as it expects values going slightly beyond -1 and 1 for the fade effect to work. But maybe change the check so that its for every 10 uv coordinate instead or something.
User avatar
Nash
 
 
Posts: 17484
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia

Re: QZDoom - ZDoom with True-Color (Version 1.0 released!)

Post by Nash »

Hey I just downloaded the latest devbuild of QZ and gave SoftPoly a spin. Good to see the walls behind the player not disappearing anymore when looking up/down. :D Ran around the first few Doom 2 levels and it feels pretty good and I didn't notice any glaring visual glitches.

I am getting sub-60 framerates constantly though... is there any chance SoftPoly can run as smooth as the software renderer at 1080p, or is this just the reality of a non-accelerated polygonal renderer that we have to accept?
User avatar
Rachael
Posts: 13913
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: QZDoom - ZDoom with True-Color (Version 1.0 released!)

Post by Rachael »

If I can understand the drawers I was thinking of doing some math caching, but I am not sure what is feasible.

A long time ago (~2000 or so) I created a Wolf3D-like software renderer using Visual Basic for DOS. I noticed when I precalculated the math for the entire screen matrix, I got a boost of speed to the amount of about 5-6 times faster than it was before.

Obviously, this is a triangle drawer so it's different, but the calculations do not need to be 100% precise and I think storing sin/cos/tan/atn values in a table could help boost things a lot. I haven't even looked at the drawers in-depth yet to see exactly how dpJudas pulled this off. :P

Also - good news - I got my laptop to compile QZDoom. Now I just need to figure out how I did my batch files so that I can get it to automatically build and upload new builds of QZDoom. :) It runs everything from an SD card to keep that silly hard drive from overheating...
User avatar
Rachael
Posts: 13913
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: QZDoom - ZDoom with True-Color (Version 1.0 released!)

Post by Rachael »

Aaaaaand new builds posting now. Yay. Really uncomfortable building from my laptop, but at least I made a new building environment that's much better than the old one. I will probably be copying that back over to the old computer when it's back up again. :)
dpJudas
 
 
Posts: 3163
Joined: Sat May 28, 2016 1:01 pm

Re: QZDoom - ZDoom with True-Color (Version 1.0 released!)

Post by dpJudas »

The triangle drawer can be made to run faster than it is doing right now - in fact, I had a version that ran almost twice the speed before adding the linear filtering to it. I need to do some minor code adjustments before being able further optimize it. You will never see it get the same speed as the original renderer though.

@Eruanna: there's no usage of sin/cos/tan kind of stuff in the drawer. In fact, once it reaches the LLVM drawer the triangle has already been projected to 2D screen coordinates. The main things slowing the drawer down is that it is doing a lot of things: stencil buffer, subsector gbuffer, perspective divide, diminishing light, linear filtering and blending.

Glad to hear that you got your build environment back online. :)
User avatar
Rachael
Posts: 13913
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: QZDoom - ZDoom with True-Color (Version 1.0 released!)

Post by Rachael »

Ah. That's what I get for not looking at the code. :P

I am still working on another project that I am hoping to have ready as a completed code submission tonight or tomorrow night. After that, I'm going to try again at diving into the poly code to see if I can make sense of all the stuff there. :P There's a lot going on there.
dpJudas
 
 
Posts: 3163
Joined: Sat May 28, 2016 1:01 pm

Re: QZDoom - ZDoom with True-Color (Version 1.0 released!)

Post by dpJudas »

Maybe I should write some kind of overview thing describing it. Especially the LLVM codegen code is almost of Ken Silverman level of mystery without some higher level explanation of what is going on. :)
User avatar
Rachael
Posts: 13913
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: QZDoom - ZDoom with True-Color (Version 1.0 released!)

Post by Rachael »

That would be helpful, yes. :P
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine

Re: QZDoom - ZDoom with True-Color (Version 1.0 released!)

Post by ZZYZX »

IMO sub-60 fps is fine, goal FPS for the renderer should be 35fps @ 1920x1080. That, it currently does, even on medium-detailed maps.
Btw just curious, is there any chance to have drawing moved into another thread to make use of multiple CPU cores? Today most CPUs have at least two.

Also, would using something like angle-based wall list (i.e. that'd store things like angle 45 to 47 from the camera being obstructed by a wall) instead of stencil buffer work for clipping stuff? (that is, with sorting things back-to-front again)
Also, does polygonal 8-bit mode exist? I'd imagine it should be noticeably faster.

Return to “Game Engines”