Emulator Issues #14041
open
Very long door transition in RE3 GCN only during Movie Recording
0%
Description
Game Name?
Resident Evil 3: Nemesis (GCN) - NTSC-U [GLE] e NTSC-J
Game ID? (right click the game in the game list, Properties, Info tab)
GLEE08, GLEJ08
MD5 Hash? (right click the game in the game list, Properties, Verify tab, Verify Integrity button)
428abf23e4c06dbfcbd3cea2fa577385 - NTSC-U
245a4269337f3a290abf57a6ff156f7d - NTSC-J
What's the problem? Describe what went wrong.
When attempting to create a TAS of Resident Evil 3 (GCN) using Movie → Start Recording from boot, the game consistently hangs on a black screen immediately after the first door transition. The door animation plays normally, but the new room never loads — the screen stays black indefinitely with no audio, as expected during a door transition.
This issue is exclusively tied to Movie Recording mode. With identical emulator settings and the same ISO, playing without any recording active results in perfectly normal door transitions every time. The problem has been reproduced on both the NTSC-U and NTSC-J versions of the game, ruling out a region-specific cause.
RE3 GCN is known to use EFB reads to detect screen fade state during room transitions. It is suspected that Movie Recording mode alters the timing or behavior of the EFB pipeline in a way that causes the game's loading logic to never receive the expected signal, leaving it permanently waiting.
All standard TAS configurations have been tested without success, including: Dual Core OFF, Idle Skipping OFF, DSP LLE Recompiler audio, Skip EFB Access from CPU OFF, Store EFB Copies to Texture OFF (RAM mode), XFB Real mode, MMU OFF, CPU Clock Override disabled, no Gecko/AR codes active, and Memory Card consistently configured. Multiple Dolphin beta versions were also tested with the same result.
What steps will reproduce the problem?
Steps to reproduce:
- Movie → Start Recording (from boot, no savestates)
- All standard TAS settings: Dual Core OFF, Idle Skip OFF,
DSP LLE, Skip EFB Access from CPU OFF, MMU OFF - Play through opening area and walk through first door
Expected: Room loads normally
Actual: Black screen, game hangs indefinitely
Note: WITHOUT Movie Recording active, the door loads 100% normally
with identical settings. Issue is exclusive to Movie Recording mode.
Tested on both NTSC-U and NTSC-J ISOs.
Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.
Yes, version 2603-348
Is the issue present in the latest release? For future reference, please also write down the version number of the latest release.
Yes, version 2603a
If the issue isn't present in the latest release, 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.)
[First broken version number here (if applicable)]
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
[Attach any fifologs if possible, write a description of fifologs and screenshots here to assist people unfamiliar with the game.]
What are your PC specifications? (CPU, GPU, Operating System, more)
CPU: Intel Core i5-1135G7 @ 2.40GHz
GPU: Intel Iris Xe Graphics
System: Windows 11 Enterprise Build 25H2
Is there anything else that can help developers narrow down the issue? (e.g. logs, screenshots,
configuration files, savefiles, savestates)
[Anything else here]
Updated by JosJuice 11 days ago
RE3 GCN is known to use EFB reads to detect screen fade state during room transitions.
I have never heard of this, and there are no settings related to GPU readback in Dolphin's game INI for the game. Do you have information on where you got this from?
All standard TAS settings: Dual Core OFF, Idle Skip OFF, DSP LLE, Skip EFB Access from CPU OFF, MMU OFF
How did you turn off idle skipping?
Updated by andreinsouza 9 days ago
JosJuice wrote in #note-1:
RE3 GCN is known to use EFB reads to detect screen fade state during room transitions.
I have never heard of this, and there are no settings related to GPU readback in Dolphin's game INI for the game. Do you have information on where you got this from?
All standard TAS settings: Dual Core OFF, Idle Skip OFF, DSP LLE, Skip EFB Access from CPU OFF, MMU OFF
How did you turn off idle skipping?
Hi,
Thanks for the reply.
Regarding GPU readback, that was just a hypothesis based on general behavior during scene transitions, I don’t have a specific source indicating that Resident Evil 3 uses anything special related to that in Dolphin.
About idle skipping: since recent versions of Dolphin no longer expose an option to disable it through the UI, I modified the DTM directly for testing purposes to ensure it was disabled during playback/recording.
So for these tests, idle skipping should not be active.
To clarify the behavior a bit more:
The issue only happens during input recording (Movie recording)
It does not happen during normal gameplay without recording
I couldn't find any relevant logs during the ~4000 frame black screen
The game eventually resumes on its own, which suggests a delayed condition rather than a hard hang
At this point, I suspect some kind of determinism or timing issue triggered specifically by TAS recording, but I haven’t been able to isolate which subsystem could be responsible.
If there’s anything else you’d recommend checking, especially anything related to TAS determinism or timing behavior, I’d be happy to test.
Thanks!
Updated by JosJuice 9 days ago
The game eventually resumes on its own, which suggests a delayed condition rather than a hard hang
Okay, so it's not the case that the screen stays black indefinitely like the original report says?
Disabling idle skipping in the DTM file has no effect in recent Dolphin versions, but anyway idle skipping shouldn't have any real impact on this. The important thing to test is to have dual core disabled, which I assume you have tested since the original report says you tested it.
Updated by andreinsouza 9 days ago
JosJuice wrote in #note-3:
The game eventually resumes on its own, which suggests a delayed condition rather than a hard hang
Okay, so it's not the case that the screen stays black indefinitely like the original report says?
Disabling idle skipping in the DTM file has no effect in recent Dolphin versions, but anyway idle skipping shouldn't have any real impact on this. The important thing to test is to have dual core disabled, which I assume you have tested since the original report says you tested it.
Yeah, sorry about that. It’s not exactly the same as I mentioned in the original report. The screen stays black for around ~4000 frames and then the game continues normally. I didn’t realize that on the first attempt.
And yes, I’ve tested with Dual Core disabled.
Updated by andreinsouza 9 days ago
The main issue is that, even though the game eventually continues, this kind of delay makes it unsuitable for TAS purposes, since every frame matters. It’s also very likely that the same behavior would occur on other door transitions throughout the game.
Updated by
Updated by andreinsouza 9 days ago
JMC4789 wrote in #note-7:
It's a timing issue, and since Dolphin isn't cycle accurate anyway, I suggest playing with the emulated CPU clock rate up/down a few percent.
Thanks for the suggestion.
After your advice, I did try adjusting the emulated CPU clock rate to different values (around 80%, 120%, 150%, etc.), but unfortunately it didn’t resolve the issue.
The behavior remains the same: during input recording, the game hits a black screen for 4000 frames (60007000 frames to be more precisely) after entering the door, and then continues normally.
Because of that, it seems less like a general timing sensitivity and more like something specific to how timing/determinism is handled during TAS recording, especially since it does not happen at all during normal gameplay.
Also, even if adjusting the CPU clock could reduce the delay, it wouldn’t really be a viable solution for TAS purposes, since it would introduce non-standard timing and affect reproducibility.
So I believe the root cause is still something deeper related to recording mode rather than just CPU timing variance.
Let me know if there’s anything else I can try.