GOB: Goblins Quest 3 - graphic issue on first level

[joshas]

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.

[joshas]

ScummVM

[joshas]

DosBox

[joshas]

Game version:
1.000
Goblins Quest 3
March 17, 1994

[raziel-]

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

[theruler]

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):
​https://youtu.be/kNvqRw9XFBQ?t=220

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

[joshas]

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

[digitall]

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;
+                       }
                        _vm->_draw->spriteOperation(DRAW_BLITSURF);
                }
        }

[theruler]

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

[antoniou79]

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:
​https://github.com/scummvm/scummvm/commit/5681ae1e82ba2c125928ecbfbd937cb187c06aa4

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.

[sdelamarre]

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