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
Admin
Posts: 13107
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

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

Post by Rachael »

Indeed it would - but that map has proven time and again that it is great for profiling and optimization. It's basically the NUTS.wad of Doom renderers.

And as one can plainly see - most source ports that play Frozen Time quite literally get Frozen in Time. *ahem*
zuzma
Posts: 57
Joined: Fri Oct 22, 2004 10:28 am

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

Post by zuzma »

Is there any known bugs in the software render for the hud weapon not turning black and white with the invulnerability effect being applied? I'm always wary providing any kind of bug reports because it could just be my fault
dpJudas
 
 
Posts: 2893
Joined: Sat May 28, 2016 1:01 pm

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

Post by dpJudas »

That's a bug. Thanks for reporting it. Probably happened when I split the player sprites from the normal sprite rendering.

Edit: checked in a fix for this.
zuzma
Posts: 57
Joined: Fri Oct 22, 2004 10:28 am

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

Post by zuzma »

Good to know, I kept trying to change options and even ended up erasing the ini file to try to fix it. I do feel a bit bad for not submitting it to the bug tracker now though. Still thanks for taking the time to fix it and for making such an awesome looking software renderer. It's great with smooth doom even :)
dpJudas
 
 
Posts: 2893
Joined: Sat May 28, 2016 1:01 pm

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

Post by dpJudas »

You're welcome. And don't worry about not having reported it - sometimes it is good not to know you broke something for a few days. :)
User avatar
Marisa the Magician
 
 
Posts: 3852
Joined: Fri Feb 08, 2008 9:15 am
Preferred Pronouns: She/Her
Graphics Processor: nVidia with Vulkan support
Location: Vigo, Galicia

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

Post by Marisa the Magician »

So... when are we getting software lights to affect sprites? :wink:
User avatar
ibm5155
Posts: 1268
Joined: Wed Jul 20, 2011 4:24 pm

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

Post by ibm5155 »

I'll give u a cookie for making dynamic lights to work with slopes :wink:
and 10 cookies to make the 3d models (md2 md3) to work in software) :D
dpJudas
 
 
Posts: 2893
Joined: Sat May 28, 2016 1:01 pm

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

Post by dpJudas »

You know, cookie monster eats 10 cookies in less than a second! I need a lot more!! :)

But, yeah, I should finish up the last few things about those lights. As for md2 and md3 support, don't expect to be getting this anytime soon. The way sprite clipping works with their draw segments makes it very difficult to add. And I can't just upgrade sprite clipping to use a zbuffer (like Quake did) because then I get the ground clipping problem GZDoom has.
User avatar
Nash
 
 
Posts: 17324
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia

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

Post by Nash »

Would the models be easier to implement for SoftPoly though? Considering the entire world is drawn with triangles... ?
dpJudas
 
 
Posts: 2893
Joined: Sat May 28, 2016 1:01 pm

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

Post by dpJudas »

It would be, although softpoly doesn't use a zbuffer either. At this point softpoly is lacking in so many other features that I'm not sure you'd really want to use it on anything but classic Doom maps. :) Especially its portal/camera clipping is really broken.
User avatar
Jaxxoon R
Posts: 772
Joined: Sun May 04, 2014 7:22 pm

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

Post by Jaxxoon R »

Image
Am I crazy, or are the software dynamic lights being selectively applied to specific parts of the sprites? As in, they might actually be better than the GL ones?
dpJudas
 
 
Posts: 2893
Joined: Sat May 28, 2016 1:01 pm

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

Post by dpJudas »

Sadly, they are only buggier. :)

If that screenshot is from the last nightly build, then the next one should hopefully be working better. I had an error in the sprite drawer that made it change the strength of the dynamic light as it drew the sprite vertically.

By the way, QZDoom no longer uses LLVM. I replaced it with some php scripts that generates the SSE 2 intrinsics needed. As a bonus this improved the speed quite considerably in some cases because the new code does the math using 16 bit integers.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48374
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

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

Post by Graf Zahl »

Out of curiosity, would it later be possible to set up the PHP stuff as part of the build process or would this require too much of a setup to get running?

Also nice to see that the SSE2 intrinsics aren't that bad. Why didn't this work out the first time - before you went LLVM?


Regarding the sprite lighting, the reason why the sprites are lit as one object is mostly that sprites have no fixed place in 3D space so doing real positioned lighting may look weird. I'll have to do it for models anyway sometime and then I might just try it on sprites as well.
dpJudas
 
 
Posts: 2893
Joined: Sat May 28, 2016 1:01 pm

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

Post by dpJudas »

Graf Zahl wrote:Out of curiosity, would it later be possible to set up the PHP stuff as part of the build process or would this require too much of a setup to get running?
I think it is pretty easy to do so. All I'm really doing is running "php r_draw_span32.php > r_draw_span32.h" to get the header file. You could probably get cmake to do that automatically by adding some .php to .h rule. The only catch is that you'd need to have php.exe installed to build it then.
Graf Zahl wrote:Also nice to see that the SSE2 intrinsics aren't that bad. Why didn't this work out the first time - before you went LLVM?
I never attempted this approach until now. Originally I wrote the drawers by hand using zdoom-style copy and paste. When that got out of hand I tried to use templates. The LLVM approach was the next thing I tried. It wasn't until then I realized that getting a better preprocessor might be a better solution - it guarantees that things are inline, yet it allows me to use PHP to control which snippets are included or duplicated. The php files are still pretty dense stuff to read, but at least there's no code duplication.

Ideally a perfect C++ compiler would be able to do this with inline functions, constants and templates. I just don't really trust them enough be willing to bet the house on it. Take the hilariously sad constexpr in C++11 as an example. No C++ compiler is required to do anything with that keyword at compile time.
Graf Zahl wrote:Regarding the sprite lighting, the reason why the sprites are lit as one object is mostly that sprites have no fixed place in 3D space so doing real positioned lighting may look weird. I'll have to do it for models anyway sometime and then I might just try it on sprites as well.
That's what the software version is doing too. It just happened to have a bug that made it look sorta fancy at times the way it bugged. :)
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48374
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

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

Post by Graf Zahl »

dpJudas wrote: Ideally a perfect C++ compiler would be able to do this with inline functions, constants and templates. I just don't really trust them enough be willing to bet the house on it. Take the hilariously sad constexpr in C++11 as an example. No C++ compiler is required to do anything with that keyword at compile time.
Just a quick example, here's how I once solved a similar problem with templates:

Code: Select all

 enum EModes
 {
      Mode1,
      Mode2,
      ...
};

struct Mode1Struct
{
      static const int Mode = Mode1;
};

struct Mode2Struct
{
      static const int Mode = Mode2;
};

template<class T> function()
{
    if (T::Mode == Mode1)
    {
    }
    if (T::Mode == Mode2)
    {
    }
}
The nice thing is that all values involved in the check are constant so it will perfectly elimintate all unwanted code. And this can easily be expanded, if you have more than one condition to check, just add a second constant to the template structs.

Or take ZDoom's own FBitmap class for a somewhat more complex example of using templates to avoid redundant code repetition.

Return to “Game Engines”