Duke4.net Forums: polymost rendering transparency wrong (blatent example) - Duke4.net Forums

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

polymost rendering transparency wrong (blatent example)  "see below"

User is online   Danukem 

  • Duke Plus Developer

#1

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


First, in the classic renderer (rendered correctly)

Posted Image

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

Posted Image

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.
0

User is offline   Hendricks266 

  • Weaponized Autism

  #2

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.
0

User is online   Danukem 

  • Duke Plus Developer

#3

View PostHendricks266, 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)

  • Attached File  EDUKE.rar (21.38K)
    Number of downloads: 63

0

User is online   Danukem 

  • Duke Plus Developer

#4

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
	}

2

#5

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.

This post has been edited by ToiletDuck64: 09 May 2017 - 01:16 AM

0

User is online   Danukem 

  • Duke Plus Developer

#6

View PostToiletDuck64, 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.
1

User is offline   Mark 

#7

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.

This post has been edited by Mark.: 09 May 2017 - 09:22 AM

0

User is online   Danukem 

  • Duke Plus Developer

#8

View PostMark., 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.
0

Share this topic:


Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks not owned by Voidpoint, LLC are the sole property of their respective owners. Play Ion Fury! ;) © Voidpoint, LLC

Enter your sign in name and password


Sign in options