r667 Sprite transparency bug still present

Bugs that have been resolved.

Moderator: Graf Zahl

Locked
User avatar
Enjay
Developer
Developer
Posts: 4748
Joined: Tue Aug 30, 2005 23:19
Location: Scotland
Contact:

r667 Sprite transparency bug still present

Post by Enjay »

Wasn't sure whether to open a new bug report for this or not but seeing as how the old one is closed:

Code: Select all

- fixed: Drawing walls with textures containing translucent parts did not reenable the alpha test afterward.
Image

:(
User avatar
Enjay
Developer
Developer
Posts: 4748
Joined: Tue Aug 30, 2005 23:19
Location: Scotland
Contact:

Re: r667 Sprite transparency bug still present

Post by Enjay »

This might cast some light on the problem. This screenshot was taken at the start of a cutscene:

Image

As you can see, all the sprites have black boxes. However, once they start attacking each other:

Image

Most of the boxes have vanished. They flickered on and off during the fight and when it was finished, all the boxes returned. (This pic was taken on a second viewing - hence the different ammo amounts - but the same thing happened both times.)

Image

The file is "Infernal War" in /newstuff right now.

ftp://ftp.fu-berlin.de/pc/msdos/games/i ... infwar.zip

Warp to map05 and "kill monsters". After a few seconds, the cutscene will start.

Video:
http://www.rowand.myzen.co.uk/graf/sprite_edges.wmv
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: r667 Sprite transparency bug still present

Post by Graf Zahl »

Damn. There must be another problem lurking somewhere...
jbailey8
Posts: 30
Joined: Sat Dec 26, 2009 3:29

Re: r667 Sprite transparency bug still present

Post by jbailey8 »

I can confirm (at least on my system) that this bug is still present.
Here's all the other info:

System:

AMD Athlon 3000+ 64-bit processor
3 - gigs of DDR 400 ram
Nforce4 on-board audio processor
Nvidia 8800GT with 320 megs of video memory
Windows XP 64-bit OS
All drivers are current.

-----------------------

Compiler - Microsoft Visual Studio 2005

SVN revision: 674 (there is a 'M' after this number, I didn't change any of the source files though).

Video illustrating the bug - http://www.youtube.com/watch?v=lsWDwi4XZMY

Wad File - 'ThunPeak' - get it here - ftp://ftp.fu-berlin.de/pc/msdos/games/i ... unpeak.zip

Savegame - none required, just load in the wad file and start a new game.
User avatar
Enjay
Developer
Developer
Posts: 4748
Joined: Tue Aug 30, 2005 23:19
Location: Scotland
Contact:

Re: r667 Sprite transparency bug still present

Post by Enjay »

jbailey8 wrote:Video illustrating the bug - http://www.youtube.com/watch?v=lsWDwi4XZMY
Youtube wrote:This video is private.
But yes, it seems to be pretty common. I've found it on lots of levels now. Another example:

Released in this thread:
http://www.doomworld.com/vb/wads-mods/4 ... d-xmas-dm/

Directl link:
http://www.4shared.com/file/180568897/4 ... _Xmas.html

MAP03 shows the problem but I don't think other maps do. :?

Image

That's with r676.
jbailey8
Posts: 30
Joined: Sat Dec 26, 2009 3:29

Re: r667 Sprite transparency bug still present

Post by jbailey8 »

Sorry for the private problem on youtube, I'll fix that now.
User avatar
Enjay
Developer
Developer
Posts: 4748
Joined: Tue Aug 30, 2005 23:19
Location: Scotland
Contact:

Re: r667 Sprite transparency bug still present

Post by Enjay »

OK, a little bit of progress I think. Line_Horizon is somehow involved. I decided to try and cut out the area from infernal war that reliably showed the problem (attached) and investigate it. I noticed that as I moved so that I could no longer see the horizon, the black boxes vanished. Then, as I turned back towards the horizon, they reappeared.

On an editing the map (not attached) removing the special from the Line_Horizon lines stopped the black boxes appearing.

This doesn't explain (to me anyway) why the black boxes would flicker on and off when the enemies were fighting but it's a start. If you want to wake the enemies, just puke script 1 which is nothing more than "Thing_Activate (27);".
black.zip
(3.01 KiB) Downloaded 26 times
[edit] Yes, I have now checked a number of maps and each one that showed the problem had Line_Horizon lines in view when the problem occurred. Also, adding Line_Horizon lines to maps that were previously OK (eg I tried with map01 of Doom2) makes them have the problem when the horizon is in view.

[spoiler]Image
The area outside has been given a Line_Horizon special. Note how the imps have black boxes but the fireballs do not. Presumably that is something to do with bright sprites or translucency[/spoiler]
[/edit]
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: r667 Sprite transparency bug still present

Post by Graf Zahl »

This problem happens because the alpha test is off when these sprites are drawn. Normally that should not happen and it is an undefined state. Apparently when it flickers something gets drawn in between that changes this states and restores it to its proper setting.
User avatar
Enjay
Developer
Developer
Posts: 4748
Joined: Tue Aug 30, 2005 23:19
Location: Scotland
Contact:

Re: r667 Sprite transparency bug still present

Post by Enjay »

I don't see anything in the changelog that specifically related to this bug:
Changelog for r677 only wrote:- Minor cleanup.
However, I've just had a quick look at a couple of maps that previously showed the bug and they seemed OK in r677. Has it been addressed or is it just luck masking the problem somehow?
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: r667 Sprite transparency bug still present

Post by Graf Zahl »

Your analysis was right on spot. The horizon portals were the cause, albeit indirectly. The horizon drawer disabled the alpha test and the translucent pass did not re-enable it. I added code for that yesterday but forgot it before committing my cleanup stuff today so I didn't add it to the log.
Locked

Return to “Closed Bugs”