Professor Layton vs Phoenix Wright: Heavy graphical glitches

[Miepee]

First it seems to have the top screen flipped horizontally.

Afterwards, it seems to prefer to display weird stuff at the top:

Finally it just black screens, altho there i'm really not sure whether the performance is just too low

[Miepee]

The bars at the top seem to be cutscene releated I would assume. Kirby Triple Deluxe has the same going on during its cutscenes.

[neobrain]

First it seems to have the top screen flipped horizontally.

Does #50 help? If not, capturing a Mikage frame in RenderDoc and comparing it with another emulator could give a good clue about what's going wrong.

Afterwards, it seems to prefer to display weird stuff at the top:

This looks like the artifact you'd typically see from missing Y2R. Could you run with --enable_logging and check if you find lots of SetReceiving references?

[NVriezen]

Does #50 help?

This should indeed help as Professor Layton is also a Level5 game.

The "weird stuff at the top" is the Level5 logo cutscene.

EDIT: I expect this game to also have problems with its framebuffers, meaning it will have incorrect colours every other frame among other glitches. Similar to the Yokai Watch games.

[NVriezen]

Regarding the Level5 logo intro, it indeed seems a Y2R issue.
Following snippet taken from --enable_logging (YokaiWatch1, but again, both Level5 games):

[16:42:43.427] [OS] [info] IPC message from yw1 to y2r:u: 00180102
[16:42:43.427] [OS] [info] cam_hle (id 20), y2r:uThread: Dispatcher entering
[16:42:43.427] [OS] [info] SetReceiving: Stub conversion to 0x17c7de00-0x17cc4300 in yw1 (id 17)
[16:42:43.427] [OS] [info] cam_hle (id 20), y2r:uThread: Dispatcher leaving 

[neobrain]

This should indeed help as Professor Layton is also a Level5 game.

Great, sounds plausible. Since your PR is now merged, that problem should be resolved then. Could you check if this is the case, @Miepee ?

Regarding the Level5 logo intro, it indeed seems a Y2R issue.

Perfect. Y2R is a hardware module that converts image data from a YUV-based format to RGB (as readable by the GPU). The current stub-implementation just copies the raw data without any conversion, which is why the output looks funny at the moment.

For reference, the way to implement this would involve two steps:

• Enable LLE for the cam module (see the bottom of os.cpp), which I expect would then defer the operation to the Y2R IO registers
• Implement said Y2R registers, which perform the actual format conversion. A shader-based GPU implementation would be ideal for performance, but a slower, software-based implementation would be good enough for a start and still be better than showing a glitchy top screen.

(Implementing this algorithm in cam_hle would also work, but a guiding principle in Mikage is to push complex implementation down in the stack as far as efficiently possible. Besides being easier to test that way, it allows the software-side modules (such as CAM) to be either LLE-ed or HLE-ed, for example, which is useful for self-validation and debugging).

[Miepee]

Could you check if this is the case, @Miepee

I was trying, but I'm having some kinda weird build failures and don't really have the time to investigate them right now.
In case it's helpful, it's about being unable to include <spdlog/logger.h> which exists in a variety of places. I did try nuking the build folder earlier and redoing all the steps but maybe (probably) i messed up somewhere

[neobrain]

In case it's helpful, it's about being unable to include <spdlog/logger.h> which exists in a variety of places. I did try nuking the build folder earlier and redoing all the steps but maybe (probably) i messed up somewhere

That's curious, Conan should normally work everywhere. Can you upload the full build log (from a clean build folder, using make VERBOSE=1 or ninja -v for verbose logs) somewhere, ideally in a new issue report to keep this one focused on the issue?