R-TYPE TACTICS I&II - The graphics becomes rough and missing fluctuation effect when unit desynched into sub-space. Xyanide: Resurrection - often freezes after loading a state.

[Ocatopuss]

Hey there, thanks for the great work that fixed black screen issue of desynch, however there is still a imp that makes when a unit desynched into sub-space the graphics of battlefield (include units) will become rough like "resolution down" after unit desynched (seems this not affect text box, menu, 3D model and animation). When the cursor/camera leave the desynched unit a certain distance away, the graphics are back to normal. The space-fluctuation effect that envelop the desynched unit in a small area is also missing. Software rendering behaves this normally. Others have reported the same issue, see the latest reply in https://forums.ppsspp.org/showthread.php?tid=906&page=2

Before unit desynched into sub-space. "Texture filtering" set to "Auto".

After unit desynched into sub-space. "Texture filtering" set to "Auto".

Before unit desynched into sub-space. "Texture filtering" set to "Nearest".

After unit desynched into sub-space. "Texture filtering" set to "Nearest".

Btw R-TYPE TACTICS/COMMAND I&II require "Buffered rendering" and "Simulate block transfer effects" both, otherwise the graphics will become more abnormally or black screen when unit desynched.

Speaking of animation, There is a noticeable drop in FPS when playing desynching/undesynching animation and could affect FPS of other animation (f.e moving, repairing, fueling, but seems doesnt affect battle animation. R-TYPE TACTICS/COMMAND I only have battle animation) when graphics got rough.

FPS drop noticeably when playing desynching animation.

About the Xyanide: Resurrection issue, the states can occasionally be load normally, but most of the time the game will freeze instantly after loading (sometimes accompanies with black screen), or a second or two before it freezes (no black screen). BGM plays normally. It doesn't help even with Software rendering.

And sometimes it even becomes like this after loading.

I have tried to switch many setting (not including those in compat.ini), such as: Graphics and Audio backend. Buffer graphics commands. Hardware transform. Vertex cache. Texture filtering. Lower resolution for effects. Fast memory. I/O timing method. Etc. But they seem to have no effect.

I enabled compatibility server reports earlier, so hopefully this will help.

ISO used for testing: R-TYPE TACTICS - ULJS00111_1.02 R-TYPE TACTICS II - NPJH50119/ULJS00233_1.05 Xyanide: Resurrection - NPEH00060_1.00

PPSSPP version used for testing: Many 1.10.3 devbuilds, some 1.11 series devbuilds including the latest (as of the point of post) 1.11.2-186-g90f1e98ab.

OS: Win10 Home 1909 64 CPU: i5-6500 GPU: R5 340X with Adrenaline 21.2.2

[unknownbrackets]

Does this happen when you use 1x PSP render resolution? Based on the performance impact, the game is probably doing a readback to apply the desync effect and this probably reduces it to 1x PSP resolution.

-[Unknown]

[Ocatopuss]

Does this happen when you use 1x PSP render resolution? Based on the performance impact, the game is probably doing a readback to apply the desync effect and this probably reduces it to 1x PSP resolution.

-[Unknown]

Thanks for replying unknownbrackets. Yes. They still occurs under 1x PSP render resoultion, no matter 1x Window size or 3x.

[unknownbrackets]

Could you try exporting a GE frame dump? Just make sure to export it while the desync is showing - it's almost like a screenshot. If you make it while the issue isn't happening, it won't help. It might help to also have one before the desync.

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]

[Ocatopuss]

Could you try exporting a GE frame dump? Just make sure to export it while the desync is showing - it's almost like a screenshot. If you make it while the issue isn't happening, it won't help. It might help to also have one before the desync.

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]

I used the alternate method. It records that I control a unit choose Move order → playing moving animation → choose Desynch order → playing desynching animation → desynch finished. Didn't use state. Just not sure if the dump recorded what I want and what you need... NPJH50119_0001.zip

[Ocatopuss]

Well I redump two dump files just in case: 0002 is the status before desynch, 0003 is desynched. I loaded Savestate before record these two dump but the Savestate doesn't have the "restart, and load for less bugs" tip. NPJH50119_0002&0003.zip

And for some reason I can't enable "Log console" to know if the dump finished.

[unknownbrackets]

It draws the texture from size 128x104 to screen at size 103x85, but it does this with linear filtering enabled. It does this in both cases. This looks okay.

In the after version, it draws to a 64x64 square at 0x04088000 around 1218/1540. But then afterward around 1266/1540, it draws from 0x04088000 as a full screen in vertical strips. It replaces the screen with this.

