Opened 15 years ago

Closed 14 years ago

Last modified 14 years ago

#1825 closed defect (fixed)

COMI: Actor redraw glitch

Reported by: SF/mnbv Owned by: fingolfin
Priority: normal Component: Engine: SCUMM
Keywords: Cc:
Game: Monkey Island 3

Description

On the beach of Booty Island, at the start of part 2,
the water ripples are in front of the statue of Elaine
rather than between her and the ocean.

ScummVM 0.7.0CVS (Nov 13 2004 15:29:08)
compiled with gcc 3.3.5
played on debian unstable
using the English version of CoMI.

I don't have a save game right now but if you can't
reproduce the bug I'll go back and try to make one.

I've only just got the game so don't know if it's
occured before.

Ticket imported from: #1066329. Ticket imported from: bugs/1825.

Attachments (3)

comi.s01 (52.8 KB ) - added by eriktorbjorn 15 years ago.
Savegame at the end of part 1
comi.s13 (58.4 KB ) - added by SF/mnbv 15 years ago.
CoMI water bug save
cannon-pie-glitch.jpg (84.8 KB ) - added by joostp 15 years ago.
Shows the priority problem on the Carnaval

Download all attachments as: .zip

Change History (24)

comment:1 by sev-, 15 years ago

Summary: Graphical glitch on beachCOMI: Wrong actors priority (regression)

comment:2 by sev-, 15 years ago

Unfortunately we can't check the bug because of abscence of
the savegame. We don't have saves in each point of the game,
so, please, provide it.

by eriktorbjorn, 15 years ago

Attachment: comi.s01 added

Savegame at the end of part 1

comment:3 by eriktorbjorn, 15 years ago

Sheesh, it's almost at the beginning of the game. Here's a
savegame (English version) at the end of part 1.

I can't reproduce the bug, though. The only thing that seems
a bit strange - and I don't think that's a regression - is
that the music stops.

comment:4 by SF/mnbv, 15 years ago

Sorry, but as you said it was near the beginning, I didn't
think to save at the time, my bad.

Any how I've attached a save file that shows the error. To
get it I had to leave the area and go to the island map and
then return to the fort.

by SF/mnbv, 15 years ago

Attachment: comi.s13 added

CoMI water bug save

comment:5 by eriktorbjorn, 15 years ago

Strange. I can see it with your savegame, but still not with
mine.

comment:6 by SF/mnbv, 15 years ago

I noticed, when I made the save file, that when start of
chapter cut scene first ended the ripples were in the
correct place. It wasn't until I went to the map and then
returned to the fort/beach that the ripples moved to the
wrong place.

comment:7 by eriktorbjorn, 15 years ago

So you said, so I walked around for a while with my savegame
and still wasn't able to trigger it. I wonder which
particular action the bug is tied to...

comment:8 by fingolfin, 15 years ago

mnbv, can you reproduce the bug if you start a new game
from scratch? Or only with that particular save game?

comment:9 by SF/mnbv, 15 years ago

I just updated to the latest cvs available and started the
game from scratch. By just leaving and returning to the fort
area I was unable to reproduce the bug. However by various
combinations of looking, talking and taking the statue then
leaving and returning to the fort area I did manage to
reproduce the bug several times.
Also the bug occurred more often if I let the monologue
finish on it's own rather than clicking both mouse buttons
to end it early.

comment:10 by joostp, 15 years ago

This sounds similar to a problem I just experienced with current CVS, so
I'll mention it in this report instead of creating a seperate one.

The Carnaval seem to suffer from this same 'priority' glitch, every few
seconds it alternates between some erroneous (background?) graphics
and the correct cannon and pies.

To reproduce use boot param 1020, and walk away from the cannon. You
should see the glitch as depicted in the attached screenshot.

by joostp, 15 years ago

Attachment: cannon-pie-glitch.jpg added

Shows the priority problem on the Carnaval

comment:11 by fingolfin, 15 years ago

Very useful, joostp. I'll only talk about the bootparam 1020 in
the following, as it is trivial to reproduce.

Just to clarify this: the problem is not the drawing order or
anything like that. Rather, whenever Wharf is not being animated
(i.e. when he stands still), the flickering sign will sometimes
be drawn atop him, because he doesn't get redrawn.

