[Fixed] Dancing torches in Heretic on Carmack

[drfrag]

HEAD, latest master, last SVN. Now they move, since g4.3pre-358-g236b47693.
It's specially noticeable with the two braziers? (statues) near the start in E1M1. Is this a known problem?

[drfrag]

For now i know that the issue was present in 4.3.1 and not in 4.2.4 but that's not much.

[drfrag]

I've done the bisect using devbuilds, it's much faster.
The first commit affected was:

Code: Select all • Expand view

- 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


https://github.com/coelckers/gzdoom/com ... 96b7817952

[drfrag]

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?

[Hugh Bomblepin]

I saw another post about Heretic from drfrag, but I have also noticed this "dancing sprite" bug in Doom. It's a new problem starting with version 4.3 and up. If you look at an older version of GZDoom, or QZ/LZDoom, the problem isn't there (but other bugs that have since been fixed still exist in those older versions). It specifically affects objects like the skull torches, evil eyes and beating hearts. It doesn't seem to affect the skulls with candles. Can this get fixed for the next build of GZDoom?

I posted this bug on the Doomworld forums, and got this response from 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..."

[drfrag]

I've merged the topics. The Doomworld thread is here: https://www.doomworld.com/forum/topic/1 ... -question/
That hint is very generic and i'm not the smartest guy around here.

[Graf Zahl]

Unfortunately that's a hefty commit that changes stuff in a way where I cannot even see anymore what the point of it all was. Overall I tend to agree with the assessment that this is a problem with the rounding math - and aside from reverting the software renderer to an older state from before this commit I really see no way to get it fixed easily - provided that even works with all the other changes to the render code.

[drfrag]

It's a minor thing anyway and the effect must be due to the heavy height changes in those sprites. That commit introduced other problems but luckily somehow i managed to fix the lightning for the player weapon sprites. Fixing this requires a good knowledge of the software renderer and i don't think adding and removing 0.5s everywhere by trial and error will help.

[Rachael]

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.

[Graf Zahl]

That commit is far too big to be reverted. It's also far too big for anyone without in-depth knowledge of how software rendering works to find the problem.

[Hugh Bomblepin]

Rachael and drfrag, this is Captain Keen from Doomworld (er, Hugh Bomblepin?)

Thank you!!

[drfrag]

@dpJudas: Thanks very much for the fix, you rule!

[dpJudas]

You're welcome.

[Hugh Bomblepin]

This is Captain Keen again. I just tried out the latest pre-release build, and the issue is indeed fixed. Thank you!!