Opened 10 years ago

Closed 9 years ago

Last modified 12 months ago

#4769 closed defect (fixed)

HE (16Bit): Inventory items (Cursors) have wrong color

Reported by: raziel- Owned by: Kirben
Priority: high Component: Engine: SCUMM
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)

inventory.png (5.6 KB ) - added by eriktorbjorn 10 years ago.
Granny grappler in inventory
cursor.png (3.5 KB ) - added by eriktorbjorn 10 years ago.
Granny grappler cursor
HE SpyFox 3 - Wrong Cursor Colour.png (692 bytes ) - added by raziel- 10 years ago.
My Cursor - Colors are off
HE Freddi 5 - Wrong Cursor Colour.png (1.5 KB ) - added by raziel- 10 years ago.
Freddi Fish 5 is affected aswell
amiga_16bit_cursor.patch (410 bytes ) - added by jvprat 9 years ago.
Possible fix
cursor.diff (1.2 KB ) - added by Kirben 9 years ago.
Solution

Download all attachments as: .zip

Change History (35)

comment:1 by eriktorbjorn, 10 years ago

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.)

comment:2 by raziel-, 10 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

by eriktorbjorn, 10 years ago

Attachment: inventory.png added

Granny grappler in inventory

by eriktorbjorn, 10 years ago

Attachment: cursor.png added

Granny grappler cursor

comment:3 by eriktorbjorn, 10 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 raziel-, 10 years ago

My Cursor - Colors are off

comment:4 by raziel-, 10 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 raziel-, 10 years ago

Summary: SPYFOX 3: Inventory items have wrong colorHE (16Bit): Inventory utems (Cursors) have wrong color

by raziel-, 10 years ago

Freddi Fish 5 is affected aswell

comment:6 by raziel-, 10 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 raziel-, 10 years ago

Summary: HE (16Bit): Inventory utems (Cursors) have wrong colorHE (16Bit): Inventory items (Cursors) have wrong color

comment:8 by sev-, 10 years ago

This bug is nice to get fixed before the release. Raising priority for keeping the track.

comment:9 by sev-, 10 years ago

Priority: normalhigh

comment:10 by jvprat, 10 years ago

Owner: set to Kirben

comment:11 by SF/mthreepwood, 10 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 raziel-, 10 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:13 by fingolfin, 9 years ago

So can anybody reproduce this on a non-amiga system? Kirben?

comment:14 by sev-, 9 years ago

Owner: changed from Kirben to sev-

comment:15 by sev-, 9 years ago

Can't reproduce. To me it looks like swapped components for the palette. Please check your cursor palette implementation.

comment:16 by raziel-, 9 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 sev-, 9 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:18 by raziel-, 9 years ago

Done.

Info! Executing Test: PalettizedCursors
Result: Passed

:-/

comment:19 by jvprat, 9 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.

by jvprat, 9 years ago

Attachment: amiga_16bit_cursor.patch added

Possible fix

by Kirben, 9 years ago

Attachment: cursor.diff added

Solution

comment:20 by Kirben, 9 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 Kirben, 9 years ago

Owner: changed from sev- to Kirben

comment:22 by sev-, 9 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 SF/mthreepwood, 9 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 SF/mthreepwood, 9 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 Kirben, 9 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:26 by SF/mthreepwood, 9 years ago

Kirben: Yeah, you're right. Your newest patch has everything working.

comment:27 by Kirben, 9 years ago

Resolution: fixed
Status: newclosed

comment:28 by Kirben, 9 years ago

Thanks for testing the patch, I added the changes to both branches of ScummVM SVN.

comment:29 by digitall, 12 months ago

Component: Engine: SCUMM
Note: See TracTickets for help on using tickets.