Danganronpa (NPJH50515) :- Selecting a certain object causes another object to be selected instead in Investigation mode when using Buffered Rendering mode (ATI/AMD/Android)

[solarmystic]

First responsible commit is the one that allowed Danganronpa to be played in plain ol' Buffered Rendering Mode, 1a8369e by @unknownbrackets

What happens is adequately shown in this short video (when Buffered Rendering is used):-

https://www.mediafire.com/?4gdiq1xntjqchh4

(Trying to open the drawers activates the Lint Roller instead, trying to pick up the Lint Roller activates the notepad, trying to read the notepad activates the sheet of paper on the wall, and so on. You get the idea.)

There is no last unaffected commit since in all prior builds to that one, Danganronpa needed one of the two Read Framebuffers to Memory modes to have a working targeting reticule during Investigation Mode.

Savedata for reproduction (rename jpg to 7z and use 7zip to extract savedata):-

Background:-

(RFB2M = Read Framebuffers to Memory)

This is actually not a new issue and I suspect it's one specific to AMD/ATI cards and Android devices only, since I recall @arnastia (the one who first implemented and introduced the RFB2M modes into PPSSPP ages ago) developed the two modes specifically to cater for the shortcomings in AMD/ATI cards with regards to the RFB2M (GPU) mode.

In builds prior to the hack, AMD cards would also exhibit this issue if the RFB2M (GPU) mode was chosen instead of the RFB2M (CPU) mode, which provided greater accuracy at the expense of speed. In fact, that was the only reason why RFB2M (CPU) was kept around as an option.

It's quite possible that the specific hack created for Danganronpa to activate the reticule with only Buffered Rendering did not take those shortcomings into account.

This is with default settings except for 3x Window Size (Buffered Rendering/Simulate Block Transfers enabled/Function Replacements enabled)

Temporary Solution:-

Use Read Framebuffers to Memory (CPU) for those specific instances when the game exhibits the issue.

Test System:-

Many thanks to Onizuka from the ppsspp.org forums for bringing this issue to my attention:-

http://forums.ppsspp.org/showthread.php?tid=940&pid=87906#pid87906

Previous long-running Danganronpa issue thread for reference:-

#1686

[unknownbrackets]

Does this reproduce somewhere in the demo? I may be able to test this on an ATI card, but I don't actually have the full game.

Well, we can probably just change it to CPU "by default". Is it faster in GPU or anything?

-[Unknown]

[solarmystic]

@unknownbrackets According to Onizuka's post in the ppsspp.org forums (that I linked to at the end of the issue post), the issue is also reproducible in a certain segment of the demo. He brushed it off as a bug specific to the demo.

RFB2M (GPU) is obviously faster but can't be used on AMD/ATI cards due to the aforementioned issue.

The difference between using your hack in Danganronpa (Buffered Rendering) and Read Framebuffers to Memory (CPU) is in the order of around 100+ VPS on my system so it'd be a shame if ATI users were forced to have to enable that mode again in Danganronpa.

[unknownbrackets]

What I mean is that, the hack triggers the "read framebuffers to memory" functionality. Within that functionality, it decides whether to dither the result down to the correct bitdepth on the CPU or the GPU based on the setting.

I assume that currently, it uses the GPU if the setting is not set to use the CPU. We could change the default here so that it uses the CPU, unless it is set to GPU. This would only matter when the rendering mode is actually set to "buffered rendering". This would mean that the hack would work for everyone if only the CPU mode can work.

That being said, I had hoped the issue was related to downsampling (2x -> 1x). Danganronpa draws blobs of solid color. It sorta looks like this:

+------------------------------------------------+
|                                                |
|   RRRRR                                        |
|    RRRRR      GGGGGGGGGG                       |
|               GGGGGGGGGG                       |
|               GGGGGGGGGG                 BB    |
|                                          BB    |
|                                                |
+------------------------------------------------+

So, for it to misidentify an object, it generally means the color is probably entirely wrong, or otherwise the color has been dithered and does not exactly match the original color drawn.

-[Unknown]

[solarmystic]

@unknownbrackets Ah, understood. I think the solution would be to change to use the CPU instead, unless you want to set mutiple ifdefs in the code to differentiate between AMD/ATI and NVIDIA graphics cards.

[unknownbrackets]

Question: if you change this code in GPU/GLES/Framebuffer.cpp:

        if (ShouldDownloadFramebuffer(vfb) && age == 0 && !vfb->memoryUpdated) {
#ifdef USING_GLES2
            bool sync = true;
#else
            bool sync = false;
#endif
            ReadFramebufferToMemory(vfb, sync, 0, 0, vfb->width, vfb->height);
        }

To:

        if (ShouldDownloadFramebuffer(vfb) && age == 0 && !vfb->memoryUpdated) {
            bool sync = true;
            ReadFramebufferToMemory(vfb, sync, 0, 0, vfb->width, vfb->height);
        }

Does it work properly, or still doesn't work (with buffered rendering)?

And, if you unthrottle and use CPU or GPU (not buffered rendering), is there a performance difference? I read somewhere that using PBOs is much slower on AMD cards.

-[Unknown]

[solarmystic]

@unknownbrackets Answer: Changing the code in GPU/GLES/Framebuffer.cpp as instructed fixes the issue (with buffered rendering).

When unthrottling there is a noticeable performance difference between CPU and GPU (RFB2M), but the difference itself varies depending on the scene. In the worst case scenario, GPU is up to 50 VPS faster, but this seldom occurs. Typically, the performance advantage of GPU is around 10 - 15 VPS.