It might've just been a copy, though, because it's 5551. Most likely that's the issue. We could try enabling IntraVRAMBlockTransferAllowCreateFB...

-[Unknown]

[Ocatopuss]

It draws the texture from size 128x104 to screen at size 103x85, but it does this with linear filtering enabled. It does this in both cases. This looks okay.

In the after version, it draws to a 64x64 square at 0x04088000 around 1218/1540. But then afterward around 1266/1540, it draws from 0x04088000 as a full screen in vertical strips. It replaces the screen with this.

It might've just been a copy, though, because it's 5551. Most likely that's the issue. We could try enabling IntraVRAMBlockTransferAllowCreateFB...

-[Unknown]

Hey unknownbrackets. Thank you for following up this issue.

About that 0x04088000, as I said I enabled "compatibility server reports", and it logged "FBO created from existing depthbuffer as color, 04088000/00000000 and 040cc000(or 04000000, 04044000)/04088000" many times.

Btw Xyanide: Resurrection have similar log that's shown as "FBO created from existing depthbuffer as color, 04110000/00000000 and 041e04c0(or 04088000, 04000000)/04110000".

[unknownbrackets]

That's not likely related to this issue.

The depth buffer is how 3D drawing keeps track of drawing things that are closer to you on top of things that are farther away. It's heavily used in most 3D drawing. But usually, it's entirely temporary: once you're done drawing a scene, it doesn't "matter" anymore and you start over.

Because of this, in modern 3D APIs, every time you draw to a new buffer (basically, a new image of the scene), you use a new depthbuffer. Some APIs have limited ways to reuse depthbuffers, but it's not supported everywhere and it's slower.

The PSP's GPU, in contrast, reused depthbuffers by default. So even if a game developer didn't care, and wanted a fresh one each time (which is true of most PSP games), they'd reuse just because that's the easiest thing. This is also because the PSP had very limited VRAM (2 MB, less than 0.1% of most modern GPUs), so handing out new depth buffers like candy was very wasteful.

In this case, the game is reusing depthbuffers in a pretty typical way. It doesn't look like the artifacts are related to that at all.

-[Unknown]

[Ocatopuss]

Thanks for the explanation. I tried to add R-TYPE TACTICS II to "IntraVRAMBlockTransferAllowCreateFB" with compat.ini. It seems the "resolution down" issue got fixed but the space-fluctuation effect that envelop the desynched unit in a small area is still missing.

As for the FPS drops, I tried 1x and 2x window & resolution, no more drops with these setting. It seems that the performance of my PC can not hold it when playing desynching/undesynching animation at 3x window & resolution with some setting. But turn off "Force real clock sync" will help to avoid the drops at 3x window & resolution.

[Ocatopuss]

Hi there, since some version the method to solve the "resolution down" issue by enabling "IntraVRAMBlockTransferAllowCreateFB" is no longer effective. Nightly version: from 1.12.3-1331. Effective in 1329. git version: from d80fd40 (Build #2951). Effective in 7ea5b96 (Build #2950).

Btw if this got fixed (thanks for your precious time), could you enabling "IntraVRAMBlockTransferAllowCreateFB" for R-TYPE TACTICS/R-TYPE COMMAND and R-TYPE TACTICS II in compat.ini by default?

[hrydgard]

Thanks for reporting, 1331 shouldn't have changed anything unless you do some manual changes to the ini so that's weird, I'll investigate. EDIT: There was a bug, fixed now

I will also add IntraVRAMBlockTransferAllowCreateFB indeed. Can you collect the game IDs to add? (like ULUS12345 etc)

[Ocatopuss]

R-TYPE TACTICS Japan: ULJS00111, NPJH50106 Korea: UCKS45065 Asia: UCAS40168 Europe: ULES01121 US: ULUS10343 (R-TYPE COMMAND) NPUH90008 (R-TYPE COMMAND demo)

R-TYPE TACTICS II -Operation BITTER CHOCOLATE- NPJH50119, ULJS00233 NPJH90089 (demo) NPJH90065 — Sorry for the late reply cause this ID took me some time since I have no idea of what this version is: very little information about it.

Btw the "space-fluctuation effect that envelop the desynched unit in a small area" also missing from some version (but I don't know which version to start with at present) even with "Software rendering" enabling (only missing when using Hardware rendering in the past).

[hrydgard]

The compat flags should work in the next builds now that #15653 is merged.

[Ocatopuss]

The issue has been fixed from 1.12.3-1346/Build #2972, thank you for the responding and solving.

[hrydgard]

I've now also added the games to the compat.ini section. Thanks!