#6744 closed defect (fixed)
SCI: Camelot - Textbox glitch on Map after loading
| Reported by: | raziel- | Owned by: | m-kiewitz |
|---|---|---|---|
| Priority: | normal | Component: | Engine: SCI |
| Version: | Keywords: | ||
| Cc: | Game: | Conquests of Camelot |
Description
ScummVM 1.8.0git (Nov 6 2014 19:33:16) Features compiled in: TAINTED Vorbis FLAC MP3 RGB zLib MPEG2 Theora AAC FreeType2 JPEG PNG
There is a glitch with the location textbox on the South England Map after loading a save state. When loading the attached save the textbox gets erased and leaves a black rectangle. [1] (It gets redrawn immediately after Arthur moves to another location.) On loading the same save (in-game) after Arthur has been moved to another location the issue is still there, but only a few locations will trigger it (and i haven't been able to get the black rectangle again) with a partially erased textbox. [2]
This is on the console, i'm not sure if it's related, i get those a lot when playing. User picked target 'camelot-amiga' (gameid 'sci')... Looking for a plugin supporting this gameid... SCI [SCI0, SCI01, SCI10, SCI11] Starting 'Sierra SCI Game' WARNING: Failed to locate base object for object at 0022:0E52; skipping!,
Conquests of Camelot: King Arthur, Quest for the Grail (Amiga/English)
AmigaOS4 - PPC - SDL - BE gcc (GCC) 4.2.4 (adtools build 20090118)
[1] - Conquest of Camelot_King Art_000.png [2] - Conquest of Camelot_King Art_001.png
Ticket imported from: bugs/6744.
Attachments (4)
Change History (15)
by , 9 years ago
| Attachment: | camelot-amiga.029 added |
|---|
by , 9 years ago
| Attachment: | Conquests of Camelot_ King Art_000.png added |
|---|
comment:1 by , 9 years ago
by , 9 years ago
| Attachment: | Conquests of Camelot_ King Art_001.png added |
|---|
comment:4 by , 9 years ago
Of course.
The original interpreter erases the location window, so that only the horse/arthur sprite and the whole map is seen.
comment:5 by , 9 years ago
Replicated under ScummVM with the DOS version. The original interpreter indeed erases the location box when saving and presumably does not save it, so no such bug after loading a savegame.
comment:6 by , 9 years ago
Could you please try again using latest daily build? I managed to get a horse, tried to save + load at "Glastonbury Tor" and everything works correctly. Maybe I'm doing something wrong.
In case it doesn't, please open the file called "VERSION" using a texteditor and tell me what's in it.
comment:7 by , 9 years ago
It shouldn't matter where you save or where you stand on loading, as it corrupts the box of nearly every location.
I re-copied, re-installed and re-added the game from my floppies, the issue is still there unfortunately.
Now for the version, this is kind of stupid...i have six disks for Camelot Amiga which all hold a "version" file. Disks 2 to 5 have the version "1.008.000" in it Disk1 and 6 have the version "1.009.000" in it. I guess they mastered version "1.009.000" and forgot to change the other disks?
In addition to the log warning in the first post i now get this everytime i load the savestate (on location Camelot): WARNING: Failed to locate base object for object at 001F:0E52; skipping! WARNING: Attempt to free Hunk from address 0026:0068: Invalid segment type 0! WARNING: Attempt to free Hunk from address 0026:0067: Invalid segment type 0!
by , 9 years ago
| Attachment: | glitch.png added |
|---|
comment:8 by , 9 years ago
I was/am using the latest daily build. My VERSION file for the DOS version reads 1.001.000
Note that in order to best see the bug you need to: - save while a location box is visible (e.g. GLASTONBURY THOR or WINCHESTER) - exit the map - load the previously save game
After doing this, I get what can be seen in the attached pic. Or the box is all black after loading from the launcher.
I'm also getting that kind of warnings when doing this, not sure if they are related: WARNING: Attempt to free Hunk from address 0026:0002: Invalid segment type 0! WARNING: Attempt to free Hunk from address 0026:0003: Invalid segment type 0! WARNING: Failed to locate base object for object at 0029:0E52; skipping!
comment:10 by , 9 years ago
| Owner: | set to |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
comment:11 by , 9 years ago
finally solved by commit 179ef7adb2c7dd0eb790a58748ad374ce92b898d
It seems Sierra's SCI saved script windows too, but it didn't use those for kernel functions after restoring the game. We now also don't put those windows into the official windowlist, which is used by kernel functions.
Added [1]