Wrong colours when decoding under macOS

[danielplaumann]

When using grfcodec to decode on macOS 13.5, I get completely wrong colours. (It is not an issue with Win vs. Dos palette.) Does anybody know a fix for this?

Attached is a part of the png obtained from openttd.grf. (For some reason, this does not affect the original TTD files like trg1r.grf, but any newgrf I have tried.) Works fine under Wine/Windows.

[rubidium42]

Can you confirm that for the ones where the colours are wrong, there is a message with Found grf container version 2 during decoding? And is is always Found grf container version 1 when the image is decoded correctly?

What version of grfcodec are you using exactly?

[andythenorth]

Confirmed locally with grfcodec 6.0.6-39-g045774d on macOS 12.6.8, decompiling FIRS.

Found grf container version 2

[danielplaumann]

I am using Version 6.0.6-50-gd5a7b85

Grf container version, probably no:
The only one I tried that gave correct colours is trg1r.grf, which is of course version 1.
But I just tested with 10-101INFRARoads.grf, which is also version 1 and gives wrong colors.
I think all the others I tried were version 2.

[rubidium42]

Today I found out... that grfcodec has a short list of GRF file names for which it knows the palette, which are basically those originally coming with Transport Tycoon (Deluxe/Original) and TTDPatch. Anything else will be decoded using the "first" palette, which is the Mars landscape of the original version. That's what's causing wrong palette.

I have absolutely no idea why it would be creating images with the correct palette under Windows/Wine. For me, under Linux at least, it's also not creating the right images. Unless for some weird reason the order of palettes is different for the Windows binary, which would be really annoying.

So, you need to explicitly set the palette that you want to decode using -p <number>. Please check grfcodec -p ? for the mapping, as that might be different. You're probably looking for the DOS TTD or Windows TTD variant.

[danielplaumann]

No, unfortunately -p 1 or -p 2 does not fix the problem. I know that Win/Dos-palette has to be manually specified or some colours will come out wrong. But this is much worse. Look at Andy's and my screenshot.

This used to work (also under macOS) until some time ago. Unfortunately, I am not sure whether it broke with some version of grfcodec or some version of macOS. I suspect the latter.

Also, "grfcodec -p ?" no longer shows me the available palettes for some reason. I just get "zsh: no matches found: ?" when I try that. (Same for -m).

[rubidium42]

Well, '-p 1' and '-p 2' are likely respectively "TT Original, Mars landscape" and "TT Original"; at least, that's the case on Linux and potentially also MacOS. Though, I don't have MacOS so I can't do any actual debugging of what might be going wrong on that platform.

Does grfcodec -p '?' or grfcodec -p "?" help with listing the available palettes?

What do '-p 4' or '-p 6' achieve?

[danielplaumann]

Sorry, I was to quick. Yes, you are correct. grfcodec -p "?" gives the list in a weird new order:

Built-in palettes: use -p , where is one of the following:
4 DOS TTD
6 Windows TTD
3 DOS TTD, Candyland
5 Windows TTD, Candyland
2 TT Original
1 TT Original, Mars landscape

And yes, -p 3 (or 6) give the correct colours. All is well.

[andythenorth]

Confirmed here also, with FIRS, -p 3 results in a correct decompile.

[glx22]

Correct order restored with #25