Opened 14 years ago

Closed 13 years ago

Last modified 13 years ago

#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


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- 14 years ago.
walk in the residence, the safe is at the right

Download all attachments as: .zip

Change History (15)

comment:1 by jvprat, 14 years ago

Owner: set to peres

by raziel-, 14 years ago

Attachment: nippon.009 added

walk in the residence, the safe is at the right

comment:2 by Kirben, 14 years ago

Another regression, which occurred between ScummVM 0.11.1 and ScummVM 0.12.0.

comment:3 by Kirben, 14 years ago

Priority: normalhigh

comment:4 by Kirben, 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 Kirben, 14 years ago

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

comment:6 by fingolfin, 14 years ago

Any news on this, peres?

comment:7 by peres, 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 sev-, 14 years ago

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

comment:9 by digitall, 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 digitall, 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 bluegr, 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 bluegr, 13 years ago

Priority: highlow

comment:13 by bluegr, 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 bluegr, 13 years ago

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