Project

General

Profile

Emulator Issues #11761

Arc Rise Fantasia crashes after the first tutorial battle

Added by mrstackz about 1 year ago. Updated about 1 year ago.

Status:
New
Priority:
Normal
Assignee:
-
% Done:

0%

Operating system:
N/A
Issue type:
Bug
Milestone:
Regression:
No
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
Fixed in:

Description

Game Name?

Arc Rise Fantasia

Game ID? (right click the game in the game list, Properties, Info tab)

RPJE7U

MD5 Hash? (right click the game in the game list, Properties, Verify tab, Verify Integrity button)

d70eab544ac48ccd22a36457a4fa12d6
-- Note: I can't get the MD5 to match GameTDB no matter what I do. Other games that work perfectly don't match MD5, either. "Verify" returns no errors or problems though.

What's the problem? Describe what went wrong.

For this specific issue.

In recent versions of Dolphin, the game completely locks up and throws up an IntCPU dialog that cannot be clicked or bypassed, even though it can be moved. Main Dolphin window is non-responsive. Task Manager to kill Dolphin is the only option.

In older 5.0 builds, the game completely locks up and throws a generic Abort/Retry/Ignore exception dialog. It does let you click the buttons, but Abort is the only one that makes a difference. You have to click it multiple times. Main Dolphin window is non-responsive. eventually Dolphin will force close.

What steps will reproduce the problem?

  1. Begin a new game
  2. After meeting girl walk to tutorial battle and complete it
  3. Crash happens immediately after the last strike that should end the battle

Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.

As of version 5.0.10472, yes.

Is the issue present in the latest stable version?

Unable to test because in 5.0 stable, "Wiimote disconnected by emulated software" issue (which ONLY happens in stable and builds under 6000) prevents control.

If the issue isn't present in the latest stable version, which is the first broken version? (You can find the first broken version by bisecting. Windows users can use the tool https://forums.dolphin-emu.org/Thread-green-notice-development-thread-unofficial-dolphin-bisection-tool-for-finding-broken-builds and anyone who is building Dolphin on their own can use git bisect.)

Unknown

If your issue is a graphical issue, please attach screenshots and record a three frame fifolog of the issue if possible. Screenshots showing what it is supposed to look like from either console or older builds of Dolphin will help too. For more information on how to use the fifoplayer, please check here: https://wiki.dolphin-emu.org/index.php?title=FifoPlayer

N/A

What are your PC specifications? (CPU, GPU, Operating System, more)

Intel i7 9700 CPU
nVidia 2080 6GB GPU
32GB Corsair 2133 RAM
Windows 10

Is there anything else that can help developers narrow down the issue? (e.g. logs, screenshots,
configuration files, savefiles, savestates)

For what it's worth, the same game file works FLAWLESSLY on the latest Ishiiruka-Dolphin stable. So the game file is fine even though the MD5 doesn't match, but for some reason Dolphin is boming at this point. After the point of crash, it's just an item and another talking cutscene, no rendered cutscenes or anything. This seems to imply that it must have worked perfectly in Dolphin at some point around when Ishiiruka-Dolphin was branched off, and the main Dolphin introduced code that broke it...?

So if we know what Dolphin build was in play when Ishiiruka-Dolphin first became a thing, it should be easy to track forward and isolate the culprit. Unfortunately, going by forum dates, that puts it somewhere between 3.5 and 5...which is a LOT of ground to cover.

RPJE7U-1.png (1.76 MB) RPJE7U-1.png JMC4789, 06/10/2019 09:04 PM
7464

History

#1 Updated by JosJuice about 1 year ago

d70eab544ac48ccd22a36457a4fa12d6 is actually the correct MD5, as listed on GameTDB and Redump.

So if we know what Dolphin build was in play when Ishiiruka-Dolphin first became a thing, it should be easy to track forward and isolate the culprit. Unfortunately, going by forum dates, that puts it somewhere between 3.5 and 5...which is a LOT of ground to cover.

It's not that simple. Ishiiruka has been gradually merging in changes from upstream Dolphin over the years. Besides, that would only let you know that it worked at a certain point in the past, not when it broke.

You mentioned that you're getting the "Wiimote disconnected by emulated software" issue in older builds. Does the first build that does not have that issue have the issue that this issue report is about?

#2 Updated by JMC4789 about 1 year ago

Ishiiruka is an ancient build of Dolphin at this point. This game does have an issue from a while ago, but I don't remember exactly what caused it.

Can you attempt to bisect? Ishiiruka is probably 6 months out of date, so, a dev build from six months ago should work. And then you should be able to bisect and figure out where it got broken.

#3 Updated by JMC4789 about 1 year ago

7464

Unable to reproduce. Please bisect.

#4 Updated by JMC4789 about 1 year ago

Also note that this game disconnects the Wii Remote when a GameCube Controller is plugged in. In newer builds, hitting a button on the Wii remote reconnects it, where as in older builds you have to hit ALT F5.

