Hi!

Please read this:
http://code.google.com/p/snes9x-gtk/issues/detail?id=51
Additional information: It often happens if the background music changes.

The same thing happens in the "normal" Snes9x emulator. It is really frustrating to have to play the game from your last savestate every time this happens. A fix for this would be very nice.

Thank you.

Please report your bug here: http://snes9x.com/phpbb2/viewtopic.php?t=3703

Thanks!

_________________
Snes9x FAQs | Forum Rules
What operating system are you using? 32 or 64bit? Version of Snes9x? Is the text at the bottom of the window white when you load the game?
These suggestions are usually the solution to your issue!

But this also happens in the Win version of Snes9x

Try the most recent testbuild if you are on windows, or compile from source if you are using the gtk version.

Thanks.
But unfortunately the game freezes with the latest testbuild as well :-/

Could you provide an SRM file from a location where it happens? The link in the gtk issue tracker is unfortunately dead.

http://www.file-upload.net/download-411 ... -.zip.html

When I go to the quicksand area and back to the bug swamp I will get a freeze (try more times and push the "Speed Up" Button (plus A Button) between area changing)

Thanks

An additional info: I am using Win 7 64bit and I have tried it with the 32bit and 64bit version snes9x_testbuild_13022012.
The freeze appears sporadic. Sometimes it is necessary to change the area 10 or 15 times to get the freeze.

Thanks in advance for any help.

This should actually be fixed with byuu's SMP in the next release.

Unfortunately it's not - the new SMP is already in the testbuild I posted, and I was able to reproduce it.

Hmm. I had associated this with the SMP, but if it's still not fixed, and since 1.51 still locks up, I'm sure it's something else.

Did you reproduce this with the NTSC cart or just the PAL one? I haven't been able to get the NTSC cart to do it.

*edit* I'm seeing an SMP lock in debugging again, so it is synchronization related. Our PAL timings must be off a bit somewhere, and I imagine the PAL version was ported without changing many NTSC assumptions, so the timing is tighter and more temperamental.

I have also tried it with the NTSC rom but was not able to reproduce it.

Any news on this?

I was able to reproduce this issue both on my snes9x x64 windows 7 x64 pc and the actual PB build of snes9x. So the issue still occurs and a fix would be nice.

Does anyone know, if this error is fixed in snes9x_testbuild_29032012 ?

There has not been any progress, no.