GZDoom Software Rendering Question

[Captain Keen]

Hi, long time reader, first time poster.

 

I've noticed that newer versions of GZDoom (after 4.3-ish) have a weird visual quirk in the software rendering. If you look at torches, or evil eyes, you'll see that the entire texture is kind of jumping up and down. In older versions of GZDoom, along with zDoom and QZ/LZDoom, this isn't the case.

 

Anyone know why this happens, or if there's a way to fix it? It's something that once I noticed it, I can't unsee it! Has anyone else noticed this or am I completely OCD and crazy?

 

(Also, if you run Smooth Doom with software rendering, it fixes this issue.)

[Biodegradable]

I've experienced this myself. If you're seeing certain props or things bobbing up and down, toggle your Sprite Clipping setting. When I had this happen I had it set to Smarter and found bumping it down to Smart sorted it out.

Edited February 7, 2021 by Biodegradable

[Gez]

Sprite clipping settings should be irrelevant for the software renderer, though.

[Captain Keen]

14 hours ago, Biodegradable said:

I've experienced this myself. If you're seeing certain props or things bobbing up and down, toggle your Sprite Clipping setting. When I had this happen I had it set to Smarter and found bumping it down to Smart sorted it out. 

 

Yeah, unfortunately that doesn't affect software settings, but you're absolutely right, and I've definitely fiddled with those settings for hardware rendering. Thanks for the suggestion.

 

It's weird, I went back and looked at it, and it seems like each software renderer has its own quirks. For example...

 

In zDoom, you have all the slimetrails from the original games, plus some weird white lines like on doorways (E1M3 opening, for example).

 

In QZ/LZDoom, those above issues are fixed, but now you have weird seam lines with certain textures. The skull switch in level 30 (Icon) of Doom II is a good example.

 

In GZDoom 4.3 and up all of those above issues are fixed, but now it has the issues with dancing pixels on torches and evil eyes that weren't there in zDoom or QZ/LZDoom.

 

TL;DR I have no idea why this is the case! I wouldn't even call it a bug, just a visual quirk. If anyone out there has worked on GZDoom, I'd love to hear your thoughts on why this happens and why the software renderer is so different between these various versions. Clearly something is going on under the hood. Beyond everything else it's just interesting to me, and not so much a problem but just a quirk.

 

 

[Captain Keen]

Well, it appears over on the ZDoom page someone else has noticed this, and offered up some thoughts.

 

The link: https://forum.zdoom.org/viewtopic.php?f=56&t=68042

 

The comment:

 

"I've done the bisect using devbuilds, it's much faster.

The first commit affected was:

Code: Select all

- change ProjectedWallTexcoords to use gradients for its texture coordinate calculations
- change SpriteDrawerArgs to draw a full sprite instead of one column at a time
- add r_noaccel cvar to allow forced software rendering of the psprites (useful for debugging and also one person on the forum actually requested this feature)
- remove FWallTmapVals and calculate texture coordinates directly from FWallCoords
- move portal clipping out of the inner sprite drawing loop

 

And of course i've got no idea of what's going on, there are a lot of changes there. Seems only fire braziers and wall torches are affected (and Doom torches too), what makes them so special?"

[dpJudas]

