Welcome to the ZDoom Forums!

That's exactly the problem that I run into in the above screenshot.

The problem is that it doesn't happen to just black (#000000), but to any other color that's sufficiently dark enough. That means that in order to work around this, a couple more shades of dark have to be removed (resulting in a not-quite-smooth fade to translucent in GL).

Not that it's a huge deal, mind you, but that just goes to say that this still happens in cases where transparency is correctly applied to the outside sprite edges.

If you want to use translations you have to use Doom patch format. If you use that you already got your transparent color, so where's the problem?

I could also use alpha channels but the problem is that this doesn't work fine when I want to use translations as well. If I want to have a sfx in 5 different colors, I do need 5 different sets of sprites :(

Never *EVER* use black for transparency in additive sprites. It doesn't work right. Cheat yourself some invulnerability and watch the wonderful rectangles around the smoke!

What esselfortium said.

http://forum.zdoom.org/viewtopic.php?f=7&t=24047&p=505269

If I remember right, this has been reported before and is a known precision issue. It'd be much slower to do it "right". The solution is to just use actual transparency to replace the offending dark colors in your additive sprites/textures.

I noticed this already several times and I think this can be considered as a bug, even though I do not know how the software renderer actually handles things.

If you have a black texture and apply the TranslucentLine special to a 2-sided wall using that black texture, additive translucency should actually make the black parts completely invisible. Though for some reason they "darken" what's behind them (about 5-10%).

Here is a little example:
[img]http://i56.tinypic.com/dvos60.jpg[/img]

These "steam" sprites consist of white circles on a totally black background. For some reason you can actually see this black background.