#4816 closed defect (fixed)
NIPPON: Katana graphics not shown (regression)
| Reported by: | raziel- | Owned by: | bluegr |
|---|---|---|---|
| Priority: | normal | Component: | Engine: Parallaction |
| Version: | Keywords: | ||
| Cc: | Game: | Nippon Safes |
Description
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)
Ticket imported from: #2969913. Ticket imported from: bugs/4816.
Attachments (1)
Change History (15)
comment:1 by , 14 years ago
| Owner: | set to |
|---|
by , 14 years ago
| Attachment: | nippon.009 added |
|---|
comment:2 by , 14 years ago
Another regression, which occurred between ScummVM 0.11.1 and ScummVM 0.12.0.
comment:3 by , 14 years ago
| Priority: | normal → high |
|---|
comment:4 by , 14 years ago
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.'
comment:5 by , 14 years ago
| Summary: | NIPPON: Katana graphics not shown → NIPPON: Katana graphics not shown (regression) |
|---|
comment:7 by , 14 years ago
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).
comment:8 by , 14 years ago
This bug is nice to get fixed before the release. Raising priority for keeping the track.
comment:9 by , 13 years ago
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
comment:10 by , 13 years ago
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.
comment:11 by , 13 years ago
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
comment:12 by , 13 years ago
| Priority: | high → low |
|---|
comment:13 by , 13 years ago
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
comment:14 by , 13 years ago
| Owner: | changed from to |
|---|---|
| Priority: | low → normal |
| Resolution: | → fixed |
| Status: | new → closed |
walk in the residence, the safe is at the right