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.42k stars 2.19k forks source link

[D3D9] Screen shaking during FMV in all Hatsune Miku games #13374

Open Leopard20 opened 4 years ago

Leopard20 commented 4 years ago

The screen shakes when playing the intro videos. pd.zip I'm not sure when this started happening, but I'm running the latest dev build (v1.10.3-550)

I'm not sure if this is related or not: https://github.com/hrydgard/ppsspp/issues/13370

hrydgard commented 4 years ago

13370 is likely related yes. The new framebuffer management that helped fix Test Drive needs a bit more work.

hrydgard commented 4 years ago

Is this ok now after #13397 ?

Leopard20 commented 4 years ago

Nope. Not fixed yet. Not sure if this is useful (it appears to be empty): recording (3).zip

hrydgard commented 4 years ago

This only happens in D3D9, right?

Leopard20 commented 4 years ago

I'm on Android! ¯_(ツ)_/¯ Vulkan and OpenGL

hrydgard commented 4 years ago

Oh! Weird.

Using postprocessing effects?

Leopard20 commented 4 years ago

Good guess! Yeah. I removed the PP effects and it now looks fine. I think both of "natural colors" effects have this issue. The rest looked fine.

I'll see if I can find the issue.

hrydgard commented 4 years ago

I'm guessing the game somehow ends up drawing the video in two different ways, one frame directly to the backbuffer and the other through a framebuffer, and it flips between those and there's a subtle offset bug in one of them when using postprocessing ...

Leopard20 commented 4 years ago

You were right about D3D9 though. It is broken with or without the shader. So please add the tag again. I fixed the issue with one of the shaders. I'm not sure what the blurry one is doing tbh! :)

unknownbrackets commented 3 years ago

I'm guessing the game somehow ends up drawing the video in two different ways, one frame directly to the backbuffer and the other through a framebuffer, and it flips between those and there's a subtle offset bug in one of them when using postprocessing ...

Yes, as per #3417. Maybe this is related to DrawFramebufferToOutput when it goes directly through presentation, i.e. not accounting for the half pixel offset?

-[Unknown]

hrydgard commented 3 years ago

Yes, that's what I'd guess.