Opened 21 years ago

Closed 21 years ago

#426 closed defect (fixed)

MI1VGA: the last few glitches

Reported by: SF/inguin Owned by: fingolfin
Priority: low Component: Engine: SCUMM
Version: Keywords:
Cc: Game: Monkey Island 1


As I promised, I played through MI1 again and verified my previous bug lists. Bug report #581700 can be closed. Most of the bugs are fixed by now, there are only very few ones remaining:

1. The voodoo lady's cauldron looks wrong. 2. During a sword fight the scroll arrows, when highlighted, cover the first pixel column of the text lines. 3. At the top view of Monkey Island the island is outlined in a wrong color (I guess it's a palette bug). 4. At the ghost ship bedroom, Guybrush shines through the bed in the foreground.

That's all, I didn't notice any more bugs. If it wasn't for the lack of sound and music, MI1 would clearly deserve 95% at the compatibility list. Great job!

Ticket imported from: #599442. Ticket imported from: bugs/426.

Change History (16)

comment:1 by SF/inguin, 21 years ago

Priority: normallow

comment:2 by fingolfin, 21 years ago

Issue 1 is now fixed in CVS. Turned out we were not implementing some opcodes, and implemented one incorrectly. Note that this fix could affect other things/ games, too.

comment:3 by SF/khalek, 21 years ago

issues 3 and 4 seem to be fixed as well?

comment:4 by fingolfin, 21 years ago

Issue 3 is still visible in my save games here; however, it is possible that to see the "fix" one has to start a new game, at least that was the case for some MIVGA bug fixes in the past.

What I see is that part where beach ends and the see starts is drawn in wrong color; e.g. initially brown, then I go to another screen (e.g. into the canyon) and go back, and now a different wrong color (pink...) is used.

comment:5 by SF/inguin, 21 years ago

Just tried it again: Issues 2, 3 and 4 still happen.

comment:6 by fingolfin, 21 years ago

Issue 3 seems to be the same bug as in

comment:7 by eriktorbjorn, 21 years ago

The second issue can be fixed with patch #643464, but I don't know if there's a better way.

The third issue is because setPaletteFromPtr() refuses to set any colour except the first 16 ones if R, G and B are at least 252. In this case, it's colour 159 that's supposed to be (252, 252, 252). We can't just remove that check because it'd cause regressions in DOTT (see bug #634424), but apparently something has to be done about it.

From what I understand, this probably means the Zak256 bug fingolfin mentioned has to be something else, because in the screenshot it looks as if it's dark colours that are missing, and this bug only affects very light colours. But since I don't own Zak256 I cannot verify this for myself.

I spent quite some time barking up the wrong trees on this one, and one thing that struck me as odd was case 2 ("room color") of o5_roomOps(). It changes one byte of _currentPalette, i.e. just one colour component. It seems more likely that it should change _shadowPalette[] instead, but I don't know where this would be noticeable. (Hmm... maybe *this* one affects Zak256...?)

comment:8 by eriktorbjorn, 21 years ago

The fourth glitch refers to the bed in the lower left corner, right? I can't say for certain yet, but it looks to me as if the actor isn't supposed to be masked by it. I'll have to check what it looks like with the original interpreter, unless someone beats me to it. (Please do. ;-)

comment:9 by fingolfin, 21 years ago

There is no bug #643464 ?!?

The check in fact looks a bit weird to me... it basicallys says: "treat colors where any componente is >= 252 differently, unless we are in a V7 game".

Which games actually require this? Obviously MonkeyVGA doesn't need it. DOTT needs it I gather from eriktorbjorn's comment. Maybe only V6 games need it? Or maybe no small header game needs it?!? Or what...

I modified the check in my local copy to read: if ((_features & GF_SMALL_HEADER) ||(_features & GF_AFTER_V7) || (i <= 15 || r < 252 || g < 252 || b < 252)) {

and indeed now the palette seems to be just fine.

comment:10 by SF/inguin, 21 years ago

Looks like I was the one to beat eriktorbjorn and he is right: Issue #4 also happens in the original DOS version. So it might look strange, but if it is to be considered a bug, it's a Monkey Island bug rather than a ScummVM bug.

comment:11 by SF/sir_kill_a_lot, 21 years ago

I made some screenshots regarding to issue #4 of MI1VGA (german), using the original exe and scummvm: ghostship_bed-original.png ghostship_bed-scummvm.png so this isn't ScummVM fault, as inguin already said.

But I found another thing that looks wrong, when Guybrush becomes invisible on the ship the visible Guybrush and the unvisible doesn't match eachother. I made a screenshot of the english version using scummvm, and another using the german version with scummvm (in the german version that looks right, so I don't know if it's a bug of MI1VGA-English or ScummVM! Btw, the german MI1VGA [from Monkey Madness CD] has *.lec resource files and no grapical user interface with icons in the inventory as the english version has so they are a little different). invisible-scummvm.png invisible-scummvm.png

Issue #3 also still happens.

comment:12 by fingolfin, 21 years ago

Martin, please submit that in a seperate bug report.

I have just a fix for issue #3, narrowed down to MonkeyVGA.

This only leaves issue 2 open, for which we have a patch on the patch tracker, but I will see if I can find a better solution than the one there.

comment:13 by eriktorbjorn, 21 years ago

> There is no bug #643464 ?!?

Right. But there's a patch with that number. (You've already seen it.)

> DOTT needs it I gather from eriktorbjorn's comment.

I should have clarified that. The full discussion is in bug #634424 -- DOTT: heavy "white" bug. I *think* the test could be changed to ((_features & GF_AFTER_V7) || (i <= 15 || r < 255 || g < 255 || b < 255)) without breaking DOTT or MonkeyVGA, but that's just a guess.

comment:14 by eriktorbjorn, 21 years ago

Eep. Now it checks if _features & GID_MONKEY_VGA instead of _gameId == GID_MONKEY_VGA. That may explain bug report #646184 ("INDY4 INTRO: white indy in room 3?").

comment:15 by fingolfin, 21 years ago

Owner: set to fingolfin
Resolution: fixed
Status: newclosed

comment:16 by fingolfin, 21 years ago

I hereby solemnly close this bug, as a patch for issue #2 was just checked in.

Any problems you encounter from now on are purely a byproduct of your overstressed fantasy and should be documented in a new bug tracker item. Thank you :-)

Note: See TracTickets for help on using tickets.