Menu
▾
▴
#4769 HE (16Bit): Inventory items (Cursors) have wrong color
ScummVM 1.1.0svn48065 (Feb 15 2010 11:24:57)
Features compiled in: Vorbis FLAC MP3 RGB zLib
When using the inventory items (either the gadgets or the items from Fox's pocket, they change to become the cursor.
This is when the colors go corrupt and look like it was before the 16bit support was compiled in.
Spyfox 3: Operation Ozone (English/Windows(Updated))
AmigaOS4
gcc version 4.2.4 (adtools build 20090118)
Any particular example? After all, this is a game where much of the time the difference between 8 bpp and 16 bpp isn't that obvious. (At least in the parts of the game I've seen so far.)
Nope, this covers "every" item you got in the inventory or spygadgets.
As soon as you "take one out" to "use" it, it becomes (in a smaller version) the cursor and right now it has false colours.
e.g. the candy boxes from cookie or the grannie grappler from quack
Granny grappler in inventory
Granny grappler cursor
Hmm... Either the effect is a lot more subtle than your description led me to believe, or it doesn't happen for me. I've attached two screenshots of the granny grappler for comparision. (They're both taken at the command center where I got the grappler in the first place.)
Could it be platform specific? Then again, doesn't the Amiga version use the same SDL backend as the Linux version?
My Cursor - Colors are off
The inventory is the same as yours but it differs (as you can see in the sreenshot) when the item becomes the cursor.
Yes, i think Amiga uses the same SDL backend as Linux (at least i don't have to add some special code to make it run under AmigaOS, apart from the OS specific I/O parts, that is)
Freddi Fish 5 is affected aswell
In the second game from HE that is 16bit i have the same bahaviour
Freddi Fish 5: The Case of the Creature of Coral Cove
This bug is nice to get fixed before the release. Raising priority for keeping the track.
This seems to be an Amiga-only problem. I'm not able to reproduce it here (Mac OS X) and we have already had two people test through freddi5 and one person test through spyfox3 without any problems (WinXP and Linux).
But then it has to be an Amiga SDL problem, because i have in now way any custom (expect the platform specific I/O) modules here.
Using SDL-1.2.13-SVNr5 from [url=http://code.google.com/p/os4sdl/]here[/url]
So can anybody reproduce this on a non-amiga system? Kirben?
Can't reproduce. To me it looks like swapped components for the palette. Please check your cursor palette implementation.
Where would one look for that? (sorry, no-coder here)
I didn't know there was a custom cursor palette implementation in the Amiga port (SDL backend)
These days you may consider compiling gsoc2010-testbed branch and try running target 'testbed' among other things this will test the cursor palette.
Done.
Info! Executing Test: PalettizedCursors
Result: Passed
:-/
I've been investigating this issue today with Hubert and it seems to be caused by endianness (the Amiga is big endian).
I'm attaching for review a patch that solved this issue for him and didn't break it for me. Anyway I'm not sure it's the best solution and it doesn't break other use cases since I'm not familiar with the SCUMM engine.
The colors are kept in little endian in the palette, they're read into native endianness in Wiz::write8BitColor(), and they're converted back to little endian in Wiz::write8BitColor(). This last case is the one I've changed so the destination image is painted in the native endianness. I'm not sure that's always the desired result.
Possible fix
Solution