Duke4.net Forums: Polymost sprite problems - Duke4.net Forums

Jump to content

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

Polymost sprite problems

User is offline   mono20 

#1

I made another small map to show some sprite placements that do not work as good in Polymost as in versions before r5395.

The first room is about shading walls and floors with sprites. This looks much better in r5387 and even perfect in older builds.

The room to the left has a stained glass window with fire and a water fountain behind it. The fire is invisible until you smash the glass (again, in Polymost only!) for a reason I don't know.

I hope this explains itself and it's not just on my system so I didn't add my specs for now.

Thanks for looking
mono20

Attached File(s)


0

User is offline   Mark 

#2

I read some other posts recently about sprites and transparency issues. I think someone is tweaking things in the code. It might need some fine tuning yet.
0

#3

View Postmono20, on 09 November 2015 - 01:20 AM, said:

The room to the left has a stained glass window with fire and a water fountain behind it. The fire is invisible until you smash the glass (again, in Polymost only!) for a reason I don't know.

I hope this explains itself and it's not just on my system so I didn't add my specs for now.


I can confirm the same effect on my machine too.

Also, in rendermode 0, the fires are drawn as if they are in front of the window, again only later versions - this kind of error in general far more pronounced in later versions; attached first image shows sprites breaking through even though they are quite some distance away. Simply moving the railing at the front forward by the absolute tiniest amount possible completely cures it (second image).

BTW, I think you are probably better off shading walls/floors directly rather than using sprites (assuming sprites aren't intended to be destructible), as sprites do have a tendency to vanish at certain angles in software render mode.

TTFN,
Jon

Attached thumbnail(s)

  • Attached Image: capt0005.png
  • Attached Image: capt0006.png

0

User is offline   mono20 

#4

View PostMark., on 09 November 2015 - 04:57 PM, said:

I read some other posts recently about sprites and transparency issues. I think someone is tweaking things in the code. It might need some fine tuning yet.


I know it's something in the making for a while. Each time I try a new EDuke32 build another group of sprites has disappeared... So I'm just the nagging rabbit here :)

View PostThe Mechanic, on 10 November 2015 - 05:44 AM, said:

BTW, I think you are probably better off shading walls/floors directly rather than using sprites (assuming sprites aren't intended to be destructible), as sprites do have a tendency to vanish at certain angles in software render mode.


I think you can't rebuild the given example exactly by just shading walls unless you use TROR or something. The top sprite of the bridge is bright (should have made a stair to it), while the floor under it is made dark using a sprite. By darkening the sector floor directly the bridge would be dark too. The left wall with the window has three zones: below the window, between window and bridge and over the bridge. Without that sprite trick you can't split the shading at the height of the bridge because you can't horizontally split the wall there again. I hope I made it reasonably clear being no native speaker... :)

Greetings
mono20
0

#5

View Postmono20, on 10 November 2015 - 06:44 AM, said:

I think you can't rebuild the given example exactly by just shading walls unless you use TROR or something. The top sprite of the bridge is bright (should have made a stair to it), while the floor under it is made dark using a sprite. By darkening the sector floor directly the bridge would be dark too. The left wall with the window has three zones: below the window, between window and bridge and over the bridge. Without that sprite trick you can't split the shading at the height of the bridge because you can't horizontally split the wall there again.


Ah but you can. The trick is to use very thin sectors - see attached For the left wall I made a thin sector and dropped it's ceiling, for the right wall I created a thin sector and raised it's floor.

Not obvious in the attached map is I added 2048 (0x800) to the two big sprite's 'flags', which you access via the F8 key. This makes the sprites unaffected by the sector brightness (link to wiki page - not sure if this only works in Eduke32).

Of course, the original problem you had here shouldn't happen anyway, however this works around it and is also less problematic when using the software renderer. No workaround for the flame bug though.

View Postmono20, on 10 November 2015 - 06:44 AM, said:

I hope I made it reasonably clear being no native speaker... :)


If you hadn't said so, I wouldn't have guessed you weren't a native speaker. :)

TTFN,
Jon

Attached File(s)


0

User is offline   mono20 

#6

View PostThe Mechanic, on 10 November 2015 - 10:55 AM, said:

Ah but you can. The trick is to use very thin sectors


A clever solution in this place for sure! I will check if I can use the trick elsewhere.


Quote

Not obvious in the attached map is I added 2048 (0x800) to the two big sprite's 'flags', which you access via the F8 key. This makes the sprites unaffected by the sector brightness (link to wiki page - not sure if this only works in Eduke32).


I remember I tried this one a while ago, maybe it was in a sector with lighting effects. It didn't work and I forgot it. I suppose it wouldn't work on e. g. enemies walking on the bridge anyway.


Quote

If you hadn't said so, I wouldn't have guessed you weren't a native speaker.


That's of course what I wanted you to say here... :) Not only for that I tried to vote your post up but the board always says "Action failed: You have reached your quota of positive votes for the day". Maybe I'm not allowed to give votes yet so I can just say thanks for now. :)
0

User is online   Danukem 

  • Duke Plus Developer

#7

It's not just polymost. I'm having the same problem in polymer. In many cases, transparent sprites will completely block the view of sprites behind them, or on the same coordinates.
0

User is offline   Darkus 

#8

View PostTrooper Dan, on 12 November 2015 - 01:05 AM, said:

It's not just polymost. I'm having the same problem in polymer.

Not only polymost/polymer, I replayed E1L5 in classic renderer, until i came here:

Posted Image
1

User is offline   Helixhorned 

  • EDuke32 Developer

#9

View PostDarkus, on 13 November 2015 - 04:06 AM, said:

I replayed E1L5 in classic renderer, until i came here:

Posted Image

Introduced in r5400. TX, we certainly don't want the sprites LASERLINE__STATIC .. COOLEXPLOSION1__STATIC (referring to the order in which they appear in game.c: G_DoSpriteAnimations()) being omitted from sorting. (Or rather, what happens AFAICS is that they are split in two groups, with each group keeping the order among the elements. That's just as wrong, though.)

What's the intention of bit 1024? A sprite that is "drawn without depth after all other sprites have been drawn" cannot really be at an arbitrary position after all; you'd have to guarantee that there are no sprites in front of it from the POV of the camera.
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