Page 1 of 1
Bug: Player sprite translation still palette restricted in true colour renderer
Posted: Fri Oct 14, 2016 4:45
by Nash
For the true colour software renderer, the Player sprite's translation is still restricted to the limited palette colours. For example, if I try to make a cyan Doomguy (R: 0, G: 255, B: 255), the world sprite just gets butchered by the Doom palette.
In the Player menu, it looks correct. Only the world sprite looks wrong.
In OpenGL, everything looks good (same as GZDoom)
Re: Bug: Player sprite translation still palette restricted in true colour renderer
Posted: Fri Oct 14, 2016 5:54
by dpJudas
This is currently working as intended (well, as coded :p). I did have the impression that GZDoom was doing it the same way with translation, but maybe GZDoom handles the player sprite differently - I'm not sure.
Re: Bug: Player sprite translation still palette restricted in true colour renderer
Posted: Fri Oct 14, 2016 8:44
by Graf Zahl
Actually, translations contain a full RGB palette for the translated colors. GZDoom of course uses this to translate in-game textures, as does the 2D interface in ZDoom.
In fact I went to great lengths to make this work well, that's why FHardwareTexture contains such explicit translation support.
Re: Bug: Player sprite translation still palette restricted in true colour renderer
Posted: Fri Oct 14, 2016 10:59
by dpJudas
Hmm, that's very interesting. The current code picking the translation in the swrenderer looks like this:
Code: Select all
FRemapTable *table = TranslationToTable(translation);
if (table != NULL && !table->Inactive)
{
dc_translation = table->Remap;
}
If I understand you correctly, if it used FRemapTable's Palette instead of Remap it would get the full palette?
Re: Bug: Player sprite translation still palette restricted in true colour renderer
Posted: Fri Oct 14, 2016 11:12
by dpJudas
Seems the answer to that question is yes. Thanks for the tip, Graf! Now that was an
easy change.