Emulator Issues #13377


(RFCEGD) Opaque Overlay Obscures Camera

Added by conte 8 months ago. Updated 7 months ago.

% Done:


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


Game Name?

Final Fantasy Chronicles: The Crystal Bearers

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


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


What's the problem? Describe what went wrong.

[At certain sections of the game, the camera view is obscured by an opaque surface. Replicated on PAL, JP, NA versions across Windows x86, Linux x86, and Macos ARM64 Dolphin.]

What steps will reproduce the problem?

[Start new game, proceed past
-opening airship scene
-starting area
-train ride
-ferret scene
-chocobo escape scene
-introductory cave fight
-ruins area
to skeleton ruins gate stairwell. After falling into the scene transition, the camera will now be obscured. Camera remains obscured for most of the rest of the area. Past this section, the camera is no longer obscured, but further sections of the game obscure the camera once more.

Video of the behavior available at:]

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, 19870]

Is the issue present in the latest stable version?


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 and anyone who is building Dolphin on their own can use git bisect.)


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:

[Linked ( is a 2 frame fifolog, should display character walking around but actually displays a black screen with only the UI visible. The fifolog is too big to fit into the file attachment section.]

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

[Attachments and footage generated on Macbook Pro 13inch, M1 2020, 16GB RAM running Macos Ventura 13.6.]

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

[Linked ( is a savestate of an affected section of the game. The savestate is too big to fit into the file attachment section.]

Actions #1

Updated by conte 8 months ago

20240 for latest dev release, 19870 for latest stable release tested against.

Actions #2

Updated by pokechu22 8 months ago

In that fifolog, the scissor offset is set to (0, 0) instead of (342, 342), which seems to mess things up, but I think that's a fifo recorder issue and not the underlying cause of the problem. Though just to rule any scissor issues out, can you test out 5.0-16340 and 5.0-16348 please, and maybe record another fifolog with one of those?

Actions #3

Updated by conte 8 months ago

For both 16340 and 16348, crashes on emulation start with

Crashed Thread:        37  Mach exception thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000000
Exception Codes:       0x0000000000000001, 0x0000000000000000

Termination Reason:    Namespace SIGNAL, Code 11 Segmentation fault: 11
Terminating Process:   exc handler [19031]
Actions #4

Updated by conte 8 months ago

Linked ( are 4 fifologs of the bug on 5.0-16340 and 5.0-16348 for both PAL and US on a Windows 10 system using the vulcan backend. The bug occurred in all four test cases.

Actions #5

Updated by pokechu22 8 months ago

  • Status changed from New to Accepted

I can confirm that RFCPGD ghost city 16340.dff works correctly on real hardware when using the hardware fifoplayer. (Or at least, it renders something; the exact result looks a bit weird but that's probably due to the hardware fifoplayer itself being janky. RFCEGD bahamut strike 16340.dff causes the hardware fifoplayer to crash (both on real hardware and on dolphin) for some reason, but that's not too important.)

The game seems to be doing some sort of postprocessing effect where it downscales a greyscale copy of the screen, and then redraws everything with that copy multiplied by the original (color) screen contents. It tries to apply a color palette to this process, but in Dolphin the color palette is entirely black, so the final result is all black too.

I also looked at some other videos of the game, and it seems like it worked correctly back in October 2021. (I'm pretty sure that video is in Dolphin, because of stuttering and flickering that wasn't present in another older playthrough; here's the same scene in that other playthrough.) Unfortunately the issue still happened when I tried the fifolog on older versions (August 2021's 5.0-15105, July 2021's 5.0-14790, and May 2021's 5.0-14344, as well as the very old 5.0 stable). So I'm not 100% sure that it worked in the past.

Actions #6

Updated by pokechu22 8 months ago

I've determined a cause for the fifolog recording issue (see, but it involves recording multiple fifologs without restarting Dolphin. Do you remember if you recorded another fifolog prior to ?

Actions #7

Updated by iwubcode 8 months ago

This was reported before but never on the bug tracker. This is one of my favorite titles, so I decided to play up to the same point described in the report and simply disabling "Store EFB Copies to Texture Only" fixes the issue.

I would not say the presence of everything working in the video means that this is a regression. It may be that the streamers had the value disabled.

A less intensive fix may be feasible with a graphics mod, once the functionality gets merged.

Actions #8

Updated by conte 8 months ago

I did record a prior fifolog to during that session of execution, but I no longer have it. Should a fresh fifolog be recorded?

Disabling 'Store EFB Copies to Texture Only' fixes the issue. Should a fresh fifolog be recorded between the setting turned on and off?

Actions #9

Updated by pokechu22 8 months ago

I don't think I need another fifolog to replace - qls8n7.dff itself doesn't work (due to the issue I fixed in PR 12260), while the one you recorded before that would have. But the other fifologs in should have the same information.

Recording one with "Store EFB Copies to Texture Only" turned off would be appreciated (just make sure that you restart dolphin before recording it).

Actions #10

Updated by conte 8 months ago

Linked ( is a .dff of "Store EFB Copies to Texture Only" turned off on a fresh run of dolphin on macos arm.

Actions #11

Updated by pokechu22 7 months ago

The game is definitely using a TLUT here to adjust brightness after making a greyscale copy (interestingly it doesn't seem to be using the blurred copy for this); here's what it looks like:

|Input value|0|1|...|23|24|25|26|27|28|29|30|...|72|73|74|75|76|77|78|...|254|255|
|Output value|80|80|80|80|80|83|86|90|93|96|100|floor((v-24)*(10/3))+80|240|243|246|250|253|255|255|255|255|255|

(The output value ended up being 0 for everything when "Store EFB Copies to Texture Only" is disabled.)

For "Store EFB Copies to Texture Only" to affect things, they must be dynamically generating the TLUT from a texture copy somehow, but that doesn't happen in the frames the fifolog contains. I'm not sure how they'd be doing that either as my understanding is that a 256 by 1 texture wouldn't just be 256 bytes in order in memory, but instead 4 by 4 chunks (or some other size) groups of colors which just wouldn't work. I'm be curious as to what it's doing but I don't think there's any good way of doing that apart from getting the game myself (which I don't plan on doing right now).

We probably should enable "Store EFB Copies to Texture Only" by default in the gameini since it seems like the game's unplayable in these sections otherwise.


Also available in: Atom PDF