Emulator

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

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?

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]

Linked (https://files.catbox.moe/32wcxi.zip) 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.

I've determined a cause for the fifolog recording issue (see https://github.com/dolphin-emu/dolphin/pull/12260), but it involves recording multiple fifologs without restarting Dolphin. Do you remember if you recorded another fifolog prior to https://files.catbox.moe/qls8n7.dff ?

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.

I did record a prior fifolog to https://files.catbox.moe/qls8n7.dff 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?

I don't think I need another fifolog to replace https://files.catbox.moe/qls8n7.dff - 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 https://files.catbox.moe/32wcxi.zip 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).

Linked (https://files.catbox.moe/8i7yqt.dff) is a .dff of "Store EFB Copies to Texture Only" turned off on a fresh run of dolphin on macos arm.

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.