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

[Rachael]

The official QZDoom builds are now compiled with -T v140_xp.

This means the builds *MAY* work on Windows XP. I am not sure about that, though. Someone will have to test. If they still don't work, I am probably not going to put in too much more effort to fix them.

[Rachael]

Another release is imminent. I've thrown up some release candidates. If nothing major gets reported within the next day or two, these will be promoted to official releases.

q1.1.0 rc1 32-bit
q1.1.0 rc1 64-bit

Notable changes:

• Updated to the very last ZDoom/GZDoom commit before the ZScript merge.
• Lots of stability improvements with the drawer code.
• LLVM code is now compiled directly into the executable rather than at startup. This results in smaller executable sizes, as well as faster startups. The LLVM code is compiled to a Pentium 4 target. If your processor is not compatible, QZDoom will not start. (Not that it ever did before anyway )

With this, obviously, it means QZDoom's master branch will now operate from ZDoom's ZScript base.

[GFD]

If it's of interest, I tried the q1.1.0 rc1 32-bit build on my old XP machine. GL doesn't work at all, unsurprisingly, as this old PC can't do GL 2.0. Though the error message says GL 2.0 is required to run QZDoom, which isn't true, 'cuz the software modes seem to work okay. Truecolour doesn't work at all though; changing the option has no effect, and the render just stays paletted. Using the poly renderer makes player sprites disappear, for some reason, though the status bar still works fine. Also, the status bar is required, as setting screenblocks to any value above 10 and attempting to render gameplay makes QZDoom vanish without a trace. The poly renderer also draws outside of the allotted area when screenblocks is set lower than 10. Compare: poly on XP, and poly on Win 10. When the player sprites are visible while using the software renderer, they don't appear to be hardware-accelerated at all. This is somewhat surprising, considering that setting vid_hw2d to false and attempting to render gameplay on my Win 10 PC makes QZDoom lock up.

[dpJudas]

Sounds like it runs great! I never added truecolor support to the DirectDraw code, which it sounds like it must be using instead of Direct3D 9.

[Rachael]

Yeah, it sounds like QZDoom isn't running D3D9 code on that machine. But it's good to know Windows XP is working, at least. It's not officially supported - I just compiled it that way because I could. WinXP supports D3D9 just fine - so it sounds like that machine's drivers have not yet been updated to support it. If your machine is properly updated, you should have full d3d9 framebuffer support working just fine - which means you will be able to fully use the poly renderer - player-sprites and all.

Since the poly renderer is still experimental, it will be removed from the menu on the official release - however, it will still be accessible from the console (r_polyrenderer 1). Obviously it is incomplete at this point, but it's good to know you've managed to get some mileage out of it. The devbuilds will keep the poly renderer in the menu, however, and with any luck enough work will be done on it to take it out of the experimental stage.

[Ed the Bat]

All this progress sounds excellent. I've been elbow-deep in ZScript since it became available in any capacity, so I haven't really been able to use QZDoom with my projects. But that should be changing presently, and I'm very much looking forward to not only ZScript in QZDoom (QZScript?), but all the new features QZDoom has gained since I last played with it.

[Rachael]

Yes, the latest official devbuild supports ZScript - however, with the -zscript command-line restriction.

[Ed the Bat]

I've already got the command ready in ZDL, in anticipation. It had just been a few hours since I stopped over to DRDTeam for a new build. Been finding plenty of things on my own to keep working on today. And on a day like this, I need all the distraction I can get...

[Rachael]

My primary compiler system just had a GPU fan that died. It was a gaming GPU (well 8 years ago, anyway) so naturally it cannot run without a fan.

I have a replacement coming but it'll take about a week to show up. In the mean time, I am going to see if I can get the build system going on my laptop (hopefully without frying the hard drive...).

That means no new QZDoom builds until I get this fixed.

[Ed the Bat]

These things happen. Either way, thanks so much for all of your efforts! I'll be patient.

[ZZYZX]

Hi, I ran devbuild QZDoom to look at the polygon renderer and it's quite awesome
But then I ran my map under it and got this, is that bug known?
Also, doomimp looks...downscaled? idk. Noticeable, well, everywhere, but mostly in Entryway, when imps walk in the corridor.

[Rachael]

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++.

[ZZYZX]

(overlapping?) polyobjects do this.
(Control sector texture bleeds into real ceiling)
Also from next room it looks like this.

The map to reproduce this can be found here: http://forum.zdoom.org/viewtopic.php?f=19&t=50593
It's fully software compatible except few visual sloped 3D floors.
Just idkfa and progress into the level a bit, and it'll be really noticeable. Not sure if isolated example is possible.

[Rachael]

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.

It looks like what's happening here is that 3D floors are not being culled if they go too far into the floor/ceiling. That should be reported as a bug. (I could be wrong, though, it's hard to tell from just a screenshot, but I will open the map and look, myself)

[ZZYZX]

Well I do report a bug, I thought it's to be done here, as the first post doesn't say anything on where to report them.
Also, walls near slopes get offset: http://i.imgur.com/4abwk5J.png
I understand that the renderer is incomplete, but can this effect stay please At least as an UDMF flag or smth.

Also, particles are Y-billboarded. These are XY-billboarded in GZDoom.