Dolphin, the GameCube and Wii emulator - Forums

Full Version: Path of Radiance/Radiant Dawn slow on latest Dolphin, fast on old version
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2

ctbk

Hello, I'm having a weird problem with Fire Emblem Path of Radiance and its Wii sequel (FE: Radiant Dawn).

In both games, if I run the game with the latest Dolphin versions (5.0-1949 & 5.0-1954) I'm stuck at ~40% speed at best: everything is slowed down, audio is glitchy, and so on: unplayable. Other games on the other hand run at 100% on my system without any particular problem.

I tried unchecking and checking every setting, without any noticeable difference.

I had the same problem with a previous Dolphin version before updating it (it was a 4 point something, sorry I don't remember).

Then I saw that in the RD page, a user (Tron) with a setup similar to mine (macbook, i5, integrated Intel card) reported that Radiant Dawn was working reliably at 100% speed for him. Just out of curiosity I looked at the version he used to test it (4.0-4762), downloaded it, tried it and... voilà! Both Path of Radiance and Radiant Dawn work fine on this older version.

Since I saw other discussions about other, less severe issues about this game with other users reporting that was working fine for them under Dolphin 5.0, I guess it could be an issue due to a particular combination of factors (Mac + something used by Intelligent Systems in their games?)

Using the older version I've no problems at running both games now, but I'll be glad if I can help to pinpoint the bug in some way.

My setup:
Macbook Air Intel i7 1.7Ghz
8Gb Ram
Intel HD Graphics 5000 1536MB
OS X El Capitan 10.11.6
We probably made some change between now and then that hurt weak configurations like your MacBook Air.

While it's probably unlikely that we'll revert that as we generally care about accuracy over speed on weak systems on OSes that have effectively abandoned OpenGL drivers, if you bisect the version and find which version caused the issue for you, that *may* entice somebody to take a look, but no promises.

If you don't know how to bisect, you take the last known working version, the latest version, and test the version in the middle of that range. Then use the result as either your working or not working version, and do the process again.

ctbk

Hi there, since the slowdown happens right from the "WARNING - Health and Safety" screen, I suspected it wasn't a graphic/power issue (as I said, other games arguably more demanding than Fire Emblem run just fine) but a timing issue instead, triggered by something unique to these two games and my setup.

After a little experimentation, I've identified the version from which the slowness appears: 4.0-8586 which actually incorporates a pull request that  changes something about syncing and timing. 


As I said, even if this issue won't be fixed it won't be a big deal (I'll just play those two games with the 4.0-8584 version), but I don't know if this could be a symptom of something else. Anyway, I hope this can be useful in some way.

Keep up the good work, Dolphin is an amazing project!
  S
hrm.

Does this happen on other games by chance?
Note: Dolphin doesn't support idle skipping in those games. The health and safety screen is not much less demanding than any other part.

Honestly, at 1.7 GHz, slowdown is about what I'd expect with those games. Timing issues caused them to run weirdly before...

ctbk

(01-22-2017, 06:53 PM)Helios Wrote: [ -> ]hrm.

Does this happen on other games by chance?

I've tried: 


New Super Mario Bros: OK with both versions
Xenoblade Chronicles: OK with both versions
Tales of Symphonia (GCN): OK with both versions
Super Mario Galaxy: 80-85% with old version, crashes with new version
Super Mario Galaxy2: 70-75% with old version, crashes with new version
The Last Story: 60-70% with both versions
Sonic Colors: OK with both versions,  a little better (100% stable) with the old one.

Of course I do not expect to be able to run all games at 100% with my very non-gaming laptop, it's just that the extreme slowdown in both Fire Emblems (even the menu and the anime scenes) seemed suspicious to me and not related to the power needed by those games... and the dramatic difference between an old version (100%) and the new one (unplayable) was even more strange.

sageamagoo

I'm running a newer setup on discrete graphics, but seeing the exact same issue, and can confirm that 4.0-8584 works flawlessly while 4.0-8586 and later slows Radiant Dawn right down to 70% speed no matter my settings (very frustrating when 1x and 4x resolution run exactly the same!)

Specs:
Macbook Pro with OSX 10.12.6
Intel i7 7820HQ (2.9GHz)
AMD Radeon Pro 560
16GB RAM

Any chance someone could look into this?

Some more info that may help:

- Slowdown occurs everywhere, starting right from the wii warnings at the beginning
- CPU override has little to no effect on max fps
- This is present in the latest development build
We've posted this before, but, it was an increase in accuracy to how we handled output. There's nothing to fix. Latest dev build has idle skipping support.

sageamagoo

(08-26-2017, 12:32 AM)JMC47 Wrote: [ -> ]We've posted this before, but, it was an increase in accuracy to how we handled output.  There's nothing to fix.  Latest dev build has idle skipping support.

But why is it that the fps never gets above a certain threshold, even in the latest dev build? Adjusting CPU Override settings to extreme values usually makes VPS cap out at 100%, but it just won't budge above 74%/75% for this game. It just seems so weird to me that my system can handle 4x internal resolution just fine for this game with no change in fps, so I'm having trouble understanding where the bottleneck lies. Obviously not everyone is having the same issue I am, which makes me think it might be system-specific in some way. Surely there must be a solution...
It's unrelated to GPU emulation, that's why. We changed how the VI was handled which would affect CPU emulation. Internal resolution won't matter for that. If you're interested in debugging it further and think it's a bug on our end, you'll need to setup compiling and try to figure out what in that change affected it. Then, maybe someone in the project can see if there's a more optimized way to do it.
Pages: 1 2