#7320 closed feature request (fixed)
FMTOWNS: Need more than 256 colors to display properly
| Reported by: | SF/hibernatus | Owned by: | athrxx |
|---|---|---|---|
| Priority: | low | Component: | Engine: SCUMM |
| Version: | 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 , 21 years ago
| Owner: | set to |
|---|
comment:2 by , 21 years ago
comment:3 by , 21 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 , 21 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 , 21 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 , 21 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 , 21 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 , 21 years ago
| Owner: | removed |
|---|---|
| Priority: | normal → low |
comment:9 by , 21 years ago
| Summary: | FMTOWNS: Palette bugs → FMTOWNS: Need more than 256 colors to display properly |
|---|
comment:10 by , 14 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 , 14 years ago
| Owner: | set to |
|---|---|
| Status: | new → pending |
comment:12 by , 14 years ago
| Resolution: | → worksforme |
|---|
comment:13 by , 14 years ago
| Resolution: | worksforme → fixed |
|---|
comment:14 by , 14 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 , 14 years ago
| Status: | pending → closed |
|---|
comment:16 by , 6 years ago
| Component: | → Engine: SCUMM |
|---|---|
| Game: | → Loom |
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.