Opened 8 years ago
Closed 11 months 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 |
Description
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)
Change History (10)
by , 8 years ago
Attachment: | gob3_scummvm.png added |
---|
comment:2 by , 4 years ago
Summary: | GOB3: graphics issues on first level → GOB: 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 , 4 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):
https://youtu.be/kNvqRw9XFBQ?t=220
Hope it helps, the bug is 4 years old now.
comment:5 by , 2 years 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; + } _vm->_draw->spriteOperation(DRAW_BLITSURF); } }
comment:6 by , 16 months ago
Just a reminder.
Issue still present on ScummVM 2.8.0git6236 windows-x86-64-master-ca36141f.
comment:7 by , 11 months 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:
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.
comment:8 by , 11 months ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Now fixed in master!
Many thanks @antoniou79 for catching this!
ScummVM