Chrono Trigger crash

[Tharn]

Chrono Trigger (U) (!) on Manjaro 64bit with snes9x-gtk. SDL and ALSA both show the same behaviour (even OSS which produces no sound with my config). It works fine on Windows.

Reproducible, for me at least, by starting a game, going into the Inn and interacting with the sealed chest next to the bed. Instead of the 'mysterious' jingle playing, snes9x-gtk crashes to desktop. The game audio is also a bit glitchy no matter how I change audio settings. Audio issue?

[groverj3]

I also can confirm this on Linux Mint 17. No options seem to fix the crash.

Game crashes when certain musical cues occur. One being that box, another when trying to fight Gato at the Millennial Fair.

[jcdenton2k]

It may be relevant if you could post the SHA-1 hashes of the ROM files that you are attempting to use. There are two known revisions of Chrono Trigger, v1.0 and v1.1 so that information may help in troubleshooting. I haven't used the Linux version of SNES9X but I hope they get around to fixing this. I can confirm the Windows version works fine. Since it may be an audio issue, head to the SNES9X settings and fiddle around with the audio settings to see if anything in particular may NOT cause the crash.

My CT ROM's hashes (perfect dump confirmed): CRC-32: 2D206BF7 MD5: A2BC447961E52FD2227BAED164F729DC SHA-1: DE5822F4F2F7A55ACB8926D4C0EAA63D5D989312

[groverj3]

What's the best way to get the MD5 or SHA-1 hashes from an SNES rom? For the CRC-32 that SNES9x can display I have 2D206BF7, the same as yours. It is version 1.0, though it was also confirmed as a good rom. Perhaps I'll try 1.1. Audio options I've tried don't seem to have an effect.

The crash also does not happen with Higan/bsnes.

[groverj3]

Never mind, got that information from Retroarch. The rom is the same as yours and supposedly good.

Also, the crash does not happen with the Snes9x core in Retroarch on Linux, either. Not sure how much they've edited the code though. For now I suppose I'll play through higan, which is less than ideal simply because I can't scale the game to my 1080p res TV in a logical way.

I'm using 1.53, the last official linux release. Perhaps something has been fixed since the last official release, and I could try building from source if I'm feeling up to it.

[jcdenton2k]

I believe that RetroArch uses a fork called SNES9X-Next based on v1.52; the main thing is they backport the security fixes and patches from the later versions without the extra 'features' added in later. https://github.com/libretro/snes9x-next

Best way I find to check hashes is a freeware portable program called MultiHasher: http://www.abelhadigital.com/multihasher

I use that because no install required and it works fine for me.

I wouldn't recommend higan at all; if you must use it then I'd say use bsnes-classic or another bsnes fork instead. I believe there may be a linux-based version on it with a Qt GUI that makes sense.

Higan is really awesome in accuracy but suffers significantly in performance because of it. If people could take it apart to figure out ways to speed things up without sacrificing accuracy (and of course use the non-folder version of the GUI) then we'd have the hands down best SNES emulator of all time.

We'll have to see how things go. Emulation is as much politics as it is progress (or lack thereof).

[groverj3]

Yeah, the rom is not the issue as far as I can tell. Thanks for the links though, I'm sure that'll come in handy.

Hopefully someone notices this issue. I'm kind of amazed that this problem exists since CT is one of the more popular SNES RPGs out there and apparently it worked fine on past releases. Perhaps it's linux-specific for 1.53 and that's why nobody else is making mention of it due to the limited userbase.

On the plus side though, if it ever does get fixed in Snes9x it's easy enough to transfer a save from higan. All you need to do is change the filename of the save to the same as your rom.srm and stick it with your Snes9x save files, and it opens just fine.

[jcdenton2k]

@groverj3:

Well SNES9X has already been forked multiple times but it seems SNES9X-Next is the primary development branch due to the ease of use and cross-platform capabilities of RetroArch.

I've spoken with several folk in the emulation development community and there's been a few reasons that new development has stalled.

The main reason is that the older emulation authors have families/jobs/lives now and can't devote as much time as they used to.

The secondary reason is that politics have come into play regarding certain romhackers demanding specific non-hardware features for compatability with their specific roms because reasons and the clash between accuracy and compatability/speed is always going on.

The fallout from the bsnes split is still being felt and a lot of authors just said 'screw it' and work on other more-interesting systems like the Sega Saturn or PS1/PS2.

New development blood is either not capable/intelligent enough to dig into coding or just not interested in it.

There is one issue that was implied but not mentioned: the ripoffs. The assholes on Google Play and iTunes that directly rip off the emulators and package them in an APK and SELL them on the store (with thousands of payments/downloads and profit) with little to no effort while the original authors could barely scrape by with meager donations.

And that is ultimately the straw that pissed off a lot of people. The entire mobile market store ecosystem in general has zero quality-control and zero oversight. Everything from obvious Nintendo-game clones to emulator ripoffs are being done without any consequence.

To sum it all up, I wouldn't hold your breath for anyone on the SNES9X team to fix this issue. If it is already fixed in SNES9X-Next on RetroArch for Linux then just use that build.

[OV2]

I can't reproduce this when building from git. Ubuntu 16.04, Pulseaudio/Alsa/OSS all work fine with that ROM and opening the chest / fighting gato.

[groverj3]

@jcdenton2k

I'm well aware that "expecting" a fix isn't going to make it happen since the devs do this in their own free time simply out of interest. I'll use whatever emulator works, I'd just prefer not to have to switch for some games, but since they all share save formats it's no big deal I suppose.

@OV2

So, as I suspected it's probably unique to the last official release on Linux. I'll try building from source when I get a chance. Thanks for looking into it.

[bearoso]

The 1.53 release is old. The Linux ecosystem has changed a lot since then. This is probably less an issue with snes9x, and more of a binary compatibility problem.

[bearoso]

Could reproduce this with Snes9x 1.53 and newer system libraries. The assertion in a corner case in blargg's smp that throws now when it didn't before. The snes9x-next version had refactored this so it won't occur there. You could fix it by disabling the assertion or copying snes9x-next's version of the function call into place. But if you want an older hacky core, just use snes9x-next.

git works because it's byuu's smp.

[groverj3]

Building from git worked for me as well.