Opened 7 years ago

Closed 7 weeks ago

#9682 closed defect (fixed)

GOB: Goblins Quest 3 - graphic issue on first level

Reported by: joshas Owned by:
Priority: low Component: Engine: Gob
Version: Keywords:
Cc: Game: Goblins 3


In first level on far right side of screen there is a railing displayed, which should not be there. Compare attached screenshots from ScummVM (1.9.0, same issue with current daily build) and DosBox.

Attachments (2)

gob3_scummvm.png (25.0 KB ) - added by joshas 7 years ago.
gob3_dosbox.png (21.1 KB ) - added by joshas 7 years ago.

Download all attachments as: .zip

Change History (10)

by joshas, 7 years ago

Attachment: gob3_scummvm.png added


by joshas, 7 years ago

Attachment: gob3_dosbox.png added


comment:1 by joshas, 7 years ago

Game version:
Goblins Quest 3
March 17, 1994

comment:2 by raziel-, 4 years ago

Summary: GOB3: graphics issues on first levelGOB: Goblins Quest 3 - graphic issue on first level

ScummVM 2.2.0git (Jul 15 2020 10:24:49)
Features compiled in: Vorbis FLAC MP3 RGB zLib MPEG2 Theora AAC A/52 FreeType2 FriBiDi JPEG PNG cloud (servers, local)

The issue is still there with above version of ScummVM.

Goblins Quest 3 CD (v1.000/DOS/English (US))

AmigaOS4 - PPC - SDL - BE

comment:3 by theruler, 3 years ago

It should have to do with the animation of blunt that jumps down from the head to the hand. That it is slight offset and doesn't show the stretching nose.
It occurs even on the italian version and scummvm windows 64bit latest build (15 feb 2021).

here is the exact point (from a 2017 walkthrough):

Hope it helps, the bug is 4 years old now.

Last edited 3 years ago by theruler (previous) (diff)

comment:4 by joshas, 19 months ago

Issue still exists on ScummVM 2.6.0 (Aug 1 2022 22:34:59)

comment:5 by digitall, 19 months ago

Did some investigation since we don't have many active developers for the GOB engine.

The following code should workaround the observed issue and is a good start for tracking down the root cause here.

diff --git a/engines/gob/scenery.cpp b/engines/gob/scenery.cpp
index cd9387c5b2e..5ad835303f2 100644
--- a/engines/gob/scenery.cpp
+++ b/engines/gob/scenery.cpp
@@ -301,6 +301,10 @@ void Scenery::renderStatic(int16 scenery, int16 layer) {
                        _vm->_draw->_spriteRight   = right - left + 1;
                        _vm->_draw->_spriteBottom  = bottom - top + 1;
                        _vm->_draw->_transparency  = planePtr->transp ? 3 : 0;
+                       if (scenery == 1 && layer == 0) {
+                               debug(1, "plane: %d pieceIndex: %d destX: %d destY:%d pictIndex:%d src: %d l:%d t:%d r:%d b:%d", plane, pieceIndex, _vm->_draw->_destSpriteX, _vm->_draw->_destSpriteY, pictIndex, _vm->_draw->_sourceSurface, _vm->_draw->_spriteLeft, _vm->_draw->_spriteTop, _vm->_draw->_spriteRight, _vm->_draw->_spriteBottom);
+                               if (pieceIndex == 2 && _vm->_draw->_destSpriteX == 455) continue;
+                       }

comment:6 by theruler, 7 months ago

Just a reminder.
Issue still present on ScummVM 2.8.0git6236 windows-x86-64-master-ca36141f.

comment:7 by antoniou79, 8 weeks ago

Looking into this since this morning, the cause of the issue for Goblin's 3 (DOS) is that our rendering loops in Scenery::updateStatic() and Scenery::renderStatic() allow drawing "order" up to 99 (order < 100) for a static sprite, while the original only goes up to 39 ( order < 40 ).

The awry sprite's position and dimensions are in the game's resource files (EXT.STK) but its drawing order is "59". My assumption here is that this is a remnant of testing from the developers that was then set to "59" (instead of deleting it) and the engine would not draw it anymore. (This room also loads another sprite that is not drawn (...), which also seems to be from some testing attempts -- this one is in scenery 0 layer 1 and as far as I can tell is a duplicate of the valid railing sprite to the right in scenery 1 but positioned at X: 0, ie. left edge of the screen).

I have only checked the disassembly of GOB3CD, though.

The culprit commit according to git blame is this one, which explicitly mentions fixing something for GOB3's drawing order:

Was the "100" loop value chosen because it's in some other GOB engine variation or was it set as a more relaxed limit?

If anyone can test running the original CD game via DOSBOX or such, they could try changing the drawing order of the awry sprite to a value less than 40 (eg. 0x27 hex) in the EXT.STK file at offset 0xC4FCD (original hex value is: 0x3B), and the original game should start rendering the glitch.

Edit: GOB2CD also has 40 as draw order limit.

Last edited 8 weeks ago by antoniou79 (previous) (diff)

comment:8 by sdelamarre, 7 weeks ago

Resolution: fixed
Status: newclosed

Now fixed in master!
Many thanks @antoniou79 for catching this!

Note: See TracTickets for help on using tickets.