Opened 10 years ago
Last modified 5 years ago
#6674 new defect
SWORD1: Minor graphical glitch when knocked down by Goat
| Reported by: | SF/diggly | Owned by: | |
|---|---|---|---|
| Priority: | low | Component: | Engine: Sword1 |
| Version: | Keywords: | original | |
| Cc: | Game: | Broken Sword 1 |
Description
1.7.0git7802-gae26f95 (64-bit) Playing Windows version of the game. After getting knocked down by the goat, part of the sandbags appears to briefly disappear when you get up.
Ticket imported from: bugs/6674.
Attachments (5)
Change History (23)
by , 10 years ago
| Attachment: | sword1.007 added |
|---|
by , 10 years ago
| Attachment: | scummvm00001.png added |
|---|
comment:1 by , 10 years ago
comment:2 by , 10 years ago
| Summary: | minor graphical glitch → SWORD1: Minor graphical glitch when knocked down by Goat |
|---|
comment:3 by , 10 years ago
diggly: Can you try to replicate this with the original interpreter under Win32 please, and attach an original interpreter savegame at this point for comparison. Thanks.
comment:4 by , 10 years ago
I can confirm the same problem occurs with the mac version as well. Will try to replicate with the original interpreter.
by , 10 years ago
| Attachment: | SAVEGAME.004 added |
|---|
comment:5 by , 10 years ago
Here's a screenshot and savegame from playing it in DOSBox. I could not reproduce the glitch there.
comment:6 by , 7 years ago
This is still present in latest scummvm.
ScummVM: 1.10.0git-5274-gbd82345 (Oct 26)
Game: Sword1 GOG/English
comment:7 by , 7 years ago
| Priority: | normal → low |
|---|
comment:8 by , 5 years ago
This is still occurring in the latest git master on Linux x86_64 i.e. dca112f94b188f797f42eababb39aef9bb891832 as of 2019-10-21.
Doing some digging into the SWORD1 engine code and adding some debugging to try to drill down to what is happening here. For starters, this screen/room is number 24 which is found in the _currentScreen variable.
comment:9 by , 5 years ago
By changing https://github.com/scummvm/scummvm/blob/master/engines/sword1/staticres.cpp#L1809 from {R24PLX,0}, to {0,0}, the front occluding parallax layer of the castle wall can be removed from the drawing, this does not break the engine and the bug can still be reproduced.
The issue is a redraw order / occlusion bug where one of the two screen layers (containing part of the sandbags) is incorrectly drawn after George (Ego) is drawn during him standing up which causes them to appear in front of him in a very blocky way. Basically it reveals the square seam between the front and back layers.
comment:10 by , 5 years ago
OK, the issue is coming from https://github.com/scummvm/scummvm/blob/master/engines/sword1/screen.cpp#L441 .. The _sortList[cnt].id has two objects at this point object #0 with id 1572868 and #1 with id 8388608.
I will need to confirm, but I think these are George (Ego) and the Goat respectively. I think the sandbags are part of George at this point... I think they are meant to be drawn first and then his "getting up" animation drawn over them to ensure that he doesn't leave a pixel trail on background... but the order is inverted for part of the movement. Will track down further...
comment:11 by , 5 years ago
Right... 1572868 is the goat which has one frame of George when he butts him, so the issue is in id 8388608 which is George ... including a few frames of sandbags.
comment:12 by , 5 years ago
Right for id 8388608 (George), the processImage() function has compact->o_resource: 168165386 at o_frame 23 when he has been knocked down by the goat. The glitch appears once he is clicked to get up when the compact->o_resource changes to 168165398 which I think has the glitch from o_frame 0 to around 12.
comment:14 by , 5 years ago
Hmm... Think I will need to play through with the original interpreter in DOSBox to determine if this was present in the original. @eriktorbjorn indicated that it was not, but his screenshot is not definitive and the savegame he indicated is not attached. :|
comment:15 by , 5 years ago
It might be an issue with the previous animation of George falling down in terms of overdrawing the sandbags in the foreground. The original interpreter might have cut off this animation early to avoid this, but will need to playtest to see what the original behaviour was.
comment:16 by , 5 years ago
"and the savegame he indicated is not attached. :|"
It's been years, but if I did attach a savegame, then surely it's the SAVEGAME.004 file? That one doesn't work?
comment:17 by , 5 years ago
@eriktorbjorn: Mea Culpa. I found it under the Attachments dropdown of the ticket. It is not shown in the comment, only "Attachment: sword1-dosbox.png added" so I had thought that this had got lost in the migration to Trac. Right, will test using that savegame with the original interpreter and see what happens. Thanks.
comment:18 by , 5 years ago
@eriktorbjorn: I was able to get this running in DOSBox using your savegame. I _CAN_ replicate the same graphical glitch running under the original interpreter. It only occurs when you get up after being knocked down with a part of the wall / sandbags being at the wrong priority i.e. z-order.
Since this occurs in the original, I am lowering the bug priority. Not sure if we can fix this.
comment:19 by , 5 years ago
| Keywords: | original added |
|---|
by , 5 years ago
| Attachment: | dosbox-bug-in-original.png added |
|---|
DOSBox Screenshot showing bug in original interpreter
screenshot