[Windows-Vulkan/Direct3D11] Radiant Mythology 2 - Character model rendered incorrectly

[master801]

Game or games this happens in

ULJS-00175 - TALES OF THE WORLD RADIANT MYTHOLOGY 2

What area of the game / PPSSPP

After beginning a new game and the cutscenes are finally done, the game allows the player to move.

The character model does not change, causing it to look like it's sitting while sliding across the floor.

This is a Vulkan and Direct3D 11 specific issue. Switching the Graphics Backend to OpenGL works fine.

EDIT: Changing I/O timing method to Simulate UMD delays causes this issue with the Vulkan and Direct3D backends.

Vulkan: https://github.com/hrydgard/ppsspp/assets/2887824/96b3ee51-77d0-449c-89f3-24d7c3297853

Direct3D 11: https://github.com/hrydgard/ppsspp/assets/2887824/c50a579c-e9f8-4976-a7a1-549cdcc6168a

What should happen

Character should be standing and in its walk animation.

Changing the Graphics Backend to OpenGL solves this issue.

EDIT: The fix is to change I/O timing method to Fast, Host or Simulate UMD slow reading speed. It cannot be Simulate UMD delays.

https://github.com/hrydgard/ppsspp/assets/2887824/cc5f31e5-2e05-447d-9303-0250cca031e8

Logs

No response

Platform

Windows

Mobile device model or graphics card (GPU)

AMD RX 580 4GB (31.0.21912.14)

PPSSPP version affected

v1.17.1

Last working version

No response

Graphics backend (3D API)

Vulkan

Checklist

• [X] Test in the latest git build in case it's already fixed.
• [X] Search for other reports of the same issue.
• [X] Try resetting settings or older versions and include if the issue is related.
• [X] Try without any cheats and without loading any save states.
• [X] Include logs or screenshots of issue.

[hrydgard]

Hm, this is really odd! Especially since you have Software Rendering enabled which means that these APIs are only used to blit a CPU-rendered image to screen.

I can't see how this can possibly happen, heh... It really should be the same in all backends, so the cause must be something really weird..

[master801]

It seems this issue is caused by something in my current settings (Documents/PPSSPP), which were migrated from older builds.

I tried the latest Git build (v1.17.1-592) with the Save path as default (in the PPSSPP exe folder), and it seems to have been fixed.

Then I tested v1.17.1 again, with the Save path as default (in the PPSSPP exe folder), and it also seems to have been fixed.

Strange issue.

So, tl;dr, some setting is causing this issue. It's indirectly conflicting with Direct3D 11 and Vulkan, but not OpenGL.

I've attached the ppsspp.ini files here:

Migrated settings / causes bad render: BAD.ppsspp.ini.txt

New settings / no bad render. GOOD.ppsspp.ini.txt

EDIT: After messing with a few settings, I've figured it out.

This issue is caused by I/O timing method being changed to Simulate UMD Delays.

Using options Fast and Simulate UMD slow reading speeds solves this oddly unrelated issue.

I've also tested this in the Git build and it's present there as well.

[anr2me]

It's strange for I/O timing method to affects graphic backends O.o And according to your video, only D3D11 shows the issue, Vulkan and OpenGL looked normal on your video.

Btw, why are you using Software rendering? does disabling it causes more issue?

[hrydgard]

I can't think of another explanation than some strange timing bug in the game (or some different timing bug in PPSSPP that exposes this timing bug in the game).

Either way, we could add a compat.ini setting that forces "Simulate slow UMD reading speeds" in order to work around it..

[master801]

It's strange for I/O timing method to affects graphic backends O.o And according to your video, only D3D11 shows the issue, Vulkan and OpenGL looked normal on your video.

Btw, why are you using Software rendering? does disabling it causes more issue?

I uploaded a video with the wrong test settings, it seems. I've updated the Vulkan video in the OP.

I was using Software rendering in case anyone in the comments were to complain about using graphical enhancements or whatnot. Basically trying to cancel out any other variable that may have affected the rendering.

Strangely enough, since you said that, when I went to re-record the updated Vulkan video, I noticed some weird behavior that PPSSPP seems to do. Video settings don't seem to actually change unless the program is exited and started again? This would explain why the first Vulkan video showed it working, but Direct3D 11 instead showed the bug.

There are a lot of variables and mysteries going on here, and I have no idea what's what.