Screen vibrates slightly when starting a Monster Hunter game with a post processing shader since v1.9.3-538

[tywald]

What happens?

Screen shakes a bit if you start a Monster Hunter game with a post-processing shader (need to be enabled before starting the game). Turning off then on while game is running "fixes" it if you are using Auto(1:1) rendering resolution or by changing resolution manually(no need to turn off the shader in this case, a simple resolution refresh does it). It appears the issue started with v1.9.3-538-ga70f00ca8 as v1.9.3-530-g639a0b7eb works fine.

Reverting #12746 on latest master fixes it.

What should happen?

Screen shouldn't shake if you start a game with a post-processing shader.

What hardware, operating system, and PPSSPP version? On desktop, GPU matters for graphical issues.

CPU: i7-3770K
GPU: GTX 1070
OS: Windows 10 Home 64-bit
PPSSPP version: v1.9.3-538-ga70f00ca8 and later

Video: https://i.imgur.com/PENe8QW.mp4

[unknownbrackets]

Can you paste the log shown when you resize? It should show created/deleted FBOs, which is what I'm interested in.

-[Unknown]

[iota97]

I could reproduce on MHFU, upon changing rendering resolution I get:

05:38:789 idle0        I[FRAMEBUF]: Common/FramebufferCommon.cpp:1730 Destroying FBO for 04000000 : 480 x 272 x 1
05:38:789 idle0        I[FRAMEBUF]: Common/FramebufferCommon.cpp:1730 Destroying FBO for 04044000 : 481 x 273 x 1
I: thin3d_gl.cpp:963: Linking shaders.
05:38:811 idle0        I[G3D]: Common/TextureCacheCommon.cpp:1585 Texture cached cleared from 2 textures
05:38:811 user_main    I[FRAMEBUF]: Common/FramebufferCommon.cpp:373 Creating FBO for 04044000 : 481 x 273 x 1
I: GLQueueRunner.cpp:426: Creating 1440 x 816 FBO using no depth
I: GLQueueRunner.cpp:496: Creating 1443 x 819 FBO using DEPTH24_STENCIL8 texture
05:38:912 user_main    I[FRAMEBUF]: Common/FramebufferCommon.cpp:373 Creating FBO for 04000000 : 480 x 272 x 1
I: GLQueueRunner.cpp:496: Creating 1440 x 816 FBO using DEPTH24_STENCIL8 texture

[tywald]

InfoLog:
ppsspplog.zip

Was using (1:1) resolution so when I maximize the window it would resize.

[unknownbrackets]

Est: 04044000 V: 0x0, R: 480x272, S: 481x273, STR: 512, THR:1, Z:44088000 = 481x273

What if you move the lines added in that pull (#12746) down so they are right above // Assume no buffer is > 512 tall, it couldn't be textured or displayed fully if so.? Seems like this is happening with no viewport so we're still using 481.

-[Unknown]

[iota97]

Seem to fix it

[tywald]

Hm, partially fixes it. I still notice some vibrations on like the main menu. Need to investigate further.

Hm, weird even if I revert the change on latest master it vibrates on like the language select in MHFU, but not if I run buildbot's v1.9.3-530
@iota97 can you check? maybe my build environment is a bit bugged since my PPSSPP_GIT_VERSION for example refuses to update properly and says v1.2.2-7325-gcfe6d26b4 even though I really am on latest master :P (I already have PPSSPP_GIT_VERSION_NO_UPDATE set to 0).

[unknownbrackets]

Use git fetch origin --tags to get the latest tags and update the version.

Hm. I know we also changed the shader parameters, but they didn't really make sense before...

-[Unknown]

[iota97]

Reverting the commit doesn't fix it, while moving it below does on master for me (tho' it's such a subtle flicker may just be reduced a bit and I can't notice it anymore).

I went back 500 commit to try to 9f694af and it flicker there too, I guess I either have never noticed or some driver update exposed it? I'm running NVIDIA driver 440.82 on Linux. Still pretty weird.

[tywald]

Thanks, tag fixed.

Ok so this is with v1.9.3-908 with the change reverted and it vibrated on the language select menu in MHFU at 2x window & (1:1) resolution, maximized the window and it stopped.

ppsspplog.zip

It seems this happens if Screen scaling filter is set to Nearest in addition of using a post-processing shader even on v1.9.3-530 now(had to look extremely close to notice it).

I'm gonna check on official v1.9.3 as I didn't notice it before but maybe it was as subtle as 530 was.

[iota97]

Also seem to happen on OpenGL only, is Vulkan fine for you as well? But it's happening in build I have played on way too much to have never notice it tbh.

[unknownbrackets]

Okay, either way I'm going to move those lines down. Seems like it should be better.

Does it log anything about 481x273 when you see the flicker?

-[Unknown]

[tywald]

For me it happens on all backends :/

But moving the lines do stop the vibration when you have loaded a character at least.

Yes it does mention here about 481x273:
ppsspplog.txt
I simply closed when the language menu popped up and this is 908 with the lines moved.

Currently this was done on DirectX 11

It still mentions about 481x273 even when you don't use a post-processing shader but it doesn't flicker.

Edit* I realized I didn't pay attention where I moved the lines, I accidentally had it above "If viewport wasn't valid..." comment instead, sorry. But good news on my end it did fix the flickering even on language menu and title screen on all backends.
Updated log where I properly moved the lines:
ppsspplog.zip

[iota97]

The only reference to it I get is this, but it's the same log on OpenGL (flicker) and Vulkan (fine).

40:19:646 user_main    I[FRAMEBUF]: Common/FramebufferCommon.cpp:452 Creating FBO for 04000000 : 480 x 272 x 1
I: GLQueueRunner.cpp:491: Creating 1920 x 1088 FBO using DEPTH24_STENCIL8 texture
I: GLQueueRunner.cpp:421: Creating 480 x 272 FBO using no depth
40:19:713 idle0        I[FRAMEBUF]: Common/FramebufferCommon.cpp:1064 Decimating FBO for 04044000 (480 x 272 x 1), age 6
40:19:713 idle0        I[FRAMEBUF]: Common/FramebufferCommon.cpp:1086 Decimating FBO for 04044000 (480 x 272 x 1), age 6
40:19:713 user_main    I[FRAMEBUF]: Common/FramebufferCommon.cpp:452 Creating FBO for 04044000 : 481 x 273 x 1
I: GLQueueRunner.cpp:491: Creating 1924 x 1092 FBO using DEPTH24_STENCIL8 texture

[unknownbrackets]

If you enable debug logging, it should say why it guessed 481. Maybe it's hitting this case if (avail_height < drawing_height && avail_height == region_height) {.

What if you change if (viewport_width != region_width) { to if (viewport_width != region_width && viewport_width > 4) {?

I don't think that's the case though... if you enable debug logging (not just info), it should show why it estimated 481 wide.

-[Unknown]

[tywald]

I made a mistake, edited my previous post regarding that.

[unknownbrackets]

Oh okay, well then we can say that changes fixes this issue. Great.

-[Unknown]

[iota97]

Nice to hear it was that. FWIW I can't seem to get any log level above Information on Linux (enabled the checkbox and changed the log level for all logging channel, am I missing something?).

[unknownbrackets]

I think #define MAX_LOGLEVEL INFO_LEVEL is set unless compiled in debug mode, on Windows, or with -DLOGGING=1.

-[Unknown]