The dancing sprites effect is caused by rounding errors when sampling from textures or when deciding which screen pixels are covered by a wall/flat/triangle. ZDoom has (or had? can't remember if my fix made it into zdoom itself) those rounding errors, I then fixed them back in the day, and then I apparently managed to break it again in that commit.

 

In ZDoom it wasn't only the sprites that were affected btw. The midtextures in particular had a tendency to wrap too early. Same thing happened with flats (the teleporters made out of 4 textures at the end in E1M8 is the most obvious example of that). Also the general stability of the picture when moving around is much better without those rounding errors.

 

In short: this bug could probably be fixed by adding +0.5f or removing a +0.5f a single place somewhere in the sampling or screen column/row code. Maybe one of the active GZDoom developers will do that, though I don't think you should put too much hope into that. Most of them only seem to be interested in the hardware renderer.

Edited February 10, 2021 by dpJudas

[Captain Keen]

4 hours ago, dpJudas said:

In short: this bug could probably be fixed by adding +0.5f or removing a +0.5f a single place somewhere in the sampling or screen column/row code. Maybe one of the active GZDoom developers will do that, though I don't think you should put too much hope into that. Most of them only seem to be interested in the hardware renderer.

 

Thank you for the reply! That all makes sense.

 

Ok, so now a question born from ignorance: how does one go about changing this in the actual GZDoom build? Who controls when new releases happen? I believe it's now on version 4.5.0.

 

4 hours ago, dpJudas said:

Maybe one of the active GZDoom developers will do that, though I don't think you should put too much hope into that. Most of them only seem to be interested in the hardware renderer. 

 

That's too bad. I prefer the software renderer for the original games or vanilla-y megawads without mods. It doesn't look like there's any way to contact them on their page, it's just another forum like this one.

 

I don't actually know the names of the people who are most responsible for ZDoom and GZDoom, although it is (by far) my favorite source port. How much of this is a community effort à la Linux where anyone can add some changes to the code? Or is it really a few specific gatekeepers who control everything? Alas I don't know much about that specifically. I haven't coded in C++ or anything in over 10 years, so changes beyond anything very basic are beyond my pay grade.

[Shepardus]

2 hours ago, Captain Keen said:

I don't actually know the names of the people who are most responsible for ZDoom and GZDoom, although it is (by far) my favorite source port. How much of this is a community effort à la Linux where anyone can add some changes to the code? Or is it really a few specific gatekeepers who control everything? Alas I don't know much about that specifically. I haven't coded in C++ or anything in over 10 years, so changes beyond anything very basic are beyond my pay grade.

GZDoom is on GitHub and accepts pull requests there.

[Redneckerz]

@Captain Keenyou can post as a guest on the zdoom forums.

[Captain Keen]

1 hour ago, Redneckerz said:

@Captain Keenyou can post as a guest on the zdoom forums. 

 

I will give that a shot, thanks.

[Captain Keen]

It gave me the name "Henry Cunkinwitch"!

 

Here's the link: https://forum.zdoom.org/viewtopic.php?f=56&t=71441

 

(I tried to edit my above comment here but it didn't seem to like my "reason" for the edit. I'm new to these forums, so not quite sure how you get it to accept a change.)

[drfrag]

Now you're "Hugh Bomblepin" and i've merged the topics (else it would have been closed as duplicate). Now it's here: https://forum.zdoom.org/viewtopic.php?f=56&t=68042&p=1181321#p1181309

[Captain Keen]

Thank you @drfrag! Rachael responded with this:

 

"I'm taking a look at this. I think I have a decent idea of exactly where to add said 0.5's, if I get it to work I'll close this topic accordingly. I'm just posting this before something drastic does happen, like reverting that entire commit."

[Captain Keen]

Ok, so one other question. Once something is fixed, and you go to the changelog and have a file like: src/rendering/swrenderer/things/r_wallsprite.cpp

 

How do you add that into the current gzdoom build, which is still 4.5.0? Or will there eventually be a new release that includes all fixes?

 

The last official build is from Halloween 2020, but there are numerous changes since then in the changelog. How does this typically work?

 

Here's the changelog link: https://zdoom.org/changelog

 

(I can't tell if this specific issue has been fixed yet, the topic is closed but I don't see the actual fix in the changelog yet.)

[dpJudas]

Easiest way for you test those fixes is to download the latest nightly build from https://devbuilds.drdteam.org/gzdoom/ - all those changes will eventually make it to the next release.

[Captain Keen]

@dpJudas Thank you again, I will do exactly that.

 

Any idea what the MO is for deciding when to update the official builds? Is it just after a certain amount of time passes, or kinda random?

[Redneckerz]

26 minutes ago, Captain Keen said:

@dpJudas Thank you again, I will do exactly that.

 

Any idea what the MO is for deciding when to update the official builds? Is it just after a certain amount of time passes, or kinda random?

When the team decides its stable enough to move to a new version number.

[Captain Keen]

I can report that the issue is fixed! Thanks to everyone -- especially @dpJudas, @drfrag and Rachael.