Opened 8 years ago

Closed 4 years ago

#5674 closed defect (fixed)

AGI: SQ2: Gfx glitch at intro logo "Chapter 2"

Reported by: SF/mokeiichi Owned by: m-kiewitz
Priority: high Component: Engine: AGI
Keywords: Cc:
Game: Space Quest 2

Description

Sorry if this is a duplicate, I remember having seen this bug reported before, but couldn't find it.

In the intro of the game "Chapter II" looks wrong. See attached screenshots. When those long lines aren't there yet, they also shouldn't be visible behind the text. When they are displayed, they also should behind the text. Right now it's (almost) the opposite.

Ticket imported from: #3292787. Ticket imported from: bugs/5674.

Attachments (2)

sq2-scummvm01.png (1.9 KB ) - added by SF/mokeiichi 8 years ago.
GFX Glitch in SQ2 - 01
sq2-scummvm02.png (2.6 KB ) - added by SF/mokeiichi 8 years ago.
GFX Glitch in SQ2 - 02

Download all attachments as: .zip

Change History (12)

by SF/mokeiichi, 8 years ago

Attachment: sq2-scummvm01.png added

GFX Glitch in SQ2 - 01

by SF/mokeiichi, 8 years ago

Attachment: sq2-scummvm02.png added

GFX Glitch in SQ2 - 02

comment:1 by SF/mokeiichi, 8 years ago

SQ2 Version 2.0F
ScummVM 4f708b0 (24.04.2011)

comment:2 by digitall, 8 years ago

Replicated this with the latest Git Master on Linux x86_32 i.e.
ScummVM 1.4.0git2461-ga6b7968-dirty (Sep 25 2011 13:22:57)
Features compiled in: Vorbis FLAC MP3 ALSA SEQ TiMidity RGB zLib FluidSynth Theora AAC

Checked with original interpreter in DOSBox and confirmed as per submitter report i.e. The original interpreter behaviour is different to ScummVM AGI

comment:3 by sev-, 8 years ago

This bug is nice to get fixed before the release. Raising priority for keeping the track.

comment:4 by sev-, 8 years ago

Priority: normalhigh

comment:5 by eriktorbjorn, 6 years ago

NAGI seems to handle this correctly, but I don't know enough about AGI to figure out what they do differently.

comment:6 by wjp, 6 years ago

At both points (lines appearing too soon and later disappearing too soon) it seems that the text sprite being drawn blits a newly rendered background picture too soon.

As far as I can tell this happens due to a scheduleUpdate being called on the text sprites while pictureShown is true, but the corresponding doUpdate only being called after pictureShown has been set to false by rendering the new pic.

This all happens within the cmdDrawPic sequence:

state->_vm->_sprites->eraseBoth();
state->_vm->_picture->decodePicture(_v[p0], true);
state->_vm->_sprites->blitBoth();
state->_vm->_sprites->commitBoth();
state->pictureShown = 0;

Unsure how to fix. Maybe set pictureShown to false immediately after decodePicture here in cmdDrawPic?

comment:7 by m-kiewitz, 4 years ago

Owner: set to m-kiewitz

comment:8 by m-kiewitz, 4 years ago

this bug seems to be solved in my current work-in-progress graphics rewrite.
Marking for later.

comment:9 by m-kiewitz, 4 years ago

This is now fixed by commit 8a595e7771aa89d06876e13d7ab6751e26da8982

comment:10 by m-kiewitz, 4 years ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.