Final Fantasy II ennemies not correctly disapearing

[Papashango420]

Been happening on pretty much every version of PPSPP I used and I dont know if it was reported,ennemies dont disapear correctly and the sprites stays on the screen until another ennemies dies.It's much more prevalent when there's a lot of ennemies sprites on screen,

[hrydgard]

That's a new one. Windows or Android? If Windows, what backend (OpenGL, D3D)? Does it help to turn off the VertexCache option?

[Papashango420]

Window 7,OGL backend.Seems VertexCache help a bit but the ennemies still take too long to fade out.

[Papashango420]

Seems like it might be coming from OGL,Been playing with D3D for 30 minutes and ennemies disapear correctly.Seems like there's a small stutter with D3D once a while when character are walking tho,Really noticeable on the map.Not that big of a deal,but it might be worth mentionning.

[xebra]

[edit] I can't confirm the first issue. Seems working fine on my PC(NVIDIA Win7 OGL).

[LunaMoo]

Can't see problem with enemies not disappearing in OGL either, but I can reproduce the other problems in d3d11(doesn't seem to happen in d3d9, surely not in OGL).

Happens in possibly all games, but harder to notice in 3D games with camera moving, easiest to notice when walking left/right on the map in those 2D FF games.

Unaffected by vsync or really any other option, but it's different between systems(on same pc) :

• Win 7 - appears as a tear wave constantly, but slowly going from down to up then after a while appearing at the bottom again repeating it's cycle,
• Win 10 - no tear wave, just a slight stutter here and there, seems like it stops happening after walking around same place so it might be something different(shaders compiling?), but the stutter doesn't happen in win 7.

[Papashango420]

Forgot to add that it happens in OGL mainly when there's 6 ennemies sprites or more.Doesnt happen in D3D9 or 11.Played around a bit and I can confirm the stutter in FF2 happens pretty much everywhere in the game for me and especially in the map.Win7 with D3D9 I get some really big stutter. With D3D11 it's just a slight stutter like LunaMoo

[xebra]

@Papashango420 Do you have the save state about disappearing issue?

[Papashango420]

@xebra If you mean a save state in a battle where it can happen,I do FF 2.zip

[xebra]

@Papashango420 Thanks!

[xebra]

I confirmed the problem in v1.3, but can't see in latest builds. @Papashango420 Did you try latest builds?

[Papashango420]

I tried the latest Git Build and everything seems to work fine,ennemies disapear correctly.

[hrydgard]

Great, then I'm closing this one.

[voyageUnseen]

This issue is happening for me with the latest nightly build on Windows with OpenGL, DirectX 3D9 and 11. No difference. It happens when there are about 5 or more enemies. The fade out animation doesn't appear, the enemy dies but stays on the screen (also they stay after escaping), and then disappears after the next enemy dies or the battle ends. I have also seen an enemy stay on the screen long enough for the characters to run over top of it during the victory sequence.

I have an Intel 5200u graphics on my laptop.

[unknownbrackets]

Does it happen when you disable these settings?

• Vertex cache
• Lazy texture caching
• Retain changed textures

If yes, does turning those settings on help?

-[Unknown]

[voyageUnseen]

Those settings on my setup are already disabled, however enabling the three of them together causes the sprites to not update upon changing walk direction, or during the victory dance, or just about any sprite change imaginable gets "stuck" and looks broken. Additionally it made the world-map stutter to the point of being unplayable. And yes, that main issue persisted...or it seems to, all the sprites hang so I can't tell honestly. It was definitely better to have those options off.

[hrydgard]

I guess this is still happening?

[voyageUnseen]

Unless there's been an update that addressed it, it was definitely still happening but may be because of the onboard 5500U intel gpu. That's what I have. I do not experience the same issue on another emulator, but it seems when they disappear it slows the emulation down noticably. Maybe it's an Intel gpu issue?

On Mar 12, 2018 8:43 AM, "Henrik Rydgård" notifications@github.com wrote:

I guess this is still happening?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/hrydgard/ppsspp/issues/9355#issuecomment-372356140, or mute the thread https://github.com/notifications/unsubscribe-auth/AJrvGThYpblP9Oi4nq5sTKVAYOkVPD2hks5tdpemgaJpZM4MLw1d .

[hrydgard]

Please try it with a fresh build of the emulator from https://buildbot.orphis.net/ppsspp/ , no point in speculating :)

[elemesmedve]

Bug is still present in 1.6.3. Tried latest build too (v1.6.3-285-g1f60c85cb). Windows 10 64 bit, Nvidia 1080Ti, all backends, in both 32 and 64 bit builds.

[unknownbrackets]

The issue - at least currently, maybe a new version of the old issue - is related to maxSeenV.

Here's the scenario:

1. There's a texture A that is used with four different CLUTs: A1, A2, A3, A4.
2. Variant A1 only accesses the top half of A, which is a background image. This part of A never changes.
3. Variants A2, A3, and A4 are used for different colors of enemies. These exclusively reference the lower half of A.
4. When an enemy is deleted, the CPU modifies A, applying the wipe-out effect and eventually clearing to transparent.
5. A1 is first set as the texture, and we check the hash. We only hash the top half, which is the same. We don't mark it different.
6. Next, A2 is set. Because the texture address (A) is the same, we don't bother rehashing the texture. So we miss that A actually did change.

I think the best solution to this is to ensure maxSeenV is increased across all clut variants of a texture when a higher value is changed. This will cause STATUS_CLUT_RECHECK to work properly.

-[Unknown]