[Danukem]

This is not the same as the missing triangle problem. Look at these screens:


First, in the classic renderer (rendered correctly)



Here we have a transparent (cstat 2) sprite from the shrinker explosion animation being drawn on the same coordinates as a frozen enemy. It is supposed to look like a roundish block of ice surrounding the enemy (nevermind whether it looks like crap, the point is it is rendered correctly). You can fully see the solid enemy, which takes priority over the transparent "ice" sprite.

Now, here is the exact same scene rendered in polymost



Even though the "ice" sprite is transparent (you can even see the walls behind it), it completely blocks the view of the solid enemy sprite on the same coordinates. This is wrong! Oh, so wrong... It has been a thorn in my side for a while now. You can also see this happening in polymost with transparent smoke sprites (or indeed any transparent sprites under the right conditions). I wish I knew when this problem started. Unfortunately, I have changed over all my code to use shortcuts such as geta[] instead of getactor[THISACTOR], so I get errors when going back far enough to find where the renderer got broken.

[Hendricks266]

I think this problem has always been here. It's algorithmic due to the way depth buffers work. Translucency is hard. The solution would require a little bit of extra infrastructure.

[Danukem]

Hendricks266, on 08 May 2017 - 12:17 PM, said:

I think this problem has always been here.

Nope, I have just confirmed that it was introduced in revision 4696

I used bisection and tested the builds in synthesis to confirm. Interestingly, that first build where the rendering goes awry only had a debug build of EDuke32 included with no release notes...

What we see in the older builds is rendering behavior consistent with current polymer behavior. It is not perfect -- in the test case, there is some flickering with the ice sprite occasionally blocking the monster sprite, but in general it is much, much better than current polymost behavior.

I am even going to attach the code I am using for testing. I ripped out the chunk pertaining to the ice sprite and made it verbose so it will compile on older builds. If you freeze monsters, the ice will spawn on them.

Attached File(s)

•  EDUKE.rar (21.38K)
  Number of downloads: 103

[Danukem]

I have a workaround, now. It turns out that moving the transparent sprite ever so slightly farther away from the camera than the sprite it is on top of eliminates the problem. Manipulating the tsprite rather than the game-world sprite works just as well, and is the better solution. No flickering at all -- it looks just like it should.

onevent EVENT_ANIMATESPRITES

gettspr[].tsprowner spriteid
switch sprite[spriteid].picnum
case ICESPRITE
	ifn rendmode 0
	{
		geta[spriteid].x x
		geta[spriteid].y y
		ifl camerax x add x 4
		else sub x 4
		ifl cameray y add y 4
		else sub y 4
		settspr[].tsprx x
		settspr[].tspry y
	}

[ToiletDuck64]

Quote

moving the transparent sprite ever so slightly farther away from the camera than the sprite it is on top of

Maybe this is just me, but I think that moving a sprite to a closer/farther distance from the camera might cause unwanted side effects when something else requires the sprite to be at the correct distance.
As an alternative...is it possible to make certain sprites automatically "win" or "lose" when it comes to priority over other sprites at exactly the same distance? (I'm imagining some kind of "tiebreaker" mechanism...) If so, then that might be a better solution.

[Danukem]

ToiletDuck64, on 09 May 2017 - 01:14 AM, said:

Maybe this is just me, but I think that moving a sprite to a closer/farther distance from the camera might cause unwanted side effects when something else requires a sprite to be at the correct distance.
As an alternative...is it possible to make certain sprites automatically "win" or "lose" when it comes to priority over other sprites at exactly the same distance? (I'm imagining some kind of "tiebreaker" mechanism...) If so, then that might be a better solution.

That's not possible using CON code -- I even tried using the 1024 cstat bit (the experimental one that is supposed to make a sprite high rendering priority) to no effect.

What I found is that there is bad behavior only when the sprites are on EXACTLY the same coordinates. Moving one to the front yields the correct results. If the transparent sprite is in the front, you can see through it to the solid one in back, and if the solid one is in front, then you can see it and the one in back is transparent.

Side effects are possible, but you should consider just how small 4 build x/y distance units are. Duke's RETRIEVEDISTANCE is 844, which is how many build units away (measured from his feet) that he is able to pick up items. If RETRIEVEDISTANCE feels like about a meter, then 4 build units is less than half of one centimeter. And while I didn't test it, I'm pretty sure the technique would work with 2 units, or maybe even 1, which means we are talking about just a few millimeters. That's a distance so small it would be imperceptible to the player.

[Mark]

I guess I should have spoke up right away. I read your original post not long after you posted it. The first thing that popped out to me was that you said both sprites were at the same co-ordinates. I was going suggest pressing L to unlock the grid and move one of the sprites the tiniest bit forward. I assumed you would have tried it already so I stayed silent.

[Danukem]

Mark., on 09 May 2017 - 09:16 AM, said:

I guess I should have spoke up right away. I read your original post not long after you posted it. The first thing that popped out to me was that you said both sprites were at the same co-ordinates. I was going suggest pressing L to unlock the grid and move one of the sprites the tiniest bit forward. I assumed you would have tried it already so I stayed silent.

No, it's a coded effect, not spritework. When one actor spawns another, the spawned actor starts on the same coordinates, which is desirable. Now that we have the transparancy bug, mappers can make sure not to put sprites on the same coordinates and coders can do extra work and move spawned sprites around, but that doesn't help all of the maps and mods made throughout the history of the game before this was a bug, or in cases where people just haven't identified the problem. Even the vanilla game uses quite a bit of sprites spawning other sprites directly on top of themselves.