#1825 closed defect (fixed)
COMI: Actor redraw glitch
| Reported by: | SF/mnbv | Owned by: | fingolfin |
|---|---|---|---|
| Priority: | normal | Component: | Engine: SCUMM |
| Version: | 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)
Change History (24)
comment:1 by , 19 years ago
| Summary: | Graphical glitch on beach → COMI: Wrong actors priority (regression) |
|---|
comment:2 by , 19 years ago
comment:3 by , 19 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 , 19 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.
comment:6 by , 19 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 , 19 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 , 19 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 , 19 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 , 19 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 , 19 years ago
| Attachment: | cannon-pie-glitch.jpg added |
|---|
Shows the priority problem on the Carnaval
comment:11 by , 19 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 , 19 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 , 19 years ago
| Summary: | COMI: Wrong actors priority (regression) → COMI: Wrong actors priority |
|---|
comment:15 by , 19 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 , 19 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:18 by , 19 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 , 19 years ago
| Summary: | COMI: Wrong actors priority → COMI: Actor redraw glitch |
|---|
comment:20 by , 19 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 , 19 years ago
| Owner: | set to |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
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.