Dangan Ronpa random problem with text

[Cloudstrifeff7]

I have a random bug with Dangan Ronpa. Sometimes the text becomes strange and after becomes normal. I am using PPSSPP 0.8.1-1297 Here one screenshot:

[thedax]

This bug has been around for quite a while, but I don't think it's had an issue dedicated to it specifically. For the record, vertex cache OFF doesn't help this bug much, except to make the bug occur less often, though to what extent is hard to quantify. There's also nothing in a typical log that would help, I don't think. A debug log? Perhaps, but a regular log, I doubt it.

[bsauvage1]

If I'm not mistaken, the roms are patched (the native language is japanese) -> looking into what the patch does may give some clue as to why this is corrupted?

[unknownbrackets]

The texture cache doesn't check for texture changes every frame, mostly because it's pretty slow to do so.

If this doesn't happen in the original game, only in the patched version, the patch could be improved by adding a call to sceKernelDcacheInvalidateRange(texbase, texsize); when modifying it.

-[Unknown]

[bsauvage1]

I confirm the original is fine.

Below a link to the patch, if it helps

https://www.dropbox.com/sh/qa4aw74dpqugnhi/0ogyUWil2Q

[bsauvage1]

Fwiw, if you select "Read framebuffer to memory (CPU)", then the text displays ok

[sethfowler]

It doesn't reliably display OK for me on 0.9.1, even with "Read framebuffer to memory (CPU)" selected. When the text becomes corrupted, toggling texture scaling will reliably fix it.

@unknownbrackets, you mention that the emulator doesn't check for texture changes every frame, but when does it decide to do so? When the text is corrupted, for me, sometimes it fixes itself after a while and sometimes it never fixes itself. The fact that it sometimes never fixes itself makes me think that there's no timer that periodically checks for changes. Do you think it would be feasible to periodically make this check, so that if the text is corrupted at least it reliably fixes itself after a short time?

[unknownbrackets]

If the authors of the patch add sceKernelDcacheWritebackRange(start, length); when modifying the font textures, it'll fix this. My understanding is that the original (unpatched) game doesn't have this issue, so it might improve some ghosting on the actual PSP.

It checks textures based on how frequently they change. For example, if a texture remains static for several frames, it'll check it less and less often, because it seems less and less likely it will change. Checking is very expensive, especially on mobile, and that's with a very fast (and weak) hash.

If you are using fast forward, this will be significantly more noticeable, because fast forwarding will "bake" textures in for a lot of frames, and so it will stop checking them often for sure. It will definitely eventually fix itself, but it might take 2048 frames at most, so if you fast forward for example.

For sure there is no timer. It's based on an exponential backoff and only checked when the texture is actually used. There's zero relation to wall clock time.

Adding just a bit of code to the patch would force the texture to be rechecked (we recheck when we have a specific range of the dcache flushed.)

-[Unknown]

[sethfowler]

Thanks for the detailed explanation. I've attempted to contact the authors of the patch about this issue.

[yukinogatari]

Actually, this issue does affect the unpatched game (and the sequel), but that's just being pedantic.

I'll talk to anonscans (our hacker) about making the fix, as that's beyond me--though I can't make any guarantees on if/when it might happen. We were initially planning on not making any updates to the patch, since it might come off as hypocritical or disingenuous to release an improved version of our patch after coming out and saying we support NISA's efforts to release the game officially (and them being kind enough to not ask us to take the translation down). However, we might be able to swing a quick bugfix.

[unknownbrackets]

Oh, I had asked and was told it did not affect the unpatched game.

Well, there's still improvements to be made to the texture caching. I've been thinking we might be able to check textures of certain bitdepths more often, or even ones used with 2d transform, etc.

It would actually help to know what some of the aspects are of this texture and its use (I don't have this game.) Another game that has this issue (unpatched) is Senjou no Valkyria 3, which I'd also like to fix.

-[Unknown]

[unknownbrackets]

From some logs @thedax showed me (thanks), looks like this uses CLUT8 and individual TRIANGLE_STRIP prims to draw the letters. Senjou no Valkyria 3 uses 8888 with a single batched RECTANGLES prim for the majority of its letters afaict.

-[Unknown]

[unknownbrackets]

Apparently per #4939, this is actually vertex cache, or else a combination of the vertex cache and the texture cache.

So, I wonder if any of the changes from #828 help it (with #4939 merged to exclude the possibility of it being both)?

-[Unknown]

[thedax]

In my experience, vertex cache on (with #4939 merged and on default settings for the texture cache) still causes it, but rarely. With it off, it doesn't seem to happen at all anymore. I've only tested for a few minutes, though.

I'll try changes from #828 in a bit.

[thedax]

As I mentioned in #828, turning vertex cache on and changing if (vai->drawsUntilNextFullHash == 0) to if (true) seems to help this game too, with the default texture cache settings. I've yet to see the scrambled text.

Should I test the other values too, like the drawsUntilNextFullHash?

[unknownbrackets]

Well, I'm wondering if changing vai->drawsUntilNextFullHash = std::min(24, vai->numFrames); to 8 would help a lot, or if if (vai->numVerts > 100) { being 200 or something would do the trick. There's got to be a happy medium for performance and glitches somewhere.

-[Unknown]

[thedax]

I tried std::min(24, vai->numFrames); set to 8, no dice. Tried if (vai->numVerts > 100) set to 200, no dice. Tried them together (e.g. both std::min set to 8 and the if statement set to 200), no dice. This doesn't look like it's an easy fix. I'll keep trying other values.

[unknownbrackets]

So, just to clarify, if vai->drawsUntilNextFullHash = 0; is always done, e.g. if it hashes every single time, does it go away? If not, it may be a hash collision, in which case altering those numbers won't help at all.

-[Unknown]

[thedax]

It doesn't help. The only thing that seems to fix it is turning Lazy tex cache off (even when Vertex Cache is off/on, it still happens so long as lazy tex cache is on).

[solarmystic]

Since "Lazy Texture Cache" is defaulted to off in PPSSPP on a fresh installation with a brand new ppsspp.ini file, should we consider the issue resolved? Folk using brand new versions of the emulator with default settings will never encounter the issue.

The same rationale was used in closing this issue https://github.com/hrydgard/ppsspp/issues/4791#issuecomment-31760356 which had a similar solution.

[unknownbrackets]

I think so. I thought it was still an issue with that off, but with vertex cache on (even if to a lesser extent.) How much does it happen with default settings?

The reality is, we can't really make lazy texture caching not... lazy. There will always be glitches like this. If someone has an idea for a new method of texture caching that's fine, but it's not really a bug without some actionable ideas behind it.

-[Unknown]

[thedax]

It never happens with default settings (or it hasn't happened to me yet, even in other games with problems like this, Project Diva's eyes being the exception, since that's a legitimate vertex cache issue), since LTC is off at that point.

[unknownbrackets]

Oh, okay, great. So, then I'll close this.

-[Unknown]