[unknownbrackets]

Sorry, I meant does the change above (in either mode) cause any performance different unthrottled? It makes it download directly rather than using an asynchronous download to a pixel buffer object. I realize that GPU is at least slightly faster, but I don't know if this pixel buffer object is buying anything on AMD cards.

Also, 15 VPS faster doesn't mean anything. 1000 -> 1015 is tiny. 10 -> 25 is huge.

-[Unknown]

[solarmystic]

Oh, you meant when comparing "like" for "like" (before and after your change)?

In a given scene (the one chosen is the one with the issue as shown in the video), unthrottled:-

Before your change

Buffered Rendering 714 VPS
Read Framebuffers to Memory (CPU) 449 VPS
Read Framebuffers to Memory (GPU) 450 VPS

After your change

Buffered Rendering 633 VPS
Read Framebuffers to Memory (CPU) 425 VPS
Read Framebuffers to Memory (GPU) 425 VPS

Overall performance reduction in all rendering modes for the scene, but performance is still way above the threshold where one would notice the regression during normal gameplay. More importantly, buffered rendering is still the clear performance champion as compared to the other two, and is fixed after your change.

[unknownbrackets]

In the demo, is this after the first trial or something? When there were signs of a struggle, everything seemed to examine fine with default settings + vertex cache off in this room on a Radeon X1600.

A savestate would help if so, just so I can get right to it. Darn Mac is pretty old and slow. I just want to be able to test it, and also see what is actually happening wrong when the GPU converts it.

-[Unknown]

[solarmystic]

I just got through the entire demo myself and I can't find a room where the object selection is out of whack either. I made sure to explore every single room available in the demo prior to the first trial.

Hmm... it'll be very troublesome if the issue is only reproducible in the full version of the game

And nope, the first trial is all there is to it for the demo after the initial exploration for clues, it cuts off abruptly at that point.

[unknownbrackets]

Thanks, I thought it cut off after the first trial which is why I was a bit confused.

We can try a savestate for the full game, I can load it on the demo. Sometimes this will work well enough to experience an issue like this, but it will eventually crash.

-[Unknown]

[solarmystic]

@unknownbrackets Here's a savestate from the affected scene in the full game:-
(unzip using 7zip)

https://www.mediafire.com/?x0vfb388ckh2f6k

You'll obviously have to rename it to the demo's game id to load it.

[unknownbrackets]

So in this case, the colors are pretty similar:

The drawer is 00FFD8, and the lint roller is 00FFC0. The format is 1 (5551), which means these each have a blue of are different 24 and 27. Strange that it would be so inaccurate. Reversing the pixel order or RGB components doesn't seem to help.

-[Unknown]

[hrydgard]

Hm. Wonder if dithering might be involved.. glstate.dither.disable() ?

[unknownbrackets]

Ah, I'll try dithering, hold on. Works.

-[Unknown]

[thedax]

Apparently this still isn't over yet.

http://forums.ppsspp.org/showthread.php?tid=940&pid=88055#pid88055

[unknownbrackets]

On mobile, pretty sure we always convert using the CPU. Not sure what differently we can do there. We're already forcing it to 1x.

-[Unknown]

[thedax]

Assuming some odd setting isn't at fault for them, I have no idea what it might be..

[unknownbrackets]

I guess if we looked at a savestate from an affected device, we could try to figure out what it's writing to memory that is wrong. It would be a bit of a pain to do, but that might answer what's going on.

Actually, maybe that would double-confirm that it's dithering in @solarmystic's savestate...

Right after loading the state, just dump 128 * 72 * 2 bytes starting at 0x04154000 to a file should do it. Then open in some image editor as 5551 raw.

-[Unknown]

[thedax]

I can check to see if my Tegra 2 device is afflicted, but I doubt it is. I'll report back shortly.

[unknownbrackets]

If you can create a savestate we can at least examine it to see what its malfunction is.

-[Unknown]

[thedax]

@unknownbrackets: Here are the savestates for your perusal: http://www.mediafire.com/download/a5f1p0b2xfbpa20/danganronpa-affected-sstates.7z

Slot 2 is taken before examining the drawers, and slot 3 is taken after examining the drawers, just to be safe.

[unknownbrackets]

On my card, the lint roller is 0/255/198. On yours, pixels alternate between 0/255/198 and 0/255/189. Definitely dithering. So you might get it if you click in just the right spot.

Is this affected by the TrueColor setting at all? If you turn it off, I mean?

-[Unknown]

[thedax]

To keep the conversation flowing smoothly (we're on IRC too), here are my results:

TrueColor = True: the drawers pretty much always examine the lint roller instead. I haven't found a sweet spot yet.

TrueColor = False: the drawers are always examined correctly.

[unknownbrackets]

There are two ways to fix this, both work.

https://github.com/unknownbrackets/ppsspp/compare/danganronpa-hack1?expand=1
https://github.com/unknownbrackets/ppsspp/compare/danganronpa-hack2?expand=1

@hrydgard which do you think we should do? Or both? Not sure if any other games will care about the exact values.

-[Unknown]

[hrydgard]

Well, hack 2 has the advantage that it doesn't differentiate between GPUs. Having the emulator take different paths on different GPU makes issue reports less consistent. But since the GPUs do differ in behaviour hack 1 makes some sense as well...

Slight win for hack 2 in my book but I don't mind either much.

edit: oh yeah, hack 1 is more likely to fix other games with the same issue but I don't think we've seen any...