DRD Team

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

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.

This whole thing behaves rather strangely.
With some of my tries, I managed somehow to even change the colour of the "transparency".

Why does everyone use imageshack? Use photoalbum instead...

imageshack + noscript = no agreement with each other.

I used to like imageshack but it causes so many problems that I simply refuse to load images from there. So posting imageshack links here is as good as posting nothing at all.

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.

When we migrate to phpBB3, the rules on attachments will be less strict (no more quotas!), maybe people will just attach their images instead.

Graf Zahl wrote:I used to like imageshack but it causes so many problems that I simply refuse to load images from there. So posting imageshack links here is as good as posting nothing at all.

Ok, I've done away with the imageshack links.

They've recently been a bit more usable again. Pics still don't show on their "my.php" pages, but now you get a direct link to the image that you can follow. Previously they tried to hide that link.

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

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.

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.

That demo level works fine for me but I get the non-transparent trees from the first report.

What do you mean by 'applying a filter'? I tried to switch through all the texture options and none triggered the bug.

I was talking about applying Translations.
Sorry, my bad. I apologize for my misleading expression.

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