Emulator Issues #13388


[Super Paper Mario] 7-2 darkness effects now cause the game to run horribly

Added by SacredGhostSPM about 1 month ago. Updated 28 days ago.

% Done:


Operating system:
Issue type:
Relates to usability:
Relates to performance:
Relates to maintainability:
Regression start:
Fixed in:


Game Name?

Super Paper Mario

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

R8PE01, R8PJ01, R8PP01, R8PK01

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


What's the problem? Describe what went wrong.

For some reason, sometime during these last 2 weeks, there was something that changed the way Super Paper Mario handles the darkness effect when you light up the torches, or talk to one of the door guys.
I don't know why this is a thing, but it chugs very hard and your FPS is taken down to 20fps, but still at 100% VPS, however, even after the effect comes back, it LOCKS your FPS at 29.97 until you load a different room. This is an obvious problem because this is not normal behaviour and it affects speedruns if this still persists.

This was not something that happened 2 weeks ago with the exact same version of dolphin, with the exact same settings [[]]
This unfortunately means that it is most likely an issue not related to dolphin but more with something that windows has updated in the last 2 weeks or something along those lines. However, I don't know where else to turn for help because nothing I do fixes this issue. I've tried many different dolphins versions, on portable mode, even going back to 5.0 stable where the same thing happens (All though to different degrees of chugging due to the updates since then.)

This is not a bounding box issue because the same thing still happens when disabled.

What steps will reproduce the problem?

  • Launch any version of Super Paper Mario
  • Go to 7-2
  • Use Bowser on the torches or Talk to the door guy (Any instance where the darkness affect goes away)

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

5.0-20314, 5.0-20211, 5.0-19953, 5.0 Stable [LUA Core]

Is the issue present in the latest stable version?


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

Windows 10 Home 64-bit
Intel Core i7 @ 2.60GHz
NVIDIA GeForce RTX 2070 (MSI)

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

All of the following clips / videos happened on 5.0-19953 [portable, if that matters] without ANYTHING changed on dolphin between these events

Example 1 of this issue:
Example 2 of this issue:
Once again, 2 weeks ago where this did not happen:


image_2023-11-08_161028352.png (94 KB) image_2023-11-08_161028352.png Graphics settings if it helps SacredGhostSPM, 11/08/2023 11:10 PM
Actions #1

Updated by pokechu22 30 days ago

  • Status changed from New to Questionable

This is probably a dual core issue.

I was able to reproduce it on my machine, but only with dual core enabled; for me, however, it dropped to 29.97 FPS, and returned to 60 FPS when the blackness returned. On single core, it maintained 60 FPS the whole time (though the max percentage speed dropped when the whole room was lit, which indicates that the game still is doing extra work of some sort).

Dual core works by emulating the console's CPU on one thread on your machine and the GPU on a second thread. This is generally faster, but it is nondeterministic, meaning weird things can happen if the CPU or GPU thread takes more or less time than usual (see #7143). In particular, this means that updating graphics drivers or having more background programs running can change the behavior - which is likely why this only started happening now. (It also can be affected by Dolphin settings, such as if you increase the internal resolution a lot, then things will obviously take longer to render. But you presumably didn't change that.) Single core, however, is (at least supposed to be) completely deterministic, but it is also slower since since some work for the GPU is done on the CPU thread.

If I recall correctly, the determinism involves telling games that work has finished at about the amount of time it would take on real hardware (though Dolphin's GPU timings are nowhere near perfect), and waiting for that work to finish if your GPU hasn't already, while dual core just lets the game continue to run in that case (only telling it that the work has finished when your GPU says it's finished), though it's been a while since I looked into it. This means that if something starts taking longer, the game will see that the current frame is taking too long to render, and the game will decide to stop skipping frames (lowering the FPS, but emulation continues to run at full speed and the game is still given 60 vertical interrupts per second (VPS) so it still knows how long things should take, which is roughly why the audio still sounds fine). 29.97 FPS would be the game skipping every other frame, while 20 FPS would be the game skipping two frames out of three.

If you want to experiment with the game skipping frames deterministically, you can use single core, and then change the emulated CPU clock override under config -> advanced. Lower values mean the game has less time to do its work each frame, which will lead to it skipping frames (and generally chugging, but audio will still sound fine), while higher values will give it more time within a frame (and if set too high means that Dolphin won't have enough real-world time to emulate things, leading to VPS drops and audio stuttering). For me, increasing the emulated CPU clock override actually avoided the FPS drop with dual core when the darkness effect was removed, since the game thought it had more time and thus didn't need to drop the framerate, but that likely varies. Note that the CPU clock override setting is not accurate to real hardware so it shouldn't be used in speedruns.

I'm not entirely sure why it didn't return to 60 FPS for you when the darkness effect came back (on my machine it does). My best guess is that it's related to CPU/GPU clocking for power usage; at least laptops and phones will change the CPU and GPU clock rates to reflect what is actually needed to reduce power usage, to try and provide the minimum needed. Among other things, this can result in the max speed value being lower than the maximum speed you'd actually get if you held down the fast forward button for a while (as your device would increase its clock rates once it was fully being used). My guess is that on your machine, 30 FPS with dolphin displaying 160% as the max speed is low enough utilization that your machine decides that the current clock rate is fine, meaning that the game doesn't run fast enough that it thinks it can make 60 FPS, leading to a vicious cycle. This is just a guess though, and I have no idea if it would apply to desktop machines. (You can see the CPU clock rate in task manager; I also recommend right-clicking the graph and changing it to logical processors.)

I'm not part of the Super Paper Mario speedrunning community, but I'd recommend discussing it among yourselves whether you should require dual core to be disabled to ensure deterministic behavior or if you want to allow people with weaker machines to also be eligible for submissions (though SPM requiring bounding box already rules out some weaker machines).

Actions #2

Updated by SacredGhostSPM 28 days ago

Hey there!

Thanks for the reply. I appreciate the in-depth response and details to test on. Everything that you have said has produced the same results with most importantly enabling CPU clock override does indeed fix this issue overall.

As for speedruns, I will be testing a lot more with this since we all know that Dolphin and SPM/Bounding box has been an issue for a long time in terms of performance. I don't think the inaccuracy will be too big of a problem to the moderation team, since we do force "Emulate Disc Speed" to be forced on (I seem to be getting the exact same loads/framedata), but like I said, more testing and over all, better performance for runners that don't have access to console, more accessibility, which is our main goal

As for why this issue started happening to me now, still have no clue, but I really do appreciate your in-depth analysis, and deserve props :)


Also available in: Atom PDF