Normally, the code will redraw an actor when it is explicitly
told so, or when the actor overlaps another (which is the case
here). For some reasons, this fails. I am not yet sure why this
happens though.

Note: I recall that we had a somewhat similar problem in the
Nexus with Commander Low standing in front of the sparking
thingy. The sparks were sometimes drawn over Low. I commited a
fix for this a looong time ago (actor.cpp rev 1.49), but that
change was partially reverted because it caused a hang elsewhere.
So I am not exactly sure why the sparks work correctly now.

comment:12 by fingolfin, 15 years ago

Observation: normally, when two actors occupy the same strip,
they are both redrawn. What happens here is that even though
actors 3 (Wharf Rat) and 20 (the sign) overlap, only actor 20 is
drawn, causing it to (incorrectly) appear above actor 30.

This is what happens: to detect actor overlap, the GFX usage bits
are checked. If two actors occur in the same strip, both are
marked for redraw. In this case, actor 3 is marked as drawn in
the correct strips/usage bits. However, actor 20 is *not*
flagged as drawn in the usage bits!

So, when it's time to draw actor 20, it is drawn, but actor 3 is
not drawn again (after all it is not marked as being in need of a
redraw). So we end up with the wrong draw order. (I'll talk about
the cause of this in a moment)

Then, in the next main loop iteration, the system detect that
actor 3 and 20 overlap (since the usage bits for both are set
now), and causes both to be redrawn. As a result, everything
looks right again.

Then actor 20 is undrawn again (the sign "flickers off"). Still
all is fine, but the GFX usage bits for it are removed. Hence
when it flickers back on, we get the redraw problem again, see
above.

The problem is hidden as long as Wharf Rat moves, because then
he's constantly being redrawn anyway; so you can only observe the
bug while he stands still

Now, to the cause of all this: It apperas the core of the problem
is that the sign consists of two parts which flicker on/off
alternatingly and indepently. So, the actor is actually always
being drawn, but in completely different areas of the screen.
While this is simply a matter of the costume, to the system it
look as if the sign "jumps around". This breaks resetActorBgs,
which removes an actor from the usage bits when its needRedraw
flag is set. If it wasn't for this, all would be fine...

There are various ways this could be "fixed", but I have no idea
what is the correct solution. Looking at scummvm-2001-10-08, the
actor redraw flags are implemented very differently there -- so I
assume Monkey2, on which that release was based, also handled it
differently. The current code in ScummVM was done by me based on
V3/V4 disassembly, and it fixed some redrawing bugs in other
games/places (sadly I don't recall which exactly). Looking at
some old stuff, it seems I may not have done this quite right
(there seems to be a "redraw counter" there, so actors could not
just be marked as in need of redraw; they sometimes were marked
as being in need of two redraws. Finally, it's possible that COMI
actually does this yet again differently...

Conclusion: it might be best if somebody would check the
disassembly of COMI.

comment:13 by fingolfin, 15 years ago

Summary: COMI: Wrong actors priority (regression)COMI: Wrong actors priority

comment:14 by fingolfin, 15 years ago

This is not a regression, it also happens with 0.6.1b.

comment:15 by fingolfin, 15 years ago

BTW, I played with reverting the draw flag changes to resemble how the
code used to be in that old CVS version. Alas, that didn't change anything.

Still would be nice if somebody could check COMI disasm :-)

comment:16 by Kirben, 15 years ago

The needRedraw and needBgReset actor fields doesn't exist
in original COMI, so not sure where to look. The original
appears to always redraw all actors.
Would disasm. of processActors() be helpful ? there doesn't
appear to be anything like resetActorBgs() or
setActorRedrawFlags().

comment:17 by fingolfin, 15 years ago

Disasm of processActors would be interesting, yeah

comment:18 by fingolfin, 15 years ago

Actually, looking at processActors and the disasm now, I realize that it's
the wrong place to look, since the redraw flags aren't used there at all --
rather they are checked in Actor::drawActorCostume().

comment:19 by fingolfin, 14 years ago

Summary: COMI: Wrong actors priorityCOMI: Actor redraw glitch

comment:20 by fingolfin, 14 years ago

Fixed in CVS by always redrawing all actors in COMI. This
seems to match disasm, but there still could be
regressions... we'll see!

comment:21 by fingolfin, 14 years ago

Owner: set to fingolfin
Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.