Opened 13 years ago
Closed 13 years ago
#5262 closed defect (fixed)
LURE: Failed assertion in EGA version
|Reported by:||SF/fizzet||Owned by:||dreammaster|
|Cc:||Game:||Lure of the Temptress|
Crash occurs in scummvm 1.1.1 with the LotT EGA version. VGA is fine.
When using the tinderbox with the oil burner in Taidgh's house, the following assertion failure occurs:
scummvm: ./engines/lure/hotspots.h:295: void Lure::Hotspot::setFrameNumber(uint16): Assertion `frameNum < _numFrames' failed. Aborted
Save file at that position attached.
Ticket imported from: #3047234. Ticket imported from: bugs/5262.
Change History (7)
by , 13 years ago
comment:1 by , 13 years ago
comment:2 by , 13 years ago
Replicated with HEAD i.e. ScummVM 1.2.0svn52199 (Aug 18 2010 23:46:53) Features compiled in: Vorbis FLAC MP3 ALSA SEQ RGB zLib FluidSynth using attached savegame.
I didn't playtest the EGA version, only VGA. Will test now with HEAD and see if this is a reliable blocker.
comment:3 by , 13 years ago
I can reliably replicate this from a clean start with HEAD (r52216). By enabling debug output, I get the following :
Hotspot 421h tick begin Executing hotspot 421h script pos=24h SET FRAME NUMBER = 6 Hotspot 421h tick end Hotspot 423h tick begin Executing hotspot 423h script pos=a64h SET FRAME NUMBER = 23 scummvm: ./engines/lure/hotspots.h:295: void Lure::Hotspot::setFrameNumber(uint16): Assertion `frameNum < _numFrames' failed. Aborted
Using debug command "rooms", this is identified as Room 30 and running the debug command "hotspots 30" prior to doing "Use Tinderbox on Oil Burner" gives the following :
3e8h - Diremot pos=(157,112,30) 423h - None pos=(145,102,30) 424h - Oil Burner pos=(-8,133,30) 2718h - Door pos=(66,133,30) 753dh - Tap pos=(2767,-127,30) 755fh - Apparatus pos=(415,-218,30)
Will see if I can get closer to the point of issue, by comparing with the VGA version.
comment:4 by , 13 years ago
By comparing with the VGA version, Hotspot 423h has 45 frames and is set to a maximum of 44, but it is showing only 23 in the EGA version...
comment:5 by , 13 years ago
I appreciate the time you've taken to diagnose the problem. One of the benefits of ScummVM, as repeatedly demonstrated frequently recently for the SCI engine, is that our code can frequently detect scripting errors in the original game that may not have been immediately obvious. An invalid frame number used in the scripts would simply end up calculating an offset and showing some garbage frames without causing an error.
I really should also double check with the original game disassembly before I make a patch. I'm currently away from my main system until early next week, though, so I'll look into it further once I get back.
comment:6 by , 13 years ago
|Status:||new → closed|
Game saved just prior to the crash