Opened 9 years ago

Closed 8 years ago

Last modified 8 years ago

#4816 closed defect (fixed)

NIPPON: Katana graphics not shown (regression)

Reported by: raziel- Owned by: bluegr
Priority: normal Component: Engine: Parallaction
Keywords: Cc:
Game: Nippon Safes


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)

nippon.009 (365 bytes) - added by raziel- 9 years ago.
walk in the residence, the safe is at the right

Download all attachments as: .zip

Change History (15)

comment:1 Changed 9 years ago by jvprat

Owner: set to peres

Changed 9 years ago by raziel-

Attachment: nippon.009 added

walk in the residence, the safe is at the right

comment:2 Changed 9 years ago by Kirben

Another regression, which occurred between ScummVM 0.11.1 and ScummVM

comment:3 Changed 9 years ago by Kirben

Priority: normalhigh

comment:4 Changed 9 years ago by Kirben

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 Changed 9 years ago by Kirben

Summary: NIPPON: Katana graphics not shownNIPPON: Katana graphics not shown (regression)

comment:6 Changed 9 years ago by fingolfin

Any news on this, peres?

comment:7 Changed 9 years ago by 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).

comment:8 Changed 9 years ago by sev-

This bug is nice to get fixed before the release. Raising priority for keeping the track.

comment:9 Changed 8 years ago by digitall

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 Changed 8 years ago by digitall

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 Changed 8 years ago by bluegr

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 Changed 8 years ago by bluegr

Priority: highlow

comment:13 Changed 8 years ago by bluegr

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 Changed 8 years ago by bluegr

Owner: changed from peres to bluegr
Priority: lownormal
Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.