Palette-specific drawing functionality

[The Zombie Killer]

I'm currently working on a project to accurately recreate Blood's weapons, and Blood does a fair amount of stuff with different palettes. Currently, I export all of Blood's tiles to doom graphics, retaining their palette indices. Then I load all of Blood's palette files in ZScript and generate translations from them.

The problem is that when I apply these translations, they get doom-paletted, giving results like this for some sprites:



If I replace PLAYPAL with the Blood palette, it obviously works correctly, since all the colours are there, but that still has issues:
1. Doom graphics are obviously screwed
2. Blood has 5 separate palettes, not 1

I was wondering if it'd be possible to add either some or all of the following:

• Set the palette to draw with via DTA_Palette (or something similar) with the Screen API
• Ability to create palettes at runtime, similar to how translations can be
• Ability to change the "global" palette (not necessary for my project in particular, but good for robustness)
• Reduce image "damage" from palettization by generating a new palette when RGB translations are used

[Graf Zahl]

You will have to create translations that map to RGB colors, not Blood color indices. That part is never going to work.

[The Zombie Killer]

They do map to RGB colours. Here's a snippet from where the translations are created (index 1 used for testing):

Code: Select all

let lumpID = Wads.CheckNumForFullName(palettePath);
let lump   = LumpStream.Create(lumpID);
let br     = BinaryReader.Create(lump);

ACS.CreateTranslationStart(1);
for(int i = 0; i < 256; i++)
{
    palette[i].r = br.ReadByte();
    palette[i].g = br.ReadByte();
    palette[i].b = br.ReadByte();

    ACS.CreateTranslationRGB(i, i,
        palette[i].r, palette[i].g, palette[i].b,
        palette[i].r, palette[i].g, palette[i].b);
}
ACS.CreateTranslationEnd();

[Graf Zahl]

Have you tried using Translation.AddTranslation instead of those ACS hacks?

[The Zombie Killer]

I wasn't aware that it existed, thanks for letting me know. Looking at the struct though, its usage seems unclear. Do you have an example onhand?
I assume I fill the "colors" field in the struct, call AddTranslation on it, and use the result?

EDIT: It uhh, gave "interesting" results

Code: Select all

let lumpID = Wads.CheckNumForFullName(palettePath);
let lump   = LumpStream.Create(lumpID);
let br     = BinaryReader.Create(lump);

Translation t;
for(int i = 0; i < 256; i++)
{
    t.colors[i] = Color(255,
        br.ReadByte(),
        br.ReadByte(),
        br.ReadByte()
    );
}
testIndex = t.AddTranslation(); 

[Graf Zahl]

What format are your source graphics in?

Also, color 0 needs to be translated to something with 0-alpha to remain transparent.

[The Zombie Killer]

They're in regular DOOM sprite format, with the same palette indices as the original Build tiles.

EDIT: Huh. Very interesting. Converting the graphic to a PNG solves the issue. EDIT: Nevermind, that was a 5:00 AM brainfart on my part. The PNG I used was truecolor.

EDIT: Something of note is that using the ZScript AddTranslation feature, the graphic is still incorrect when PLAYPAL is the Blood palette:

[The Zombie Killer]

As we just found on the ZDoom Discord server, the palette was being read incorrectly (due to an issue with String.CharCodeAt not working with bytes above 127). When I "baked" the palette into the source code, I got this output:



Which looks correct when the Blood palette is used as PLAYPAL:



So I assume the image is still being palettized.

[Graf Zahl]

As we just found on the ZDoom Discord server, the palette was being read incorrectly (due to an issue with String.CharCodeAt not working with bytes above 127).

The old signed char issue? It should work if you and the result with 255 then.

[The Zombie Killer]

Huh, well I'll be damned. That solves the binary reading issue at least, major thanks for that.

[The Zombie Killer]

So uhh, upon some investigation, I've discovered some confusing behaviour.

When not using BLOOD.PAL as PLAYPAL:

The graphic uses palette index 247 (171, 123, 83) instead of index 1 (11, 11, 11) for whatever reason.
So if I manually change index 247 to (11, 11, 11) the issue somewhat gets fixed.

When using BLOOD.PAL as PLAYPAL:

The indices all appear to be correct when doing this, because changing index 247 doesn't change the graphic anymore, but changing index 11 does.

[Gez]

Index 247 is a redundant black color. ZDoom uses index 0 for transparency and remaps index 0 black pixels to index 247 (when using the standard Doom palette).

[The Zombie Killer]

I think I get the gist, but I don't quite understand the "remaps index 0 black pixels to index 247" part, do you mind elaborating a bit?

EDIT: I ended up "solving" the problem by re-running my Build tile -> Doom graphic converter, but making it remap any palette indexes of "0" to "1" (which is almost the same colour). So I think the necessary feature addition here is the ability to disable that index 247 remapping.

Before mapping 0 to 1:



After:

[Rachael]

I think I get the gist, but I don't quite understand the "remaps index 0 black pixels to index 247" part, do you mind elaborating a bit?

When GZDoom is first loaded, it has to prepare all the textures in memory. What it does just before this happens though, is obviously it loads the game palette. When the palette is loaded, the following occurs: (At least, from what I read of the comments in the source, this is my understanding of it)

1) The entire palette is scanned for duplicate entries. With Doom, Heretic, and (I believe?) Strife this is not an issue.

2) If one is found, the duplicate is turned into black, and a texture color remap is created which remaps any pixels with color "0" to the new color. As these textures are loaded, the texture is filled with pure "0"s to signify transparency, and then the pixels are loaded on top of the new texture in their remapped form.

3) If no duplicates are found (as is the case with Hexen) it then tries to search for the closest color to black, and instead remaps color 0 to this new color, and does the same as above.

4) The game then proceeds like usual with the new altered game palette and textures.

(In true-color modes the entire process is less obvious since the textures can easily be loaded in using their native colors)