Flickering random text characters in Sol Trigger / Naruto UNH 3

[joelolopez]

flickering random characters when playing sol trigger tested on vulkan/open gl backend. this also occurs on naruto shippuden ultimate ninja heroes 3

here are the screenshots

OS android 7.0 , Octa-core, 2360 MHz, ARM Cortex-A53, 64-bit, 16 nm , Mali-T830 MP2 , 4 GB RAM

[unknownbrackets]

Does this happen even when you disable "Vertex cache" and "Lazy texture scaling"? Also make sure "Reuse changed textures" is off.

-[Unknown]

[joelolopez]

I didnt see any "reuse changed texture" at the configuration.. Vertex cache and lazay texture scaling seems working on naruto but i doesnt have any effect on sol

[unknownbrackets]

Does it happen when it's not animating/drawing the text (e.g. just while it's sitting)? If so, could you try exporting a GE frame dump? These help a lot.

See here for instructions - it's not hard and works on Android too:
https://github.com/hrydgard/ppsspp/wiki/How-to-create-a-frame-dump

You can zip that and then drag and drop it into a reply here.

-[Unknown]

[wolfram55]

This also happens in the JP version I'm trying. I hope its the same problem. The characters flicker around to different characters before finally settling on the proper character. Its playable if you wait for the text to settle, albeit extremely annoying. Happens anywhere with text. Menus, battles, dialogue, etc.

I don't know how to upload a dump, so here is a dropbox link to the before and after dump files.

https://www.dropbox.com/sh/zdv1mb1u7j7i796/AABdhaSeXkw8ug6XWMV58YR6a?dl=0

[nfathoni79]

PPSSPP Android version 1.8.0.
Random characters:

Actual characters:

[LunaMoo]

This is weird, the hash doesn't seem to fail and a better one doesn't help.
Also when drawing the prim one by one it get's correct glyph in the preview, but then after it finishes/ends frame when it sets new framebuffer width of 200(font texture is half of that ~ 256x128) followed by pointer the preview instantly changes to wrong glyphs. The font is filled with somewhat random and repeated glyphs and changes with each new glyph drawn(I made that unclear so to make it clear - the font texture changes when new character is drawn in-game, not when next one is drawn in the same frame), so if it would somehow use wrong width for the final draw it could explain constantly changing characters while the font is being filled during text showing up.

[unknownbrackets]

Is it perhaps a flushing issue? Does it reproduce in a GE frame dump?

-[Unknown]

[LunaMoo]

I think GE debugger got disabled in some recent change, I'll check in older version >.> Edit: NVM I pushed a fix, it was just a typo in #12026 will check frame dump in a moment.
Ok so it can't be reproduced in frame dump, but also doesn't happen in D3D backends :3.

[LunaMoo]

Heh actually it can happen in D3D backends as well, it's just rarer there...

^That change happens after FINISH and END, but before clear right after framebuffer pointer is set.

Dump as I said doesn't reproduce the problem, but maybe it'll be still useful somehow ~ I have to leave ;3.
NPJH50619_0001.zip

[unknownbrackets]

I'm pretty sure the issue here is that the game is modifying the texture while the display list is stalled (possibly to add more characters to draw or whatever.)

In other words, see #9449. Since we don't check the texture if already set when resuming from stall, we draw using the old texture data and get the wrong image.

Which aligns well with observations:

• The GE debugger force sets the texture to download it, which avoids this problem.
• The GE frame recorder reads from RAM directly and checks each prim, so is immune to this problem. It also does its own stalling for memory management, so it doesn't stall exactly the same way.
• All graphics backends (except software) share this same texture behavior.
• Once the full text is drawn, all textures are static, so they "settle" at the end because there's no more modification and our texture cache rechecks the hash next frame.

If we really wanted to keep the #9449 optimization but also fix this bug, potentially we could check to see if a memcpy is being used to write into the texture (or some other easily detectable way.) We could dirty the texture image flag only if there's a texture set and the memcpy/memset is in its range, for example.

-[Unknown]

[hrydgard]

Yeah, it's a tricky one to do well. Some games that draw in stupid ways are really hurt by re-checking the texture, especially if it's large like in that one mini game. Could of course always "solve" it with a compat option for the few really badly affected games...

[genos1213]

I'm still having the text flickering issue with Last Ranker and Sol Trigger. Using a Snapdragon 855 device.

[unknownbrackets]

Picked up Sol Trigger. Right near the first save point, "Save" seems to do the flicker thing. Draw 1463/1468 is when it starts with the letters.

Texture in this is 0x08b8b430 (256x128). Each letter is drawn with a stall right after. Writes to this texture are from PC=0894fd68 (z_un_0894f9d4), which is a function that calls sceCccUCStoJIS and sceCccEncodeSJIS. Apparently, Last Ranker has a similar function but I don't know if it's exactly the same.

Reverting #9449 does fix it, which seems to confirm my theory before. And gstate_c.Dirty(DIRTY_TEXTURE_PARAMS); is not enough, but gstate_c.Dirty(DIRTY_TEXTURE_IMAGE); is (as expected.)

I guess I'll add a hook, I think this func is common to both games.

-[Unknown]

[unknownbrackets]

Once the build on #15549 is done (find it under Checks -> Arifacts) or it's merged (into the latest git build), you can verify if that worked in Sol Trigger and Last Ranker.

Does Naruto Heroes 3 have the same issue still? Does it also not reproduce in a frame dump or with the debugger? I think there's a demo for that game (not sure), can someone upload a save state from the demo right where you can easily reproduce this issue?

-[Unknown]

[padoverc]

Sol Trigger text is fixed (I thought the text flicker was some weird edgy design choice by the devs). Sort of related, is it just me or are the voices super quiet?

[unknownbrackets]

Yeah, the text was a bug. In some places it seems intentional, but it happens too often.

For the audio volume, check your reverb volume setting. See #6511.

-[Unknown]

[joelolopez]

if i'm not mistaken this error does not occur anymore on the latest version you may close this issue😊