#3704 closed defect (fixed)
AGI: Fan(Kings Quest 2 1/4) - Sprite not erased
| Reported by: | raziel- | Owned by: | sev- |
|---|---|---|---|
| Priority: | normal | Component: | Engine: AGI |
| Version: | Keywords: | ||
| Cc: | Game: | AGI Fanmade |
Description
ScummVM 0.12.0svn (Apr 18 2008 07:29:15) Features compiled in: Vorbis FLAC MP3 zLib MPEG2
After the death through falling from the "path" the "dead" sprite is drawn over the last instance of the "falling sprite as shown in the screenshot.
Might be happening in the original aswell, can't test because neither AGIv2 nor the provided exe will run (the game) under DOSBox for me
AGI Fangame (Kings Quest 2 - Breast Intentions (v2.0)/DOS/English)
AmigaOS4 gcc version 4.0.2 (AmigaOS build 20051012)
Ticket imported from: #1945716. Ticket imported from: bugs/3704.
Attachments (2)
Change History (6)
by , 17 years ago
| Attachment: | AGI_KQ2_Breast_Double_Sprite.png added |
|---|
comment:2 by , 16 years ago
This is the exact same problem with the one in bug "#1658643: AGI: SQ1 (2.2 DOS ENG) Graphic error, ego leaves behind copy", which has been corrected for that bug in AgiEngine::setView().
The problem here is that there is already a view in the same view slot as the one specified in setView(), which is still drawn. I believe that the original did full screen updates in such cases, so it the bug is not shown, as the new frame including the new view completely overwrites the old one (though I could be wrong about this).
My solution to fix this situation was to check if there is a sprite in the specified view array index which is drawn on screen. If this is true, then the sprite is erased and the new one is then drawn normally. Unfortunately, this approach caused the new sprite to disappear when a text box was shown on screen, as described in bug "#1715284: Roger sometimes disappears", therefore it is currently only applied to the situation described in bug #1658643. We should check how other AGI interpreters handle this case (e.g. NAGI) or check how the original does it, as the approach I took for the other bug is not based on dissassembly, so applying the same workaround for this bug means that it will likely pop up again in the future
comment:3 by , 14 years ago
Fixed in svn by adding a workaround. Actually the reason is independent. It was caused by limitation of our rendering system which differs from original.
comment:4 by , 14 years ago
| Owner: | set to |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
hmm