#5 Updated by mrstackz about 1 year ago

JosJuice wrote:

d70eab544ac48ccd22a36457a4fa12d6 is actually the correct MD5, as listed on GameTDB and Redump.

So if we know what Dolphin build was in play when Ishiiruka-Dolphin first became a thing, it should be easy to track forward and isolate the culprit. Unfortunately, going by forum dates, that puts it somewhere between 3.5 and 5...which is a LOT of ground to cover.

It's not that simple. Ishiiruka has been gradually merging in changes from upstream Dolphin over the years. Besides, that would only let you know that it worked at a certain point in the past, not when it broke.

You mentioned that you're getting the "Wiimote disconnected by emulated software" issue in older builds. Does the first build that does not have that issue have the issue that this issue report is about?

Same problem, yes.

#6 Updated by mrstackz about 1 year ago

JMC4789 wrote:

Also note that this game disconnects the Wii Remote when a GameCube Controller is plugged in. In newer builds, hitting a button on the Wii remote reconnects it, where as in older builds you have to hit ALT F5.

In my case I'm emulating to an Xbox One controller, and that's all that's connected.

In the New Game menu (assuming I get that far), when it asks you what you're using. If I map the Classic Controller, that's all I can choose. If I have a GameCube controller mapped, the only way I can select it is with X. But in the 5.0 stable, I don't even get that far regardless of whether there's a GameCube controller mapping or not. This is at the very startup "make sure you use your wrist strap" screen where the Wiimote disconnect message occurs and you can't move past it.

#7 Updated by JMC4789 about 1 year ago

I just loaded up Dolphin 5.0 and went past it? I don't know what issue you're having. The game disconnects the Wii Remote itself when it thinks a GameCube controller is plugged in.

#8 Updated by mrstackz about 1 year ago

JMC4789 wrote:

Ishiiruka is an ancient build of Dolphin at this point. This game does have an issue from a while ago, but I don't remember exactly what caused it.

Can you attempt to bisect? Ishiiruka is probably 6 months out of date, so, a dev build from six months ago should work. And then you should be able to bisect and figure out where it got broken.

I'll give it a shot and report back.

Sad thing about this one, because you have to go through tutorial, it's a VERY slow going process to test every build. That's why I figured it might not be worth trying to even fix because of the time investment just to find it. And if you can't replicate, it may just be a moot point.

#9 Updated by JosJuice about 1 year ago

Just to make the Wiimote issue clearer, what happens when you press Alt+F5? Does it just show the same message again?

#10 Updated by JMC4789 about 1 year ago

Anyway the Wii Remote issue isn't important as it doesn't happen in the latest development builds.

Do you have any extra settings on?

#11 Updated by mrstackz about 1 year ago

JosJuice wrote:

Just to make the Wiimote issue clearer, what happens when you press Alt+F5? Does it just show the same message again?

So an update on this and the original issue.

I created a working save on Ishiiruka-Dolphin, exported and then imported into Dolphin to try and test whether it would keep working after the crash point. That worked, so then I booted 5.0 stable up and started a new game - no more Wiimote disconnects or issues. I can no longer replicate the crash.

So something wasn't right somewhere that I overwrote with...something. To do something. And then it worked.

(I work with software for a living) this is the reason I don't like software development. Random weird 'things'.

Anyway, we can probably close as unable to replicate, now that even I can't.

#12 Updated by JMC4789 about 1 year ago

I doubt it's random. Probably a configuration thing at the very worst.

Anyway, please bisect and see if you can find whatever build changed behavior for you. I can't reproduce the issue, so I can't really help much. I did a lot of testing with this game in the past, so, if we do find out what's causing this, hopefully we'll have a jump start to narrowing down why and fixing it.

#13 Updated by mrstackz about 1 year ago

JMC4789 wrote:

I doubt it's random. Probably a configuration thing at the very worst.

Anyway, please bisect and see if you can find whatever build changed behavior for you. I can't reproduce the issue, so I can't really help much. I did a lot of testing with this game in the past, so, if we do find out what's causing this, hopefully we'll have a jump start to narrowing down why and fixing it.

Likely won't be until tomorrow or possibly Wednesday. As I said there's a LOT of builds and that beginning set of cutscenes and the tutorial just slows things down.

Upnote (maybe), I was able to get it to crash again on Stable and even on Ishiiruka immediately after the following two actions:

  • loaded HD texture pack
  • switched controllers

It only did it that one time though, but it was again right after a battle's final blow (a bird in front of the chest that's after the first rock skip). After that, both have loaded and have been working. So that might be back to the whole intermittent crash deal with this game I read about on the wiki.

If I didn't know any better, I'd swear it was an issue with one of the assets it needs to load not loading correctly.

Along with the bisect if I can get it to crash again I'll try to also capture a log at that point.

#14 Updated by JMC4789 about 1 year ago

I'm just playing the base game with no enhancements on single core to reduce any non-deterministic variables.

#15 Updated by mrstackz about 1 year ago

