mirror of
https://github.com/hrydgard/ppsspp.git
synced 2026-04-26 06:36:05 +03:00
[GH-ISSUE #3151] Dangan Ronpa random problem with text #1310
Labels
No labels
Atrac3+
Audio
CPU emulation
D3D11
D3D9 (removed)
Depth / Z
Feature Request
Font Atlas
GE emulation
Guardband / Range Culling
HLE/Kernel
I/O
Input/Controller
MP3
Multithreading
Needs hardware testing
Networking/adhoc/infrastructure
No Feedback / Outdated?
OpenGL
PGF / sceFont
PSMF / MPEG
Platform-specific (Android)
Platform-specific (Windows)
Platform-specific (iOS)
PowerVR GPU
SDL2
Saving issue
User Interface
Vulkan
arm64jit
armjit
armv6
x86jit
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/ppsspp#1310
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Cloudstrifeff7 on GitHub (Aug 13, 2013).
Original GitHub issue: https://github.com/hrydgard/ppsspp/issues/3151
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 commented on GitHub (Aug 14, 2013):
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 commented on GitHub (Aug 14, 2013):
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 commented on GitHub (Aug 14, 2013):
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 commented on GitHub (Aug 14, 2013):
I confirm the original is fine.
Below a link to the patch, if it helps
https://www.dropbox.com/sh/qa4aw74dpqugnhi/0ogyUWil2Q
@bsauvage1 commented on GitHub (Aug 15, 2013):
Fwiw, if you select "Read framebuffer to memory (CPU)", then the text displays ok
@sethfowler commented on GitHub (Sep 28, 2013):
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 commented on GitHub (Sep 28, 2013):
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 commented on GitHub (Sep 28, 2013):
Thanks for the detailed explanation. I've attempted to contact the authors of the patch about this issue.
@yukinogatari commented on GitHub (Sep 29, 2013):
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 commented on GitHub (Sep 29, 2013):
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 commented on GitHub (Sep 29, 2013):
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 commented on GitHub (Jan 2, 2014):
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 commented on GitHub (Jan 2, 2014):
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 commented on GitHub (Jan 2, 2014):
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 commented on GitHub (Jan 2, 2014):
Well, I'm wondering if changing
vai->drawsUntilNextFullHash = std::min(24, vai->numFrames);to 8 would help a lot, or ifif (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 commented on GitHub (Jan 2, 2014):
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 commented on GitHub (Feb 15, 2014):
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 commented on GitHub (Feb 15, 2014):
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 commented on GitHub (Feb 15, 2014):
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 commented on GitHub (Feb 15, 2014):
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 commented on GitHub (Feb 15, 2014):
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 commented on GitHub (Feb 15, 2014):
Oh, okay, great. So, then I'll close this.
-[Unknown]