[1200 et al] sprite transparency problem
Moderator: Graf Zahl
- NeoHippo
- Posts: 408
- Joined: Tue Sep 13, 2005 0:47
- Location: British Columbia Canada
[1200 et al] sprite transparency problem
I really do not know if it is a problem with GZDoom or with myself not understanding something.
I'm trying to understand the TEXTURES lump in regards to sprites.
Here are the images:
normal sprites in ZDoom
normal sprites in GZDoom
ICEyfied sprites in ZDoom
ICEyfied sprites in GZDoom this one shows the problem I'm having
Several times I had a go at setting the transparent colour of the sprites in question, but always the same result.
and both maps:
normal
ICEyfied
I'm trying to understand the TEXTURES lump in regards to sprites.
Here are the images:
normal sprites in ZDoom
normal sprites in GZDoom
ICEyfied sprites in ZDoom
ICEyfied sprites in GZDoom this one shows the problem I'm having
Several times I had a go at setting the transparent colour of the sprites in question, but always the same result.
and both maps:
normal
ICEyfied
Last edited by NeoHippo on Wed Mar 25, 2009 0:32, edited 2 times in total.
TAtL, tU, aE
- Enjay
- Developer
- Posts: 4748
- Joined: Tue Aug 30, 2005 23:19
- Location: Scotland
- Contact:
Hmmm, I don't know. I can't see anything obvious wrong with your images on checking them in PSP. Zdoom and XWE seemed to give them a clean bill of health too.
What I do know, however, is that when I tried resaving them myself and reinserting them int a WAD, I made the situation worse because 3 trees showed the unwanted effect instead of two.
What I do know, however, is that when I tried resaving them myself and reinserting them int a WAD, I made the situation worse because 3 trees showed the unwanted effect instead of two.

- Graf Zahl
- GZDoom Developer
- Posts: 7148
- Joined: Wed Jul 20, 2005 9:48
- Location: Germany
- Contact:
- Enjay
- Developer
- Posts: 4748
- Joined: Tue Aug 30, 2005 23:19
- Location: Scotland
- Contact:
Fortunately, in this case, the linked WAD files illustrate the point anyway.
Yeah, I never really understood why so many people used imageshack because I have always found it problematic too. I used to use Picoodle but they suddenly changed to require you to register a couple of weeks ago so I have been using imageshack as a filler until I find something better.
Yeah, I never really understood why so many people used imageshack because I have always found it problematic too. I used to use Picoodle but they suddenly changed to require you to register a couple of weeks ago so I have been using imageshack as a filler until I find something better.
- NeoHippo
- Posts: 408
- Joined: Tue Sep 13, 2005 0:47
- Location: British Columbia Canada
- Rachael
- Developer
- Posts: 3651
- Joined: Sat May 13, 2006 10:30
Eh, fuck em. If they don't want to be usable, they don't want to be used, then I won't use them. There's plenty of other sites out there with far superior quality and features, and well worth my time.
I bet making their page not work with JavaScript blocking enabled has earned them a LOT of money for ad revenue...
I bet making their page not work with JavaScript blocking enabled has earned them a LOT of money for ad revenue...

-
- Posts: 8
- Joined: Wed Aug 16, 2006 9:28
Maybe the topic of this thread can change to "TEXTURES - Applying a filter disables transparent color"?
In zdoom, everything looks fine.

In gzdoom, those new defined textures with filters lose their transparent color. Instead, gzdoom creates one solid color for them, and, randomly.


In zdoom, everything looks fine.

In gzdoom, those new defined textures with filters lose their transparent color. Instead, gzdoom creates one solid color for them, and, randomly.


- Attachments
-
- TextureFilterReport.zip
- Demostration file in pk3 format
- (1.12 KiB) Downloaded 52 times
- Rachael
- Developer
- Posts: 3651
- Joined: Sat May 13, 2006 10:30
What's happening here is pretty clear - in order for a filter to be applied, the texture / sprite is being placed on a background which later gets removed. However, since the filter is being applied to the texture / sprite, the background changes, and that causes the background to change, and GZDoom (or the graphics API) no longer recognizes it - so it no longer gets removed. I am not sure if the OpenGL API gets involved in this or not, but I'm betting it does.
The only way to fix this, that I know of, is to remove the background before the translation, but I know of course that's a lot more complicated than it sounds. It might be possible to save a texture's alpha channel before translation, though, and reapply it after.
The only way to fix this, that I know of, is to remove the background before the translation, but I know of course that's a lot more complicated than it sounds. It might be possible to save a texture's alpha channel before translation, though, and reapply it after.
- Graf Zahl
- GZDoom Developer
- Posts: 7148
- Joined: Wed Jul 20, 2005 9:48
- Location: Germany
- Contact:
-
- Posts: 8
- Joined: Wed Aug 16, 2006 9:28
Re: [1200 et al] sprite transparency problem
I was talking about applying Translations.
Sorry, my bad. I apologize for my misleading expression.
Sorry, my bad. I apologize for my misleading expression.
- DoomRater
- Posts: 397
- Joined: Tue Jul 19, 2005 4:14
- Location: Programmer's Room, talking to Will Harvey
- Contact:
Re: [1200 et al] sprite transparency problem
Possibly related...
In this patch Wolverine's altfire claw is supposed to attack from the left hand, but instead it attacks from the right. The problem appears to be GZdoom not applying the FlipX value as it should be. ZDoom does, however.
I went ahead and tested with a latest SVN build and same problem.
Here's the wad: http://www.sendspace.com/file/pq3vmj
In this patch Wolverine's altfire claw is supposed to attack from the left hand, but instead it attacks from the right. The problem appears to be GZdoom not applying the FlipX value as it should be. ZDoom does, however.
I went ahead and tested with a latest SVN build and same problem.
Here's the wad: http://www.sendspace.com/file/pq3vmj