Opened 16 years ago

Closed 9 years ago

Last modified 12 months ago

#7320 closed enhancement (fixed)

FMTOWNS: Need more than 256 colors to display properly

Reported by: SF/hibernatus Owned by: athrxx
Priority: low Component: Engine: SCUMM
Keywords: Cc:
Game: Loom

Description

In Loom FM Towns there are some rooms where the
distaff has wrong colors (and other objects actually, the
leaf for example).
That's because the 16 first colors of the palette should
be constant.
They're initialized in sub_114C in INDY3.EXP, sub_156C in
LOOM.EXP and sub_1550 in ZAK.EXP.
And you can find the right palettes at 0x230B8 in
INDY3.EXP, 0x23E6C in LOOM.EXP and 0x23E0C in
ZAK.EXP. See: http://hibernatus34.free.fr/pv/

A little warning: When you enter room 5 in Loom, a call
to o5_roomOps does _shadowPalette[13] = 6 which
makes another glitch on the distaff. So the 16 first
colors are really constant and shouldn't be remapped.

I guess it isn't very important for Zak (there's a
difference, but it's not annoying).
Indy3 should also be ok since the PC version has the
same "bug" as scummvm (look at the verbs in the
gymnasium).
But since you have to fix Loom, i guess it won't hurt to
fix every FM Towns game :)

Same thing for CharsetRendererV3::setColor.
You only fixed Loom, but if you look at the disassembly
(sub_3014 in INDY3.EXP, sub_3718 in ZAK.EXP,
sub_36CC in LOOM.EXP), you can see it should be:

void CharsetRendererV3::setColor(byte color) {
_shadowColor = (_vm->_features &
GF_FMTOWNS) ? 8 : 0;
_color = color & 0x0F;
if ((_vm->_features & GF_FMTOWNS) &&
_color == 0)
_color = 8;
if (_vm->_features & GF_OLD256)
_dropShadow = ((color & 0x80) != 0);
else if (_vm->_features & GF_16COLOR)
_dropShadow = ((color & 0xF0) != 0);
else
_dropShadow = false;
}

The "if (_color == 0) _color = 8;" can be seen at
0000397B in the disassembly of ZAK.EXP for example.
But i guess that case never happens in scripts.

Ticket imported from: #812891. Ticket imported from: feature-requests/136.

Change History (16)

comment:1 by fingolfin, 16 years ago

Owner: set to SF/khalek

comment:2 by fingolfin, 16 years ago

Have no FMtowns Indy/Loom, can't comment. CVS tells me khalek
made the GF_FMTOWNS related changes to
CharsetRendererV3::setColor, so I assume he knows something
about this.

BTW all V3 games are either GF_OLD256, or GF_16COLOR (I just
noticed that while looking at scummvm.cpp :-) so the code could
be simplified accordingly.

comment:3 by SF/hibernatus, 16 years ago

"So the 16 first colors are really constant and shouldn't be
remapped."
This part is wrong, sorry. It actually needs more investigation
on roomOps case 2.

comment:4 by SF/hibernatus, 16 years ago

I've tried changing that 16 colors palette under UNZ and saw
that it doesn't change the background picture.
In Indy3 the objects seemed to use the 256 colors palette
while in Loom they seem to use the constant 16 colors
palette. So i don't understand. It's not a matter of position on
the screen since a line of text can be displayed anywhere and
it will always use the constant 16 colors palette.
So please don't fix that bug until i or somebody else
understand it completely. I'll make more tests.

comment:5 by SF/hibernatus, 16 years ago

<KtJ_Dragon> FM TOWNS can overlays 640x480:4bit screen
on 320x240:15bit screen.
I think this explains why a 16 colors palette is set with low
level stuff (interrupts) and is displayed simultaneously with
the usual 256 colors.
So, scummvm needs to use that constant 16 colors palette
for a few things only.
I've replaced the 16 first of each room palette by some pink
and the 16 colors of the overlay by some green. Here are the
results:
Green (overlay palette):
- Cursor
- Any text
- Anything displayed by verbOps (even object images)
- drawBox
Pink (usual 256 colors palette):
- Room background
- Actors
- Objects (background animations)

Am i missing something? If not, this bug could be fixed now.

comment:6 by fingolfin, 16 years ago

I am not sure how you think this could be fixed. If I understand
you right, we'd need at least 256+16=272 color for that, but we
only have 256 available...

comment:7 by fingolfin, 16 years ago

We discussed this some time ago on IRC, there is indeed
apparently no clean solution to this with just 256 colors...

Lowering priority and un-assigning this.

comment:8 by fingolfin, 16 years ago

Owner: SF/khalek removed
Priority: normallow

comment:9 by fingolfin, 16 years ago

Summary: FMTOWNS: Palette bugsFMTOWNS: Need more than 256 colors to display properly

comment:10 by athrxx, 9 years ago

This should be fixed now.

Pleae test again with latest SVN. Be sure to use a build with Hi-Color support (USE_RGB_COLOR). Using old savegames may lead to palette glitches. It would be appreciated if you could play through your Scumm Fm-Towns games again right from the beginning and report any bugs you find.

I set this item to pending.

Florian

comment:11 by athrxx, 9 years ago

Owner: set to athrxx
Status: newpending

comment:12 by athrxx, 9 years ago

Resolution: worksforme

comment:13 by athrxx, 9 years ago

Resolution: worksformefixed

comment:14 by SF/sf-robot, 9 years ago

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

comment:15 by SF/sf-robot, 9 years ago

Status: pendingclosed

comment:16 by digitall, 12 months ago

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