Opened 8 years ago

Last modified 6 months ago

#10431 new defect

SCI: Shivers: Access Violation rendering picture under RetroPie

Reported by: ParadoxGBB Owned by: dafioram
Priority: normal Component: Engine: SCI
Version: Keywords: sci32
Cc: Game: Shivers 1

Description

Hello,

First off, thanks so much for the great work here, it's amazing the number of titles you guys are able to support.

I've been trying to get as many as I can running on my Raspberry Pi 3 under RetroPie, and I've noticed the following parsing violation on the opening picture after the video intro of Shivers 1:

(this is from memory, apologies)

Pic1012(abs: 2 + 1 > 0)!

I've tried this on both published versions for retroPie, SDL1 and SDL2, and today refreshed the source to make sure it's still an issue. Now it gives a different error:

ERROR: Compression type not supported - P: 1012 C: 0!

This for some reason does not reproduce on my windows desktop.

I saw a similar bug so using that as guidance I extracted the resource via sv.exe (on my windows desktop) and included it here. The resource appears to be the opening picture of the locked gate at the museum.

Attachments (1)

1012.p56 (178.7 KB ) - added by ParadoxGBB 8 years ago.

Download all attachments as: .zip

Change History (8)

by ParadoxGBB, 8 years ago

Attachment: 1012.p56 added

comment:1 by csnover, 8 years ago

Component: --Unset--Engine: SCI
Keywords: sci32 added
Resolution: worksforme
Status: newpending
Summary: Shivers: Access Violation rendering picture under RetroPieSCI: Shivers: Access Violation rendering picture under RetroPie

Thanks for your report! There is no problem with the picture resource you have uploaded, it matches the original resource data. I also cannot reproduce any problem just by starting a new game on macOS. (I do not have any RPi.)

Since you haven’t mentioned which version of ScummVM you are trying to use or how you have built it or the exact steps to reproduce the problem, it is difficult to take any action on this ticket other than to close it, so please provide that information.

The symptoms you have described sound to me first like a device, OS, or compiler problem, rather than a bug in ScummVM, since from what you have said so far the behaviour only changes between compilations, and it is not reproduced elsewhere.

Please try the official Raspberry Pi 2.0 build and report exactly the error if it occurs with that build. If you have other hardware, please test on the other hardware. If you can provide all the information requested when reporting a bug we may be able to take additional action. Thanks!

comment:2 by ParadoxGBB, 8 years ago

Resolution: worksforme
Status: pendingnew

Hello,

Here's some additional information that I hope can make this ticket actionable.

1) The automation set up by retroPie allows you to install from source or from binary with the same ease. I moved to installing source after hitting this problem, partially because I saw a resolved issue around parsing bitmaps and I thought it might be worth a shot. I reinstalled the released binary (2.0.1pre) and now the first error I saw is reported again:

ERROR: Access violation reading Pic.1012: 2 + 1 > 0 (abs: 2 + 1 > 0)!

2) The information you request:

Version: 2.0.1pre (With SDL1 support)
Language: English
Version of Game: CD
OS: RetroPie 3.4.7 (This is based on top of Raspbian Jessie)
ScummVM settings: all default, no component dropdown under engine that I can see.
Repro: after intro video, an access violation will automatically trip up the debugger.

I can provide debugger output if you wish me to, or if there's logs to extract I can provide them too.

comment:3 by dafioram, 8 years ago

What is your version is your libpng?
What happens if you build the source for SDL2 scummvm?

comment:4 by dafioram, 8 years ago

Owner: set to dafioram
Resolution: outdated
Status: newclosed

Now that a new Retropie version is out and supports stretch and uses scummvm 2.0 with sdl2 there shouldn't be any issues. Please reopen if the new version is buggy.

comment:5 by ParadoxGBB, 6 months ago

Resolution: outdated
Status: closednew

Hello, I'm reopening this bug:

1) This has never worked for me for multiple RPiOS versions now (jesse, buster, bullseye, bookworm, and now trixie), with each of its different compiler and scummvm versions. I am now running the latest
2) ScummVM on windows is now showing the same error / crash.
3) Running via DosBox under windows seems to work, so I don't think the resource is corrupt. I have also attempted to acquire the picture the crash is complaining about from multiple sources and always get the same error.

So I can conclude that it appears to be a ScummVM bug, and it appears that it is not platform specific as the original resolution posited. I'd greatly appreciate someone to try to reproduce. Thanks!

comment:6 by sluicebox, 6 months ago

Hello! Thank you for following up on this. My favorite thing about our bug tracker is that we let anyone change a ticket's status. This is why! I also resurrect ancient unfixed SCI tickets =)

We are very close to a new release. I don't know if we'll be able to figure this out in time, but it would be nice.

I might be the only one who can address this in time, if there is time, but I am unusually busy with real life. If you can post a lot of details, that might give me the information I need to reproduce this within the limited time I have to spend.

Can you provide a directory listing with precise file sizes of your shivers files, including subdirectories? If you can also provide md5sums for them (or a similar hash) that would be a huge help. It's possible that you have a version that's slightly different; SCI versions are anarchy.

Any other version information you can find (about box, text files, original media) would help too.

Shivers is one of the SCI games I am least familiar with, although I did once play through it successfully two years ago. Please provide instructions for me to reproduce the crash from scratch like I'm a child. Assume I know nothing! (I don't!)

comment:7 by sluicebox, 6 months ago

Removing a comment I just wrote about memory corruption; I now see that SCI32 picture code modifies raw resource data in-place, causing our diskdump debugger command to not produce accurate dumps. I still need that version info!

Note: See TracTickets for help on using tickets.