[r2018] Stacked sprites flicker

[Janizdreg]

If several actors with a visible sprite are in the exact same spot their sprites flicker whenever any other sprites enter the player view. It basically seems as if ZDoom couldn't decide which of the stacked sprites to draw in the foreground and which in the background, switching between them whenever other sprites show up in the player's view.

I whipped up a little sample Doom II MAP01 wad for reproducing the bug. Just make sure you have rocket trails enabled, pick up and equip the rocket launcher right at the start, fire it and watch the stacked gib piles and rocket launchers flicker at an insane rate.

[Graf Zahl]

Even more interestingly, even when it works ZDoom tends to get the order wrong. I have seen it on several maps that stacked sprites are not shown correctly and the one that's supposed to be hidden can be seen.

Doom.exe seems to always draw the sprite with the higher map index first.
Anyway, I wonder if fixing this won't cause other problems but so far I've seen sprite stacking on vanilla maps only.

[Enjay]

Can't see the WAD ATM. I can think of a few maps where items are placed in the same location. From memory, one of Kurt Keslers Zdoom maps (Kbase7?) has a few piles of pickup dotted around the place. Is this the kind of situation that is being referred to?

[Graf Zahl]

If it's all the same item there is no problem. Since both sprites look the same any interference won't be visible. It's when different items are stacked.

[Enjay]

Again from memory, he does use different items - eg a medkit and some ammo or an armour helmet or two.

[randi]

Fixed. Doom used a stable (but slow) sort. ZDoom replaced it with qsort, which is not stable. Replacing that with the STL's stable_sort was a simple matter.

[Graf Zahl]

I did some tests with this and discovered something interesting:

All source ports I checked seem to invert the sorting order of sprites with equal distance. This is easily checked with Strain MAP13. There's one room behind the start where some torches are placed overlapping with red pillars. This is supposed to make it look like a flame on the pillar.

Another WAD where this can be noticed is Astrostein. In some levels it uses shootable lamps but does it rather hacky by placing 2 actors at the same spot, one for the working lamp and one for the destroyed version. But with all these ports only the destroyed version is visisble due to the sorting.

This works correctly in Chocolate Doom but ZDoom, PrBoom and ReMood (standing in for Legacy which I refuse to use) all do this wrong. Since obviously an unconditional change is out I added a compatibility option for this to restore the original sorting.

[randi]

Considering that intentionally overlapping sprites was never viable before, why does it need to be a compatibility option to reverse their order before sorting?

[Graf Zahl]

Because it doesn't look right in the maps I listed without it. Just have a look.

In Strain MAP13 it's the room right behind the start (noclip there and you'll find 7 pillars with torches) and in Astrostein one such lamp can be found in MAP06 at (-224, -864)

And it's reproducably different in Chocolate Doom and Doom.exe. I wouldn't have added the option if I hadn't done careful tests with and without it.

Reversing the order before sorting just ensures that all sprites with equal distance appear in reversed order in the sorted list which is the result I intended.


I would have done it without the option if all ports behaved the same. However, it looks that Boom already switched the sorting order without anyone ever noticing.

[randi]

Yes, that's what I was attempting to say. Why make a compatibility option of it when you can just make it the standard behavior?

[Graf Zahl]

I have no idea if there's any map which requires it the other way around. I was just careful. But after trying to find some WADs with overlapping sprites that need it reversed I have to come to the conclusion that the option is probably unnecessary. Everything I have seen so far needs the option on.

[Graf Zahl]

I have found a handful of Boom maps which place overlapping inventory items with the inverse-to-vanilla order in mind.

So I don't think removing the option is ok but it may make sense to invert its logic so that the vanilla behavior is the default. The amount of vanilla-compatible maps requiring this active is certainly a lot higher than the small amount of Boom maps mentioned above.