#4769 closed defect (fixed)
HE (16Bit): Inventory items (Cursors) have wrong color
| Reported by: | raziel- | Owned by: | Kirben |
|---|---|---|---|
| Priority: | high | Component: | Engine: SCUMM |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
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)
Ticket imported from: #2952298. Ticket imported from: bugs/4769.
Attachments (6)
Change History (35)
comment:1 by , 14 years ago
comment:2 by , 14 years ago
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
comment:3 by , 14 years ago
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?
by , 14 years ago
| Attachment: | HE SpyFox 3 - Wrong Cursor Colour.png added |
|---|
My Cursor - Colors are off
comment:4 by , 14 years ago
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)
comment:5 by , 14 years ago
| Summary: | SPYFOX 3: Inventory items have wrong color → HE (16Bit): Inventory utems (Cursors) have wrong color |
|---|
by , 14 years ago
| Attachment: | HE Freddi 5 - Wrong Cursor Colour.png added |
|---|
Freddi Fish 5 is affected aswell
comment:6 by , 14 years ago
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
comment:7 by , 14 years ago
| Summary: | HE (16Bit): Inventory utems (Cursors) have wrong color → HE (16Bit): Inventory items (Cursors) have wrong color |
|---|
comment:8 by , 14 years ago
This bug is nice to get fixed before the release. Raising priority for keeping the track.
comment:9 by , 14 years ago
| Priority: | normal → high |
|---|
comment:10 by , 14 years ago
| Owner: | set to |
|---|
comment:11 by , 14 years ago
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).
comment:12 by , 14 years ago
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]
comment:14 by , 14 years ago
| Owner: | changed from to |
|---|
comment:15 by , 14 years ago
Can't reproduce. To me it looks like swapped components for the palette. Please check your cursor palette implementation.
comment:16 by , 14 years ago
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)
comment:17 by , 14 years ago
These days you may consider compiling gsoc2010-testbed branch and try running target 'testbed' among other things this will test the cursor palette.
comment:19 by , 14 years ago
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.
comment:20 by , 14 years ago
Sounds like this issue is due to cursor been a wizImage, but drawn by outside drawing method, which expects native endian to be used, rather than little endian.
That patch isn't the correct method to fix cursors though, and would cause numerous palette glitches on a big endian system, when any manipulation of wizImages is triggered. The kDstMemory and kDstResource types mean the destination is another wizImage resource, so the colors much be kept in little endian, to match the decoding methods for wizImages.
The solution is to add another another type specifically for cursors , try the attached patch.
comment:21 by , 14 years ago
| Owner: | changed from to |
|---|
comment:22 by , 14 years ago
Hm. that means that you will need to revert 53456 & 53457 as I've committed the patch, just forgot to close this bugreport.
Thanks for the heads up.
comment:23 by , 14 years ago
I just tested the patch on a BE system (Mac PPC) and it fixed cursors and caused no palette problems, at least in the first few screens of Freddi Cove.
comment:24 by , 14 years ago
Correction: I tried the original patch that was reverted. I tested before I saw Kirben's patch. I can test that too later.
comment:25 by , 14 years ago
The patch really needs to be tested with a game that does manipulation of wizImages, like the later Backyard sports titles.
Try quick starting a new game in Backyard Football 2002, and check that the play selection screen segments still use the correct palette.
comment:27 by , 14 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:28 by , 14 years ago
Thanks for testing the patch, I added the changes to both branches of ScummVM SVN.
comment:29 by , 5 years ago
| Component: | → Engine: SCUMM |
|---|
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.)