Menu
▾
▴
#4816 NIPPON: Katana graphics not shown (regression)
ScummVM 1.2.0svn48243 (Mar 12 2010 07:44:55)
Features compiled in: Vorbis FLAC MP3 RGB zLib
Path: Donna
When in the emperors mansion hall, trying to get the Katana from behind the picture there is no resemblance to that there is actually something in this hidden safe. Even after opneing the picture door there is only a small little pixel on the bottom of the safe.
Hovering over it shows "Katana" though and taking it makes it display correctly in the inventory later
Nippon Safes Inc. (Multi-lingual/Amiga)
Amiga OS4
gcc (GCC) 4.2.4 (adtools build 20090118)
walk in the residence, the safe is at the right
Another regression, which occurred between ScummVM 0.11.1 and ScummVM
0.12.0.
This regression was specifically caused by revision 30673.
It looks like animations still aren't sorted, judging by the comment for this revision:
'Animation are not sorted yet, so they can overlap in an inconsistent fashion for the time being.'
Any news on this, peres?
As Kirben noted, this is a sorting issue. A stopgap measure could be raising the z coordinate of the katana object at load time (putting a kludge in the parser).
This bug is nice to get fixed before the release. Raising priority for keeping the track.
Tested with Nippon Safes (Amiga) and:
ScummVM 1.4.0git1802-g0382e99-dirty (Aug 25 2011 01:50:57)
Features compiled in: Vorbis FLAC MP3 ALSA SEQ TiMidity RGB zLib
FluidSynth Theora AAC
Still occuring.
Revision 30673 suspected to be the point of breakage is now Git be2c5d3c8772963fe2c1a00c1a50546438e3e7a5
Have confirmed this and performed some investigation.
The console "gfxobjects" command gives a breakdown of the graphics objects being drawn. The "katana" object has a z (depth) of -100 along with 4 other objects.
The code which sorts the scene objects (sortScene() in gfxbase.cpp) uses another function (compareZ() in gfxbase.cpp) to determine the ordering of objects (which I think also defines the drawing order i.e. back to front or rather lowest z to highest). I suspect the cause of this bug is the logic which deals with ordering when the objects have the same z i.e. depth, which is not "correct" i.e. as per prior to the regression point.
Added a hack to fix this in HEAD. As explained in the hack:
The katana object has the same default z index (kGfxObjGetZ or -100)
as the cripta object (the safe).
Game scripts do not set an explicit z for the katana (as it isn't an
animation), but rather rely on the draw order to draw it over the
safe. In this particular case, the safe is added to the scene after
the katana, thus it is drawn over the katana. We explicitly set the
z index of the katana to be higher than the safe, so that the katana
is drawn correctly over it.
This is a regression from the graphics rewrite (commits be2c5d3,
3c2c16c and 44906f5).
Reducing the priority of this one, as it is resolved with the hack, but keeping it open till peres has time to properly look into it
Update: according to peres, this is a script bug, so the aforementioned fix (a workaround for the script bug) is the right thing to do - closing