ZDoom

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*

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

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.

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

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.

So... when are we getting software lights to affect sprites?

I'll give u a cookie for making dynamic lights to work with slopes
and 10 cookies to make the 3d models (md2 md3) to work in software)

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.

Would the models be easier to implement for SoftPoly though? Considering the entire world is drawn with triangles... ?

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.

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?

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.

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.

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 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 • Expand 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.