Closed starry-abyss closed 8 years ago
The only way it can be fixed is by adding some logic which will decide to add alpha component to passed color, like adding additional argument, so makeParticles might look like this:
public function makeParticles(Width:Int = 2, Height:Int = 2, Color:FlxColor = FlxColor.WHITE, Quantity:Int = 50, AddAlpha:Bool = true):FlxTypedEmitter<T>
{
if (Color.alpha == 0 && AddAlpha)
{
Color.alphaFloat = 1.0;
}
for (i in 0...Quantity)
{
var particle:T = Type.createInstance(particleClass, []);
particle.makeGraphic(Width, Height, Color);
add(particle);
}
return this;
}
But i don't like this solution and don't want to add it.
Colors in Flixel are almost always ARBG, with a few exceptions like sprite.color
(and even those generally still accept ARGB and ignore the alpha part), so this behavior does not seem all that unexpected to me.
FlxSprite#makeGraphic()
(which seems very similar to makeParticles()
) and draw functions in FlxSpriteUtil
use ARGB colors as well.
Code snippet reproducing the issue:
Observed behavior:
If I try to make particles in FlxEmitter like in snippet, no matter what color and alpha ranges I set later, the particles will be invisible (I can see their collision boxes in debug). If I replace the color in makeParticles() to 32-bit version (0xFF3FCF46), particles are visible and react to color and alpha ranges set in emitter. It's kind of frustrating.
Expected behavior:
Since FlxEmitter.color works with both color versions, I expect makeParticles() to behave the same. Or to just ignore the argument and always make white particles, as color will be overriden by FlxEmitter.color.