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.

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

Postby Rachael » Mon Feb 06, 2017 7:14 pm

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*
User avatar
Rachael
Admin
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Debian-like Linux (Debian, Ubuntu, Mint, etc) 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

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

Postby zuzma » Tue Feb 07, 2017 10:49 am

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
zuzma
 
Joined: 22 Oct 2004

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

Postby dpJudas » Tue Feb 07, 2017 1:31 pm

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.
dpJudas
 
 
 
Joined: 28 May 2016

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

Postby zuzma » Tue Feb 07, 2017 2:47 pm

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 :)
zuzma
 
Joined: 22 Oct 2004

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

Postby dpJudas » Tue Feb 07, 2017 2:53 pm

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. :)
dpJudas
 
 
 
Joined: 28 May 2016

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

Postby Marisa Kirisame » Sun Feb 12, 2017 4:42 pm

So... when are we getting software lights to affect sprites? :wink:
User avatar
Marisa Kirisame
ZScript Crimester
 
 
 
Joined: 08 Feb 2008
Location: Vigo, Galicia
Discord: 霧雨魔理沙#1666
Twitch ID: MarisaDOOM
Github ID: OrdinaryMagician
Operating System: Other Linux 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

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

Postby ibm5155 » Mon Feb 13, 2017 4:42 am

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
User avatar
ibm5155
Just Spooky
 
Joined: 20 Jul 2011

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

Postby dpJudas » Mon Feb 13, 2017 5:15 am

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.
dpJudas
 
 
 
Joined: 28 May 2016

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

Postby Nash » Mon Feb 13, 2017 5:20 am

Would the models be easier to implement for SoftPoly though? Considering the entire world is drawn with triangles... ?
User avatar
Nash
AKA Nash Muhandes! Twitter/Facebook/Youtube: nashmuhandes
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Twitch ID: nashmuhandes
Github ID: nashmuhandes

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

Postby dpJudas » Mon Feb 13, 2017 5:55 am

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.
dpJudas
 
 
 
Joined: 28 May 2016

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

Postby Jaxxoon R » Thu Feb 23, 2017 4:28 pm

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?
User avatar
Jaxxoon R
 
Joined: 04 May 2014

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

Postby dpJudas » Thu Feb 23, 2017 6:41 pm

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.
dpJudas
 
 
 
Joined: 28 May 2016

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

Postby Graf Zahl » Thu Feb 23, 2017 7:20 pm

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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

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

Postby dpJudas » Thu Feb 23, 2017 8:03 pm

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. :)
dpJudas
 
 
 
Joined: 28 May 2016

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

Postby Graf Zahl » Fri Feb 24, 2017 4:24 am

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 allExpand view
 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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

PreviousNext

Return to Game Engines

Who is online

Users browsing this forum: No registered users and 0 guests