I realise you are probably in no position to look at this, and that the recent changes may have made this irrelevant but I noticed it and if I don't report it I'll forget it and, who knows, it could be important.
When you are using the burn wipe style, sometimes the screen fades to white rather than an image of the screen. It seems to be pretty easy to get it by starting a few games (never seems to happen with the first time you do it) and it can happen between levels as well.
I recorded a video of the effect because it's easier than explaining.
http://www.rowand.myzen.co.uk/burnfade.wmv
[fixed at last!] 1.0.32 Burn wipe style goes white
Moderator: Graf Zahl
-
Enjay
- Developer
- Posts: 4748
- Joined: Tue Aug 30, 2005 23:19
- Location: Scotland
- Contact:
-
Graf Zahl
- GZDoom Developer
- Posts: 7148
- Joined: Wed Jul 20, 2005 9:48
- Location: Germany
- Contact:
-
Graf Zahl
- GZDoom Developer
- Posts: 7148
- Joined: Wed Jul 20, 2005 9:48
- Location: Germany
- Contact:
Re: 1.0.32 Burn wipe style goes white
I'm moving this to 'vexing bugs' for now.
I'm sorry but as much as I'd like to have this fixed (Burn is my preferred wipe style) I have absolutely no clue why it doesn't work unless a new texture is being created. If someone with more experience can give me a hint I'd appreciate it very much.
I'm sorry but as much as I'd like to have this fixed (Burn is my preferred wipe style) I have absolutely no clue why it doesn't work unless a new texture is being created. If someone with more experience can give me a hint I'd appreciate it very much.
-
Graf Zahl
- GZDoom Developer
- Posts: 7148
- Joined: Wed Jul 20, 2005 9:48
- Location: Germany
- Contact:
Re: 1.0.32 Burn wipe style goes white
I can finally retire this report. 
After all this time I was just ready to rewrite this effect to use a shader. And guess what: While rewriting the code I found the reason for this bug because with the shader based version it manifested itself just differently but a lot easier to analyze.
When a texture is bound the texture class keeps track of the GL texture ID which is used in each texture unit. However, for wipe textures these get deleted right after use and recreated in the next frame.
Normally this isn't an issue. Here, however it just happened that the second texture unit was not used for anything else so the last bound ID was kept even though the texture no longer existed.
Now, when wiping twice without any new textures being created the new textures got the same ids as the old ones which no longer existed. The result was that the texture manager thought that the currently set texture was still valid even though it wasn't.
After all this time I was just ready to rewrite this effect to use a shader. And guess what: While rewriting the code I found the reason for this bug because with the shader based version it manifested itself just differently but a lot easier to analyze.
When a texture is bound the texture class keeps track of the GL texture ID which is used in each texture unit. However, for wipe textures these get deleted right after use and recreated in the next frame.
Normally this isn't an issue. Here, however it just happened that the second texture unit was not used for anything else so the last bound ID was kept even though the texture no longer existed.
Now, when wiping twice without any new textures being created the new textures got the same ids as the old ones which no longer existed. The result was that the texture manager thought that the currently set texture was still valid even though it wasn't.