MONKEY: Wrong Palette for Amiga-Versions

[ceztko]

The sprites use the EGA graphics in the Amiga version while the backgrounds have 32 colors. Now, there are two different versions of the Amiga executable.

It's wonderful how many times I changed opinion in this couple of days. Let's try to summarize positions and facts:

In most frequent display modes, amiga is able to display a maximum of 32 colours chosen from a palette of 4096.

Amiga version of Monkey Island 1 stores two kinds of objects for graphics:
- backgrounds;
- sprites.

Each pixel of a background is stored using a 12bit representation of the colour. Backgrounds use a maximum of 32 colours, so the amiga display mode is respected. This does mean there exist an implicit 32 colours palette for backgrounds, and there's no need to hardcode it in scummvm: the 12bit colour will be drawn in the surface SDL exposes.

Each pixel of a sprite is stored using a 4 bit bit representation of the colour. This does mean sprites use a maximum of 2^4=16 colors. This is done to save space, as sprites are many more than backgrounds. This 4 bit colour must be mapped to the 2^12 = 4096 colours palette of the OCS chipset in the amiga. To do this, an explicit 16 positions map table is stored on the MI1 executable. Still, the total sum of background plus sprite colours must not be over 32.

Having an hardcoded map table in the MI1 executable means it must be implemented in scummvm as well: the sprite palette is stored in engines/scumm/palette.cpp source file as 24bit colours (8-8-8 representation).

Whatever scummvm must draw a background or sprite pixel, the final output will be 16bit as scummvm use a 16bit SDL surface, so there can be a little loss of accuracy (but not easy noticeable) in the final colours displayed. This because of the 12bit->16bit conversion for backgrounds and 24bit->16bit rescale for sprites.

It seems there are 2 executable versions, with different sprite palettes:
- mine, that is the same of the EGA sprite palette;
- nolange's one, that is the same of old 16 colours amiga scumm games (Zak and MM).

There's no reason that one should be prefered in favor of another, so probably they should be both implemented.

After these considerations, there is a strange bug with the colour of the poisoned flower in the forest. Some parts of the screens in the forest are randomly generated at runtime but the screen with the poisoned flower (the one you can actually pick up) should have a constant appearance with the flower of a yellow colour. The bug manifests in BOTH (nolange's and mine) sprite palette versions, causing the flower to be red instead.


(correct poisoned flower screen, EGA sprites palette)


(bugged poisoned flower screen, EGA sprites palette)


(correct poisoned flower screen, scumm V2 amiga games sprites palette)


(bugged poisoned flower screen, scumm V2 amiga games sprites palette)

Actually is unknow what is causing the poisoned flower colour bug. It could be something related to:
- sprite palette;
- random generated forest algorithm (md5 don't agree the algorithm is related to this bug while logicdeluxe is opened to this interpretation);
- graphichs engine of scummvm;
- others parts of scummvm.

If there's something wrong in what I've just wrote, please tell me so I will fix this post.

[md5]

The bug manifests in BOTH (nolange's and mine) sprite palette versions, so it's probably not directly related to palette itself. My guess is it's related to random generated forest algorithm.

The forest algorithm has nothing to do with the palette of the flower sprite. The algorithm itself is used to create the forest screens, and one of the forest screens contains the flower sprite, which has a problematic palette. The algorithm itself is related to the logic of the game, and the incorrect palette is related to the graphics engine of the game.

[LogicDeLuxe]

Actually, amiga version of Monkey Island 1 is using 2 palettes:
- A 32 colours palette for backgrounds (unknown if stored in 12bit, 4-4-4 representation, or other formats);
- A 16 colours palette for sprites (12bit, 4-4-4 representation).

It's more like a split palette. The Amiga hardware only has one palette per screen. I call those sprites, since they are not part of the background, but they are all drawn by software. The only hardware sprite is the cursor, and even that has to share colors from the main palette (only one color in this case, which is rotated through different shades of gray).
Keeping this in mind, from the available 32 colors, one goes for the mouse cursor, thus 31 left.
From those remaining 31 colors, 16 are used for the EGA "sprites".
That makes 15 colors left, which can be freely used as additional colors for the backgrounds. Those custom colors can be also used for color rotation effects.

For some reason, the forest script misses to set the intended custom color to yellow. This bug is certainly not related to the different skin colors. After all, pink remains pink, blue remains blue etc., just with different brightness. That is not the case with the flower.

And I wouldn't really worry of round off errors when translating 12 bit to 16 bit colors. Take a look at the Sega version (which uses the Amiga graphics). That one I call bad color translations.

[ceztko]

It's more like a split palette.

Well, I wanted to write some true facts doc on how pixel colour information is stored in scumm games (in particular amiga MI1) and finally displayed by scummvm, so we can focus on parts where the flower bug actually is. I modified the post, seems ok now?

[ceztko]

The forest algorithm has nothing to do with the palette of the flower sprite.

Well, not the palette, but could be related to the choice of a colour instead of another? After all, the random generated forest is always full of unpoisoned (that can't be picked up) plants, that are all always red. Only the poisoned flower is yellow. Aren't red plants part of the algorithm? It doensn't seems a coincidence that the bug made the poisoned flower to become red like the others.


(screen with unpoisoned flowers, EGA sprites palette, e-uae)


(Another screen with unpoisoned flowers, EGA sprites palette, e-uae)

[md5]

You're using "algorithm" in a very broad sense here, and please don't reach conclusions based on guesswork...

[ceztko]

You're using "algorithm" in a very broad sense here, and please don't reach conclusions based on guesswork...

You aren't very nice. I'm a tester and I'm doing my job: testing reference versions. At the moment, nobody told me: try this, do this. Guesswork is just a way to give hints to some developers so, before or later, they may think "yes, this *may* be bugged, better to check".

"Algorithm" HAS a very broad meaning, I don't need to check wikipedia to know this. If you are so sure the algorithm/script/whatever that generates the forest isn't related, tell us what is it doing exactly.

[fingolfin]

You aren't very nice. I'm a tester and I'm doing my job: testing reference versions. At the moment, nobody told me: try this, do this. Guesswork is just a way to give hints to some developers so, before or later, they may think "yes, this *may* be bugged, better to check".

I am sure you have the best intentions, but actually, very often such "guesswork" hurts much more than it helps. Especially if you have no idea about how the underlying code works.

"Algorithm" HAS a very broad meaning, I don't need to check wikipedia to know this. If you are so sure the algorithm/script/whatever that generates the forest isn't related, tell us what is it doing exactly.

OK, let's stop this pointless bickering, everybody, please. It leads nowhere. Ceztko, you filed a bug report, it is on the tracker and won't be lost. And if somebody with the actual ability and knowledge to analyze the issue and fix it has some time (and happens to have Monkey Island for Amiga, which I don't), it will be resolved. Nothing else we can do.

But further theorizing on the hypothetical causes of this issue is *not* going to help. So there is no point to further add to this thread, unless you want to start working on fixing the issue yourself, and have specific questions on that, which you want to ask here.