Citra: Tales of the Abyss / Pac Man Party 3D - wrong screens offsets

[JohnGodgames]

These two games have the same problem and it's a pretty old issue...

Tales of the Abyss

Pac Man Party 3D

[JayFoxRox]

I've only taken a look at Pac-Man Party 3D, but:

We have to handle flags (crop_input_lines | flip_vertical) here. We already handle flip_vertical but crop_input_lines is entirely unimplemented in master.
(Not sure if 3DS also supports it for TextureCopy)

DisplayTriggerTransfer: 0x00046500 bytes from 0x1801c000(256x512)-> 0x183ce430(240x400), dst format 1, flags 0x00001005
DisplayTriggerTransfer: 0x00038400 bytes from 0x18030000(256x512)-> 0x180b4830(240x320), dst format 1, flags 0x00001005

The framebuffer is at VA 0x18000000; 256x512 RGBA8
I tried to understand what the crop mode does but figured it's easier / safer to just write a HW-test. However, I'll leave this to somebody else because I don't have particular interest in these games / knowledge about this part of code.

[yuriks]

crop_input_lines doesn't matter for emulation. (On hardware it needs to always be set when your output width is less than the input, otherwise you get bad/skewed output.) It would also not cause the kinds of mis-alignment we see here. The root cause must be something else.

(Pedanticness disclaimer: I guess we could emulate the buggy hardware behavior, but it isn't really useful and it's not reliable across different configurations either. Retail games always set them correctly and homebrew I think always sets it, period. One thing we should do is warn if the flag is not set and input_width > output_width.)

[Subv]

As for Pacman's top screen, the game is properly rendering and doing a display transfer to 0x182FB530 (left fb0), but it tells the LCD to draw from 0x18346500, which is right in between the left fb0 and the left fb1, so we're showing parts of both.
I have no idea why it is doing this.

[benderscruffy]

still happens on the latest nightly

[Subv]

Pacman allocates the output framebuffer at 0x18346500, but during the display transfer call it detects that the output dimensions are smaller than the input dimensions and subtracts some value (that is calculated from the input and output dimensions) from the output pointer, yielding 0x182FB530. It also sets a flag in the display transfer when this happens but i was unable to identify which bit it enabled.

I wonder how the PICA actually handles these cases.

[benderscruffy]

still happens in the latest nightly

citra_log.zip

[benderscruffy]

still happens in the latest nightly