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

[Marisa the Magician]

Oh by the way, I commented on the dynamic lights bug that player sprites are still unaffected.

[dpJudas]

That will work for the branching, but it still leaves the problem that the inner loops needs to do several function calls to Sample, Shade and Blend. It isn't until VS2015 that Visual Studio even has a calling convention (__vectorcall) that could support it (most of the arguments to those functions are __m128i). That calling convention works for simple arguments, but look at it funny and it will stop inlining.

The php scripts are arranged in such a way that it is relatively easy to test if this works without any speed regressions, so I can give it a try. But I wouldn't be too surprised if one of them found some lousy excuse for not inlining things.

@MarisaKirisame: yep, didn't implement it for player sprites. Those use a canvas drawing API I'm not very familiar with - not sure how easy it is to add there.

[dpJudas]

Okay, implemented a templated version of the span drawers. Seems to have had no performance impact on MSVC or on clang. So far so good.

[Marisa the Magician]

No problem on GCC either.

[RaVeN-05]

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?

I like this method of lightning, look at this -> viewtopic.php?p=543443#p543443
and this -> http://forum.drdteam.org/viewtopic.php? ... 223#p49223

[dpJudas]

Well, seems the templated version just got Game Over'ed by Microsoft's 32 bit compiler:

Code: Select all

r_draw_wall32_sse2.h(274): error C2719: 'shade_fade': formal parameter with requested alignment of 16 won't be aligned
r_draw_wall32_sse2.h(274): error C2719: 'shade_light': formal parameter with requested alignment of 16 won't be aligned
r_draw_wall32_sse2.h(274): error C2719: 'viewpos_z': formal parameter with requested alignment of 16 won't be aligned
r_draw_sprite32_sse2.h(360): error C2719: 'shade_fade': formal parameter with requested alignment of 16 won't be aligned
r_draw_sprite32_sse2.h(360): error C2719: 'shade_light': formal parameter with requested alignment of 16 won't be aligned
r_draw_sprite32_sse2.h(360): error C2719: 'lightcontrib': formal parameter with requested alignment of 16 won't be aligned
r_draw_span32_sse2.h(352): error C2719: 'shade_fade': formal parameter with requested alignment of 16 won't be aligned
r_draw_span32_sse2.h(352): error C2719: 'shade_light': formal parameter with requested alignment of 16 won't be aligned
r_draw_span32_sse2.h(352): error C2719: 'viewpos_x': formal parameter with requested alignment of 16 won't be aligned

Apparently 32 bit won't even allow a __m128i or __m128 to be a function argument. Trying to switch to the new __vectorcall calling convention produces this:

Code: Select all

r_draw_wall32_sse2.h(274): error C2218: '__vectorcall' cannot be used with '/arch:IA32'

Edit: okay, found a way to make to compile, but that involves switching from /arch:ZXSpectrum to /arch:SSE2.

[Gez]

/arch:ZXSpectrum

Heh.



Seriously though,how many people are still using non-SSE2 PCs? Every x86-64 processor has them, so you need to go back to decade-old processors like the Athlon XP or the Pentium M to lack them.

[dpJudas]

The Pentium 4 was the first to have SSE 2 support. It was released in 2001, 16 years ago. But yeah maybe add a couple of more years for the AMD and low end chips.

In any case, I fixed it in QZDoom by bumping up the minimum requirement to SSE 2 in the CMakeLists.txt file. That was the minimum requirement anyway for the TC drawers. If someone wants to target those old platforms they will have to send a patch that restores the support.

[Graf Zahl]

Never underestimate the upgrade resistance of computer users. Remember that there have been serious attempts to make a Win98 compatible build.

What this needs to do is separate out the 32 bit drawers into their own group of source files and add the SSE2 option only to that.
The true color renderer won't work with non-SSE2 anyway so having its entire sources SSE2'd won't pose a problem, but what it definitely needs is a safeguard for older hardware which is still nominally supported. Count on it that some people are still out there with such dinosaurs who want to run the classic software renderer.

[dpJudas]

It is already its own file (r_draw_rgba.cpp), but my knowledge of CMake isn't big enough to do it without spending at least an hour on this, maybe more.

I remarked the old checks in the CMakeLists.txt if someone interested in this is willing to do the work. As for those that tried to make a Win98 compatible build - to be a little blunt, the second they realized they actually had to DO something, the efforts quickly ended. Clearly it is only that important if someone else must code it.

[TiZ]

Hiya! I was wondering if there would eventually be .deb package builds for QZDoom on the DRD Team apt repository, like there presently is for GZDoom.

[Rachael]

That is entirely up to Blzut3. I'd suggest you PM him. It's more likely now since the LLVM requirement was removed, but not guaranteed. We'll probably have to do a release without the LLVM in order for that to happen.

Also, it might be helpful for us to add back in ARM support, but that is lower priority right now. It's a "want-to-do-but-doing-too-many-other-things-right-now" project.

[ibm5155]

so, did I miss some kind of new testing dynamic light system for qzdoom?

[dpJudas]

so, did I miss some kind of new testing dynamic light system for qzdoom?

There's just the thing you can find in the WIP thread (look for Nash' video there), although that is more a GZDoom feature (it just happens to have been branched off QZ).

I have another new branch there called shadowmaps, which implements something similar with a lot better performance characteristics. I'll post some more about it once I have something to show.

[RaVeN-05]

What about partial sprite lightning ? viewtopic.php?p=979567#p979567