search

hrydgard / ppsspp

A PSP emulator for Android, Windows, Mac and Linux, written in C++. Want to contribute? Join us on Discord at https://discord.gg/5NJB6dD or just send pull requests / issues. For discussion use the forums at forums.ppsspp.org.
https://www.ppsspp.org
Other
11.03k stars 2.15k forks source link

Fate Extra graphical artifact #6273

Open daniel229 opened 10 years ago

daniel229 commented 10 years ago

Since https://github.com/hrydgard/ppsspp/commit/acab898be0b6075ef13b5f856753abb23dda8874

01

before 02

unknownbrackets commented 10 years ago

Which texture is it? Does it look like it ought to be rendered at all?

-[Unknown]

daniel229 commented 10 years ago

just compare to psp's,it does not ought to be rendered. 201406092317_001

daniel229 commented 10 years ago

the ghost is more clearly seeing here 03

before 04

unknownbrackets commented 10 years ago

It seems to me that it's drawing some bloom, and it accidentally latches onto a framebuffer instead of an actual in-memory texture.

It must be nearby. I wonder how common y-offset framebuffers are vs. just x offset. Maybe we reduce the subarea max or use a ratio instead of hard limit. Could also check remaining height vs total height of texture.

-[Unknown]

unknownbrackets commented 10 years ago

How does ef12694c4b926c9619c24764bc369adbdc38af87 look?

-[Unknown]

daniel229 commented 10 years ago

Look better,still a little bright. 06

daniel229 commented 10 years ago

God of War,shadow problem come back. 07

unknownbrackets commented 10 years ago

God of War's problem isn't handled yet, if it was fixed before it was by accident.

-[Unknown]

daniel229 commented 10 years ago

I see.

unknownbrackets commented 10 years ago

Although, I think we can handle that with just viewport hacks... I think? Well, at least for non-3d... hmm. I wonder if it draws in throughmode.

In its case all the render textures start on the same line, which is probably the safest way to detect the offset. I doubt games are doing y offsetting, but then, who knows...

-[Unknown]

daniel229 commented 10 years ago

just before the bright. 08 09

unknownbrackets commented 10 years ago

Hmm. Fixed blending without a texture, what are the vertex colors? Is lighting enabled?

-[Unknown]

daniel229 commented 10 years ago

lighiting is enabled 11

vertex colors 10

unknownbrackets commented 10 years ago

Has this improved at all with the vram mirror attachments maybe?

Also, if you comment out the block starting with if (fbInfo.yOffset > MAX_SUBAREA_Y_OFFSET_SAFE && addr > 0x04110000) {, does it fix it maybe?

-[Unknown]

daniel229 commented 10 years ago

No,it doesn't change anything.comment out that block not help either.

unknownbrackets commented 9 years ago

If you double click alpha blend mode right before it's doing it, and change the value to 000000aa, is it still too bright? I just want to make sure this is where the problem is coming from.

If so, then the brightness is coming only from the drawing, which seems confusing because acab898be0b6075ef13b5f856753abb23dda8874 shouldn't affect that? Hmm.

-[Unknown]

daniel229 commented 9 years ago

too bright is gone 01

compare 02

unknownbrackets commented 7 years ago

Does this look correct in the software renderer?

-[Unknown]

Arrkhon commented 6 years ago

I am not really sure if this how it should look but it looks somewhat right based on PSP screenshot earlier on god this is slow There's also glitch when you leave the classroom that I am pretty sure is caused by camera being too high but it's probably not relevant glitch

unknownbrackets commented 6 years ago

Could you try exporting a GE debugger dump on PC?

To do this, open the game and select Debug -> GE debugger..., then when it's displaying the scene, press Record in the top right. After a second or so, it'll finish and save a trace of the drawing activity.

After that, check the memstick/PSP/SYSTEM/DUMP folder and it'll have created a file named something like "ULES12345_0000.ppdmp". You can zip that and then drag and drop it into a reply here.

-[Unknown]

ghost commented 2 years ago

Shadow is incorrect position using vulkan backend.

https://user-images.githubusercontent.com/37603562/136020161-6f636473-8a00-4601-8c91-f41dcf8d40bb.mp4

ghost commented 2 years ago

On that area the game got a graphics regression. Both opengl and vulkan. Screenshot_2021-10-13-19-38-25-960_org ppsspp ppsspp fate extra.zip

unknownbrackets commented 2 years ago

It starts like this, which looks fine enough: Scene without unexpected flecks of light everywhere

Then at 452/593, it reads from 0x08929ce0 (the address would be different in the game, but in any case, not VRAM), which looks like static. It's a 64x64 texture, but it's only drawing from 40x8 of it. This is drawn with an alpha test and src.a + ONE blend. It then blooms with the static, which blurs the static a bit.

If the static is skipped, it looks like this: Same scene without flecks, but possibly with a missing sunflare effect

Because the static is in RAM, I haven't tried this on a PSP; whatever operation caused the static isn't a GE drawing operation specifically, but is either a bad block transfer, CPU, HLE, or other issue. I'm sure the dump would show the same static artifacts on a PSP.

The interesting thing was that I'd previously thought this was an issue with render-to-texture detection. Since the dump shows a RAM address, it can't be VRAM (it intentionally maps VRAM -> VRAM to capture framebuffer effects correctly.) My best guess is this is block transfer or missing memory copy function hook related... but I wonder what it's trying to draw here.

-[Unknown]