Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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. #14198

Open
Ocatopuss opened this issue Feb 21, 2021 · 15 comments
Labels
GE emulation Backend-independent GPU issues
Milestone

Comments

@Ocatopuss
Copy link

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

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

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

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

NPJH50119_00067
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.

NPJH50119_00045
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.

NPEH00060_00000
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
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Collaborator

unknownbrackets commented Feb 21, 2021

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
Copy link
Author

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
Copy link
Author

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
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Collaborator

unknownbrackets commented Feb 28, 2021

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
Copy link
Author

Ocatopuss commented Feb 28, 2021

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
Copy link
Author

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 hrydgard added the GE emulation Backend-independent GPU issues label Jul 6, 2022
@hrydgard hrydgard added this to the Future-Prio milestone Jul 6, 2022
@hrydgard
Copy link
Owner

hrydgard commented Jul 6, 2022

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)

@hrydgard hrydgard modified the milestones: Future-Prio, v1.13.0 Jul 6, 2022
@Ocatopuss
Copy link
Author

Ocatopuss commented Jul 6, 2022

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
Copy link
Owner

hrydgard commented Jul 6, 2022

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

@Ocatopuss
Copy link
Author

Ocatopuss commented Jul 6, 2022

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

@hrydgard
Copy link
Owner

hrydgard commented Jul 6, 2022

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

@hrydgard hrydgard modified the milestones: v1.13.0, Future-Prio Jul 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
GE emulation Backend-independent GPU issues
Projects
None yet
Development

No branches or pull requests

3 participants