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

[Nash]

Me and undead003 plan to do a coop playthrough with QZDoom's TC renderer probably later today or over the weekends. Haven't decided what WAD yet (I was thinking of a made-for-GZDoom mod that doesn't rely on models or dynamic lights) but I'm looking forward to it!

EDIT: courtesy quote

I finally got a chance to sit down and try this out. I am absolutely impressed. It looks so smooth, and bright, and colorful, like GZDoom, and yet the sprites aren't being clipped; a combination I've wanted for some 8+ years but never thought I'd actually see. If y-shearing could be defeated, I'd make a full switch over to this renderer without hesitation. Heck, I'd be tempted to already, were it not for the headaches/nausea it gives me...

[Rachael]

I'd like to get rid of the y-shearing as well, but that's not as easy as it sounds. There is only one real way to do this with the existing renderer and that is using some sort of perspective warp - whether applying it to the drawing canvas, or to the column drawers themselves. Both are ugly hacks. Both will take lots of time to code. >_<

Or another way is just to switch to polygonal rendering ... but then you won't easily get the sprite non-clipping.

(I was thinking of a made-for-GZDoom mod that doesn't rely on models or dynamic lights) but I'm looking forward to it!

Skyboxes aren't in yet, either... although you can fudge it in using a custom sky pretty easily, for now.

[Ed the Bat]

Oh trust me, I never thought it sounded easy. After all, if it was easy, it would've been soundly defeated decades ago, I'm sure. No one y-shears by choice, right? I honestly blame myself more, since it seems to be a rather unique problem to get motion sick from it. No one else I talk to has that problem.

[Rachael]

Motion sickness or not, it's still pretty ugly, but I suppose you're right somebody would've come up with a solution by now for 2.5D engines if it were in fact easy.

ZDoom's polymost renderer was going to handle that to some extent, as well - maybe, someday, I should resurrect that. (Necrocoding? >_>) But in the end, there was a reason why it was abandoned, although it's nothing I can't learn from if I look at it, I am sure.

The thing here is - if it wasn't for Doom's rendering tricks, like sprites inside the floor, flatfills, and other unique things like that, I would have already switched it to a polygonal back-end myself.

[Someone64]

Oh trust me, I never thought it sounded easy. After all, if it was easy, it would've been soundly defeated decades ago, I'm sure. No one y-shears by choice, right? I honestly blame myself more, since it seems to be a rather unique problem to get motion sick from it. No one else I talk to has that problem.

Oh, don't worry. You're not the only one. I almost vomitted for real thrice trying to play with software renderer with freelook before.

[Gez]

You can look at DelphiDoom for perspective warp code.

DD has the most interesting software renderer in Doom ports since Vavoom dropped its Quake-derived one. Probably the most underrated source port IMO.

[Rachael]

It might be worth looking at that source code, but I am not 100% sure. Considering it is written in another language entirely, there's likely the opportunity that the renderer was rewritten at some point, which means if that was done any methods used would be useless for QZDoom. I'll take a look when I am a little more awake.

[ZZYZX]

ZDoom's polymost renderer was going to handle that to some extent, as well - maybe, someday, I should resurrect that. (Necrocoding? >_>) But in the end, there was a reason why it was abandoned, although it's nothing I can't learn from if I look at it, I am sure.

Pretty sure the reason why polymost was dropped is because no one wanted to write texture mapping code, as original polymost didn't need it (it outputted triangles into OpenGL).
I mean, I don't think it's related to the fact that there are no rendering tricks in polymost.

... but then you won't easily get the sprite non-clipping.

I've once been thinking of this algorithm (for each subsector, assuming things are drawn strictly back to front):
1. draw floors and ceilings, don't write into Z-buffer
2. enable Z-buffer writing
3. for each 2-sided wall with differing heights at it's sides, draw infinitely tall invisible (but solid in Z-buffer) quad starting at real height and up (ceiling) or down (floor); this is used to clip solid geometry against ledges
4. draw solid geometry (top/bottom textures of 2-sided walls, 1-sided walls)
5. draw 3D floors
6. draw non-solid geometry (sprites, masked walls)

Didn't try, but it should work for Doom-like sprite handling where floors don't clip things directly.
Walls will still clip though, but pretty sure this is possible to fix with Z-buffer hacks as well (or just using polymost method, where you calculate clipping manually and then just output polygons into OpenGL for rendering).
And either way walls aren't that important compared to planes.

P.S. just saying, the above list should work even on the most ancient OpenGL versions, so not sure why it wasn't implemented and instead esoteric smart clipping logic was introduced.
Especially when people were using glBegin/glEnd actively and drawcall optimization was nonexistent.
Would be nice to have some person that understands OGL comment this.

[Kizoky]

Is this a bug?

---

Also, I haven't encountered any crashes so far, looks way more pretty than ZDoom

[dpJudas]

No, that is not a bug. It's switching from one mipmap level to another. If you don't like that effect, you can turn mipmapping off in the menus. Note that the side effect of doing that is more aliasing in the distance.

[DOOMERO-21]

exist a windows xp version?

[Marisa the Magician]

I will be building and testing this both on my desktop and on my laptop.

[Rachael]

exist a windows xp version?

At the moment I do not have a build environment set up for Windows XP compatibility. You'll have to ask Blzut3 if he's willing to add this project to his auto builds, or ask someone else for help with that. You're the only one who's even asked so far.

[DOOMERO-21]

exist a windows xp version?

At the moment I do not have a build environment set up for Windows XP compatibility. You'll have to ask Blzut3 if he's willing to add this project to his auto builds, or ask someone else for help with that. You're the only one who's even asked so far.

yeah, because when i execute qzdopom.exe appear a window with the message of a non valid win32 application.

[Rachael]

Because of the amount of work required for me to officially support and target the Windows XP platform (which is, as of now, 30 months deprecated) I will not officially support or give more than minor assistance to getting it working.

But because I am a nice girl, I went and researched this and have seen that it might be possible - but it's a question of API compatibility whether or not this even works. QZDoom is compiled with the DirectX for Windows 10 API, which means it probably will not start on your system (but you can try +vid_used3d false just to see).

The application you're looking for is http://www.ntcore.com/exsuite.php - what you will need to do is search for a field called "Minimum OS version" - change this from 6 (Vista/7/8/8.1) to 5 (Win2000/XP). This will eliminate the "Not a Valid Win32 application" error - but other errors may result. If it works, please do let us know.

Beyond that, I really hope someone can help you with this, because I do not have a Windows XP system to test this on, and right now I have other things I need to deal with so I cannot devote the proper time to get this working.

EDIT: A hex editor may work, also.

In qzdoom.exe - change the following:

Code: Select all

Offset 0x00000180: Change 06 00 00 to 05 00 01
Offset 0x00000188: Change 06 00 00 to 05 00 01

I found this method on another site. This may also work, as well.

Here's a pre-patched EXE for q0.2pre-57-g64ae207 for you to try.