Dolphin, the GameCube and Wii emulator - Forums

Full Version: Xenoblade emulator crash
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I havent used Dolphin in a very long time, but I did use it back in the day on this system to play Xenoblade and never had any stability issues. There was only D3D9 back then iirc.
Now it runs alot better with D3D11, although menuing is much slower, used to load instantly and now it takes 3 seconds in every menu, but my main issue is that the emulator randomly crashes - picture freezes and the music gets stuck in a loop. Dolphin main window does respond to "stop the emulation" button, but fails to actually stop the emulation, have to do it a second time after which it terminates the whole program.
Now here is the part where it gets weird: these crashes seem to only occur when using HD texture pack - I'm not 100% certain on this, as the crashes are random and occur about every 4 hours on average and I simply have not played enough hours without the HD textures as it is quite unpleasant. They also only happen during combat - a taxing activity for hardware.
I'm having a hard time understanding how exactly can HD texture pack cause the emulation to become randomly unstable. I mean, its just a bunch of .dds texture files and since I can hardly find any mention of this issue then whatever is going on must be specific to my aged system.
My best guess is that the cpu / gpu threads get too far apart due to increased load caused by these textures on my system and the whole thing crashes? But I really have no idea what I'm talking about here as I'm basing this solely on the existance of a "sync gpu / cpu threads" setting thats supposed to prevent "random freezes", whatever that means, "freeze" is a very ambiguous word, can mean "stutter", can mean "crash", who knows. Unfortunately that setting also murders performance so its not really a viable solution for me.

I have tried alot of different settings, including running in opengl, but nothing makes this problem go away. I even tried loading only about 1/4th of the HD textures, thinking that its some sort of memory issue, but it still crashed eventually.
These crashes happen both on the latest dev build and Ishiiruka, but they likely happen on much older versions also. I cant test this on the stable builds unfortunately as those are so old that they dont even load the texture pack properly (something to do with newer texture format that only recently became supported.).
At this point I would just like to know what exactly causes this issue.
Do you have preload textures enabled under advanced graphics settings?
(11-18-2017, 04:42 AM)ExtremeDude2 Wrote: [ -> ]Do you have preload textures enabled under advanced graphics settings?

No, that texture pack is huge - it wouldnt fit into my limited memory. My understanding is: that setting doesnt affect stability, it only affects load times. I dont have any performance issues with it turned off.

But I guess I could try preloading only some UI elements from the texture pack and see if that crashes.

Edit: So I loaded about 150~ MB of textures into RAM but it crashed fairly quickly in an intense battle. These crashes seem to happen more frequently the more enemies are involved in a battle for some reason. I'm gonna play without the texture pack for awhile to see if its actually whats causing this, seems very odd to me. One thing I forgot to mention is that I'm also using a fairly untested gecko code that not many people have ever used, it was writted by a guy who didnt own Xenoblade so he never tested it. This code does work as it should, but maybe somehow there is a weird cross-interaction with the texture pack? I dont think it has anything to do with these crashes though - I think I had those before I started using that gecko code.
Well, it took me all day but I did manage to crash it without any custom textures loaded; it seems the texture pack has nothing to do with these crashes after all. My next suspect is the gecko code - I'm gonna try to get a crash with cheat mode disabled. If it does crash I guess it means that the new dolphin versions are inherently unstable on my system for some reason. This whole thing made me suspect some sort of subtle hardware failure going on, so I downloaded prime95 and ran a blend-in torture test for 20 minutes, but it went without any errors.
I have played a significant amount of hours without any crashes so it seems either the gecko code is bad, or it just doesnt work with Dolphin, or maybe just checking the "enable cheats" checkbox makes the whole thing unstable. Here is the code itself:

$EXP/AP/SP Multiplier v2 [dcx2]
C20A2C10 00000012
48000011 3F800000
3F800000 3F800000
C9828198 D981FFF8
60000000 00000000
6C978000 92E1FFFC
C961FFF8 ED6B6028
6CB68000 92C1FFFC
C941FFF8 ED4A6028
6CDA8000 9341FFFC
C921FFF8 ED296028
7D8802A6 C18C0000
ED6B0332 C18C0004
ED4A0332 C18C0008
ED290332 FD60581E
D961FFF8 82E1FFFC
FD40501E D941FFF8
82C1FFFC FD20481E
D921FFF8 8341FFFC

# The three 3F800000's at the beginning are the EXP, AP, and SP multipliers in single-precision floating-point format.

This code multiplies exp/ap/sp and rounds down to a whole number. I've played with 0.2 multiplier on all of those and it works great, except for the random emulation crashes  Undecided
I think this code is supposed to be compatible with both PAL and NTSC-U, I've used it with NTSC-U.
I dont know of any other code out there that does all this stuff so it would be great if someone could fix whatever is wrong with this one  Heart
I found out there is already a bug report about this issue: https://bugs.dolphin-emu.org/issues/10456 and its 3 months old.
Its probably a good idea to put "MAY CAUSE RANDOM CRASHES" in big red letters over "enable cheats" until this is sorted, it took me DAYS to figure out that the gecko code was responsible, it was pretty much the last thing I though of.
Hope this gets fixed soon.