Page 1 of 1
(r1016) A_RailAttack particles are not true color
Posted: Fri Oct 01, 2010 4:47
by Footman
Unsure whether this is a bug, oversight, or intentional, but I'll throw it out here anyways.
When setting a color of a railgun for A_RailAttack, the colors used appear to still be limited to Doom's palette despite GZDoom's true color rendering.
This is easiest to tell when attempting to use a cyan or turquoise color.
Re: (r1016) A_RailAttack particles are not true color
Posted: Fri Oct 01, 2010 7:14
by Graf Zahl
That may be possible. Not all code that does color processing has been altered to work without the palette. Originally in ZDoom all such code was palette-locked and most has been changed by now. It was probably just overlooked.
Re: (r1016) A_RailAttack particles are not true color
Posted: Mon Aug 01, 2011 20:58
by Gez
The problem comes from the use of ColorMatcher.Pick() in a lot of basic functions. Particle effects (including railgun but also blood for example), decals, GetBlendMap(), AActor::SetShade(), FTexture::InitGrayMap(), and more.
One thing I wonder about is constructions such as this:
Code: Select all
DEFINE_PROPERTY(stencilcolor, C, Actor)
{
PROP_COLOR_PARM(color, 0);
defaults->fillcolor = color | (ColorMatcher.Pick (RPART(color), GPART(color), BPART(color)) << 24);
}
Is this putting the closest match's palette index in what's normally the alpha part of a RGBA DWORD so that the same variable keeps both the real RGB triplet for the hardware renderer(s) and the software-compatible palette index?
Re: (r1016) A_RailAttack particles are not true color
Posted: Wed Aug 03, 2011 1:30
by Gez
Fixed, with apparently no ill effects, even in software mode.