JMC4789 wrote:

I'm just playing the base game with no enhancements on single core to reduce any non-deterministic variables.

So I don't know where my reply went that I thought I left late yesterday, oh well. I had a BSOD so maybe it was lost in draft.

I ran into no dissimilar build behavior, but I was able to isolate the issues down to the cheat function. Specifically Gecko, since that's all I have in there at the moment. If the cheat function is not enabled, everything works perfectly fine. I usually leave the cheat menu enabled across games, so it's not something I think of.

  1. Enable the cheat menu, game works fine if no cheats are enabled
  2. Enable any cheat, doesn't matter which, game will crash after battle

Now what's strange is, even if I disable the cheats and restart the game completely, it will still crash. The only way to get it to stop is to completely disable the cheat option. This is why I was getting inconsistent test results - I wasn't disabling the cheat option and if I forgot to do the portable file, it was still remembering that setting vs. if it's a full clean install.

So it's fine assuming you don't enable codes for the game, and it's fine if you don't have the cheat menu enabled at all, but if I enable the cheat menu, enable at least one, crash happens until and unless I completely disable the cheat menu, regardless of disabling the cheats afterwards. I can make this happen in every build, and it doesn't seem to matter which code(s) are or are not enabled.

#16 Updated by JMC4789 about 1 year ago

  • Status changed from Questionable to New

Can you bisect when this behavior started? This sounds like a serious, serious bug, especially if it's not happening in older builds.

#17 Updated by mrstackz about 1 year ago

JMC4789 wrote:

Can you bisect when this behavior started? This sounds like a serious, serious bug, especially if it's not happening in older builds.

No, this is happening in every build I've tested, and at this point I've gone through the majority of 5.0 development builds and the 5.0 stable build. That's what I meant by "no dissimilar build behavior". I can make them all crash with the steps.

I'm an old guy. I don't have significant time to invest into the bisect method. I assumed going in, it would just ask me for the crash point or steps, then just scan the code for any changes that would have had anything to do with that crash point and report a smaller list to test. But it just launches each one for manual unit testing.

That wouldn't be an issue if a new build of Dolphin weren't released literally every day, sometimes multiple times a day. It's too much for one person with limited time. And it feels pointless because 5.0 stable will crash too, but bisect can't be limited down to just stable builds.

I'd like to just use process of elimination to see if we can get there faster and with less human effort or at the very least, get the total list down. There are just too many builds and it takes about 2 minutes to get back to the trigger event per build because of the intro logos you can't skip, the loading of the save, walking to get into a battle, the slowness of the battle sequence, etc. And since save states are hard coded incompatible between builds you can't just freeze a state right at the trigger point which would save HOURS of time.

We know that
* Dolphin works fine if cheat menu is not enabled. That means the game is fine, and the emulator in general is fine handling it.
* Dolphin works fine if the cheat menu is enabled with no cheats. That means the code that handles the cheat menu is fine.
* Dolphin works fine on other games where cheats are enabled. That means the issue has to be specific to Arc Rise Fantasia and how codes are handled and/or being applied.
* We knew there was an issue with the 60FPS code and according to the wiki, it's still a problem. The workaround involved speeding up the disc transfer rate and 125 overclock of the CPU.
* According to the issue logged about that, the root cause was how codes are done in Dolphin: they apply at time intervals rather than the traditional (and I may get this wrong) VI hook method.

So, is it possible Arc Rise Fantasia is doing something at the exact moment a battle ends that throws off this last bullet? That's what I'd look at first. But I don't have the tools to trace that interaction; what Dolphin is specifically writing or reading at that specific point that might explain the behavior, which might highlight the problem.

Or can we think of anything in the code that would cause it to throw that specific error and look at that point? Or anything that would cause a dialog that can't be interacted with?

I just think we (or I) don't know enough about what's happening at the moment you land that last hit to isolate builds more efficiently, and because Dolphin completely freezes and won't let me interact with the dialog box at all, I can't stack trace it to see what it's trying to call.

#18 Updated by JosJuice about 1 year ago

If it crashes in both 5.0 stable and the latest development build, there's no reason to bisect between those builds. You could try some older stable version if you want to, like 4.0.2, but if there isn't an old build where it doesn't crash there isn't much point in testing different builds.

#19 Updated by mrstackz about 1 year ago

JosJuice wrote:

If it crashes in both 5.0 stable and the latest development build, there's no reason to bisect between those builds. You could try some older stable version if you want to, like 4.0.2, but if there isn't an old build where it doesn't crash there isn't much point in testing different builds.

I did try the very latest 4.0 development build the other day and it still crashed, so again, I'm thinking it's something with how the game's interacting with codes that it doesn't like.

I would say it's probably best to just close this issue or attach it to the other about the changing of code behavior from a timed interval to the VI-whatever, then I'm happy to retest to see if it still happens. But right now it's needle in a haystack with not enough data to work off of about why the game would fail at that exact point.

Thanks to everyone though.

Also available in: Atom PDF