Micro Stuttering/Frame Pacing issue

[BParks21]

NOTE: If you are experiencing this issue, it may have multiple causes. See this comment: https://github.com/hrydgard/ppsspp/issues/9736#issuecomment-509018634

---

Using any API there is in every game a micro stutter or frame pacing issue that occurs randomly. This may be exclusive to windows. I've tested windows 7-10 and many different systems with the same results. It is more prevalent using a monitor at 60hz. The issue is almost gone using a 120hz display. Currently that is the only way to resolve the issue in all my testing. The easiest way to test this is to play a game with complete 360 camera control stand in place and slowly spin the camera around. You will see random stutters or inconsistent frame pacing. This occurs with games running at full speed at all times, vsync on, and frame skipping off. I believe ppsspp is suffering from the same issue the PCSX2 team is trying to resolve here. https://github.com/PCSX2/pcsx2/issues/1437

It would be worth looking into. This is my biggest issue with ppsspp and is very noticeable and unpleasant imo. I've been trying to find a solution to this for years and it is driving me mad. I think the pcsx2 team has pinned it down though. Thanks for your time i really hope you guys look into this and hope it is resolved. I love ppsspp except for this :)

System Specs: Operating System: Windows 10 Pro 64-bit MOBO: Asus Maximus IX Code Processor/CPU: Intel(R) Core(TM) i7-7700k @5Ghz Video Card/GPU: MSI GTX 980 Memory/RAM: 32GB DDR4 @3000Mhz

[Aszarsha]

On my end OpenGL do indeed removes the stutterings (*) somewhat (**) but also prevents the unthrottling from functioning (***), which makes this workaround unusable since I use PPSSPP instead of real hardware exactly for the fast-forward/unthrottle functionality.

Running under Win 10 18362.10000 with Radeon Adrenalin 19.6.2 on an R9 280X.

(*) not micro, since it remains for a few seconds every 10 to 20 seconds (**) I haven't tested extensively (***) nothing happens as if the key was unmapped

[unknownbrackets]

I assume that means you have vsync on or forced. You may need to set FrameSkipUnthrottle to True to get any speed above vsync in that case.

-[Unknown]

[Aszarsha]

Sorry, I should have specified. Vsync is off in PPSSPP and forced off in the driver.

EDIT : Vsync was indeed off in the driver, but Triple Buffering was on. Disabling TB did enable the unthrottle, which I find surprising since I though that triple buffering was conditional on vsync (double buffering of the second back buffer).

[unknownbrackets]

Just to summarize things to try in general for everyone:

1. Try settings -> System -> Force real clock sync.

   This uses a spinloop for timing (click for detail.)

   Windows is stupidly incapable of making a thread sleep for less than 1ms, so normally we just live with it. This means that occasionally a frame may be longer (i.e. instead of 16.66 + 16.66 + 16.66, it'll be 16 + 17 + 16 or something.) This setting forces better timing.
   Tradeoff is worse battery life on laptops, etc.

2. Try settings -> System -> I/O timing method set to "Host".

   Exposes disk timing to the game (click for detail.)

   We normally stutter if disk access is slower than expected, to ensure the game play is the same every time (and ideally the same as on a PSP.) "Host" makes us just use whatever timing your actual system has. Even if you have a fast SSD, this can matter due to antivirus, OS caches, background processes, etc.
   Tradeoff is you might run into bugs if games expect fast timing, but usually they don't.

3. Check settings -> Tools -> Developer tools -> Log dropped frame statistics.

   You'll have to show the logs (Debug -> Log console) to see (click for detail.)

   If you have texture scaling, texture replacements, or other settings you might be dropping frames. This won't always show up in the speed % or FPS display because it's an average.
   Leave the log open and play for a while, then check the log. If it has any dropped frames, it will log statistics about the dropped frame. It could mean shader compilation, too high graphics settings, texture upload, etc.

4. Disable vsync, even if this sounds like crazy advice.

   PSP games are NTSC unlike PC games (click for detail.)

   PSP games don't run at 60 frames per second, but rather 60 frames every 1.001 seconds. It's a small difference but that 0.001 adds up and can cause stutter every now and then. PSP games also generally all double buffer internally (there are only a few that don't.)
   Don't forget to check driver settings. Sometimes it forces vsync. You may also want to try vsync on.

5. Try changing settings -> Graphics -> Upscale level to off.

   Texture scaling currently runs on the CPU (click for detail.)

   We already have to limit the textures we scale per frame to make it playable (unfortunately this causes pop-in), but it's still generally expensive. It's a likely cause of any stutter if you have it on.

6. Make sure unthrottle increases the speed substantially.

   On any modern PC, you should get 500%, easy (click for detail.)

   If unthrottle only takes you to 200% or something less than 500%, there may be settings or game-specific bugs limiting performance. This might easily stutter at times when throttled, since there are spikes in what the game needs.

7. Try using the "render duplicate frames" option in latest git builds.

   This forces PPSSPP to send 60 FPS to the driver, even if the game is 30 FPS.

   Most games on the PSP render only at 29.97 FPS, and some people have experienced issues only in these games. Forcing 60 FPS output has helped those people.

-[Unknown]

[Aszarsha]

The (not so micro) stuttering is present with all backends but OpenGL. Everything that you specified was already at that state (real clock sync, host timing, vsync off, no upscale). Unthrottling goes to crazy speed (uncontrollable speed basically, but useful for jrpg to solve whole combat in about 1 second).

In my case I play mostly sprites based games at 1x resolution, so it is most probably not a throughput issue but a frame timing one, that somehow the OpenGL driver solves internally with and without vsync.

I'm currently running build g8940a9d9f, and I can happily make more tests.

[OCRBonk]

The solution that works for me in W7 , rather than repost what I wrote, just link to it. https://github.com/PCSX2/pcsx2/issues/2307#issuecomment-517850448 Scanline Sync gets me perfect 99% stutter free vsync with PPSSPP standalone. From what I remember in Windows 10 vsync would have to be disabled and IIRC I think maybe only it worked with Vulkan or OGL maybe? I can't remember. Because I think in DX9/11 the compositor takes over no matter what. Don't quote me on that though and I may remember wrong.

[BParks21]

I would like to note that this issue is worse in the libretro core. But if you set vsync swap interval to 2 in Retroarch you get perfect frame pacing for 30 FPS games. 33.3ms which is what you want for a 30 FPS game. Without this on you get constant fluctuations from 34ms-40ms. The dolphin core and upstream dolphin also suffer from this when running 30FPS games at 60Hz. To bad setting the display at 30Hz through the OS introduces an enormous amount of input lag otherwise that would be the solution.

[BParks21]

@OCRBonk I can confirm that the methods you explained in the link work. Like you state though for games with mixed maxed framerates this is not really a solution. I would like to know how a lot of the cores in RA like beetle psx are able to achieve perfect frame pacing for 30fps games. For instance Legacy of Kain Soul Reaver is 30fps. I notice though that beetle psx sends out VPS to RTSS instead of the internal fps. So for 30fps games it reports 60fps even though the internal is 30fps. You can prove this because one of the core options sllows you to display the internal fps counter. Whatever the beetle psx core is doing for framepacing thats what needs to be done here haha.

[OCRBonk]

I can confirm that. I have played a few 30fps games in lr-beetlepsx without having to use any tricks for proper frame pscing. Just 1:1vsync.

[BParks21]

I'm referencing this issue which I've also opened for the dolphin libretro core. Just in case any findings are made everything is kind of connected. https://github.com/libretro/dolphin/issues/112

[hrydgard]

I think I might later revive something PPSSPP had in very early days - it outputted frames at 60hz no matter if the game ran at 30hz or not. This is of course only possible in buffered mode, but it should lead to much better frame pacing for 30hz games.

[BParks21]

Ok perhaps that will work. I thought i saw somewhere you added EFS mode to the 1.9 milestones?

[LunaMoo]

In case you didn't saw, exclusive fullscreen is in the 1.10 milestone. However similary to many other constantly pushed things that matter only to a small fraction of userbase(which is the case for many of such issues and requests), imo it should simply be pushed to "future" milestone to give more incentive for others to do some work instead of false hope.

[Nomadsx]

It's great this hasn't gone ignored or forgotten. I've also had this same issue for years with ppsspp. Mine will microstutter every 15 seconds before going back to smooth scrolling again at 60hz. The 59hz bandaid fix works okay for a bit until everything desyncs and stutters hard before it fixes itself. Would love for this issue to be resolved fully as it was for PCSX2 and Dolphin.

[BParks21]

I still get pacing issues in Dolphin. But i have been dealing with this for years as well ;(

[Nomadsx]

Really? I don't want to derail this into a Dolphin talk but I fixed mine by simply switching over to Vulkan. I recall hoping that'd fix it in ppsspp too when Vulkan was added but the microstutter problem is the same with all rendering choices.

[BParks21]

I've tested vulkan i get the same result. Less frequent than ppsspp. It takes longer to trigger too. Really bad with Luigi's Mansion though.

[BParks21]

@hrydgard Some progress to further understanding the issue may have been made? https://github.com/PCSX2/pcsx2/issues/2307#issuecomment-531557886

[BParks21]

@hrydgard The Dolphin team have recently implemented what is called "present duplicate frames" to mainstream dolphin development builds. I can confirm that this method fixes the frame pacing related stutter in 30 fps games. Maybe the same thing can be done in PPSSPP? https://github.com/dolphin-emu/dolphin/pull/8554

[mirh]

Skipping frames even though there are zero guarantees about the next one seems a really poor idea. And honestly, it sounds like complicating your life for next to no gains (maybe to save energy on laptops.. but at that point I could as well don't care about vsync) Probably only a well funded emulator like dolphin (which is using as new apis as possible) could go that down the rabbit hole of optimization. /s Or, I dunno ppsspp.

Still, this is something that everybody would see in the same conditions (or well, at least if having a slow pc also is included)

Instead, I'm not sure if you understand that this is some wicked interplay of drivers, apis and vsync (or well, at least this is my impression, after thinking to what you have seen in pcsx2 too). https://github.com/hrydgard/ppsspp/commit/49fb0bd65b97c9bd6beabc7dfdb33eccafc25ecb I see here the right flag is being used.. But I'm wondering if the rendering surface, client window and display size areas are all matching? (as having a fit-to-screen image made a huge difference in pcsx2)

[LunaMoo]

I think I already wrote that, but maybe it was different just similar issue - on most common HD resolutions, PPSSPP cuts off a pixel from top and a pixel from the bottom to provide 1:1 unstretched image, this can be changed in display layout editor by using stretching instead of scaling or by using skipping buffer effects, but that's buggy and awful hack.

I never was able to reproduce this whole issue, despite from somewhat long time using Nvidia gpu. Althrough I do upgraded to adaptive sync display after switching to modern GPU and have no use for vsync whatsoever.

[OCRBonk]

It would be nice to not have to force 1/2 Refresh vsync (and the input lag penalty that incurs) in the OGL backend, or use Scanline Sync (Works with the other backends for Vsync with a borderless window)with PPSSPP's frame limiter disabled (And the problems that comes with in games like Brandish where when switching rooms the SS limiter breaks and the audio is sped up for several frames and then returns to normal once the next room is loaded) to be able to get proper 30hz frame pacing on 30FPS games (Which I would say are the majority of PSP games. If not 20hz).

Using the Libretro core, similarly you have to use 1/2 rate vsync which subjectively feels like there ends up being more latency with that setup even with frame delay at 15 compared to standalone.

[unknownbrackets]

That's basically what was already suggested earlier:

I think I might later revive something PPSSPP had in very early days - it outputted frames at 60hz no matter if the game ran at 30hz or not. This is of course only possible in buffered mode, but it should lead to much better frame pacing for 30hz games.

It might help. Personally, I think it'd make sense to do when the "Force real clock sync" (lagsync) setting is enabled, since they make sense in basically the same situations.

I should mention: if you have this setting off, you today would have the 1/2 vsync input lag penalty mentioned (or worse.) But if you have this setting on, then irregardless you should not have that specific penalty (it keeps game time aligned with real time at 2ms intervals, so in theory that should be the max input lag penalty, outside hardware/drivers etc.)

There is a separate possible penalty, because we queue up frames to render through the OS graphics driver. This can currently cause up to 3 frames of lag (so longer if at 30 FPS.) Not sure if the same setting would ideally control that too, but maybe. I can imagine situations where you want the sync, but still want the queue (like netplay), so not sure. Also, if your graphics driver is fast enough, I think we would not have that lag, so it may not be a problem on more powerful systems.

-[Unknown]

[LunaMoo]

I forgot about this, but does my post process workaround helps with this issue as well? I posted it here, it basically does the 60hz output doesn't matter on the game's FPS. It's just an empty shader with 60fps flag, the flag can be added to any other post process shader ofc.

[unknownbrackets]

Yes, I think that should also cut the lag to one 60 FPS frame without "Force real clock sync". But it won't affect the separate queue penalty I mentioned.

-[Unknown]

[OCRBonk]

Using that post process shader actually works almost perfect (In the backends you can use shaders in). The frame times that are reported at 60hz are kind of wildly uneven. (You can clean it up with an external 60hz limit on top)But the frame pacing for 30hz games is basically perfect with none of the pacing errors and stuttering that it otherwise has when playing 30hz games with 60hz vsync. An easy test to see this is Metal Gear Ac!D on the first map. Hit Triangle and you can pan all over the map to easily see frame pacing stutter.

Now if only you could use Shaders in the DX9 renderer. (Only reason I care is because DX9 is the only way to get better Anti Aliasing with buffered rendering https://imgsli.com/MTEyNDY/).

I did discover something Very strange however. I had the frame pacing shader selected and enabled in OpenGL. Then switched to DX9 to test something with Metal Gear Acid, and it acts like the shader is still working. As the game was reporting 60FPS. Enabling Scanline Sync 1x (Not X/2)with the PPSSPP frame limiter disabled, synced everything properly with correct 30hz frame pacing and no stutter. Loaded up Brandish and it reported 30FPS properly. And Thus enabling scanline sync 1x and disabling the limiter made the game run at 60FPS and double speed when Scanline Sync was enabled.

Switched back to OGL, removed the shader. Switched back to DX9, ran Metal Gear Acid again. And now it reported 30FPS like normal and enabling Scanline Sync 1x with limiter disabled and the game ran at double speed like it normally would with 60hz scanline sync.

And checking this with other games. I can confirm enabling the frame pacing shader in OGL and then switching the backend to DX9 works with other games to get perfect frame pacing with 60hz Scanline Sync. Even in mixed framerate games! Works with Metal Gear Portable Ops (With 30FPS cheat) Metal Gear Acid 2 Breath of Fire 3 Dead Head Fred Castlevania X Ultimate Ghost's and Goblins Parappa the rapper Star Ocean First Departure (60hz in town. 30hz in 3D segments like battle.)

Does not work with Brandish Tales of The World Radiant Mythology ( A mixed framerate game.)

These are just a few of the games I own that I can test. https://www.mediafire.com/file/dwu2is1ldcin1pt/PSP_30hz_shader.7z/file Here's an archive with 2 videos I recorded with OBS (Which captures the audio weird so it sounds like shit)at 60hz with an overlay displaying the framerate and it working with Star Ocean FD. You can see me switching the PPSSPP frame limiter on and off in each. (So you can see Scanline Sync activating. It doesn't work without the limiter disabled in PPSSPP)

Can anyone explain why the shader would still be working in DX9 mode if left enabled in OGL before switching??? I mean the intended effect is exactly what is needed. But shouldn't it not work?

[mirh]

But it won't affect the separate queue penalty I mentioned.

Windows 10 has a fuckton of voodoo to optimize that, including automatically upgrading some applications to the flip model. Also, drivers themselves have fullscreen hacks that can turn you to exclusive mode even if you didn't ask for it.

But last and not least, just for the records, input lag would not be stuttering.

[LunaMoo]

About the workaround affecting games when switching to d3d9 ~ the post process shader is NOT the workaround, the workaround is the 60fps flag set to that shader and it probably still get's checked despite not being able to run shader because d3d9 backend is just meh, it's supported mostly as a legacy option for very old / bottom end hardware and it does share a lot of the code with backends that can use post process shaders.

I would consider this an unnoticed bug which fixing might be delayed if it helps currently. The shader I prepared is more of a clean test without actual effects potentially obfuscating problems and a temporary workaround since the flag is not all positive, we have an issue about it causing problems when paired with unthrottle on Linux/android and it might actually need more work for the sake of those platforms:].

As for AA ~ if I want a good, but expensive AA, instead of enforcing some driver hacks I'd rather just use SSAA post process or a different more complex post process with SSAA flag, eventually set to a higher value(by default it's just x2 which leaves some aliasing, but the upper limit would be whatever your gpu can handle even far beyond PPSSPP render resolution settings assuming modern higher end desktop gpu's). PPSSPP post process can do some unique and not that well advertised things, but most people just don't care, PSP games will never look as good as modern titles anyway because there are tons of details that make a graphics nice in modern standards and PSP games just can't get that at least not from technical standpoint, artistically it's a whole different thing.

[OCRBonk]

Is possible to maybe make this an option hidden in like the developers menu instead? Or is there something else that can be done alternatively? Because at least as far as I can tell. In the games it works in, it works extremely well so far. And makes mixed framerate games playable without stutter when they switch to 30hz. And you can play 30hz only games without the input lag penalty incurred by having to use 1/2 refresh vsync in OpenGL. With the same being true in DX9/11 if there was FSE. (Stinks it doesn't work in every mixed framerate game. But can't really complain about that).

As for AA, the existing resolution scaling can only do so much. After a certain threshold the resolve filter here just can't handle an input higher than 4x (2x2) your current display resolution without breaking and ending up doing the opposite of what AA should do. Doing a 2 step resolve (Ala GeDoSaTo) results in a large improvement all around. https://imgsli.com/MTEyODc

But even if it could handle it, just brute force OGSSAA (Downsampling/Resolution Scale) with a basic resolve can't handle temporal aliasing as well compared to SGSSAA. (Which piggybacks off of MSAA.) And getting good AA is really just about getting the image to look as close to a ground truth render as possible. Getting rid of all the problems caused by 1x or less sampling. It won't stop it ultimately from looking like what it is. (A PSP game) But the image quality benefit that makes it look as if it was rendered offline is huge. All 3D rendering benefits from better image quality, even simplistic systems like the PS1.

To show this, here's 3 videos because temporal aliasing problems can't effectively be shown in a still image. (Sorry for low quality encodes. But it's good enough to showcase the broader point) https://www.mediafire.com/file/a9rhix8i9myhtba/PPSSPP_AA_comparison.7z/file No AA (4x res, 1920x1088) 8xSGSSAA (Forced with a compatibility flag through the Nvidia Driver) 10x res (4800x2720) with 2 stage downsampling.

If you can come up with some kind of solution that is better than what is implemented now,available to all users that comes comparably closer to SGSSAA. Then i'm all for it. Anti Aliasing is often just an afterthought when it comes to real time rendering. (Fast AA has always been more important than high quality AA. Often leading to poor image quality.)

Edit: I was not aware of the SuperSampling shader before. It's actually pretty good. Not as good as SGSSAA but I never bothered trying it before because I always assumed it was just another basic Post Process AA solution that ends up looking like nothing more than a low pass filter. I was wrong. Is it just using a Gaussian function for resolve instead of a standard linear/box and that's it?

[BParks21]

I think frame duplication is the best way to go tbh. Or at least make it optional like Dolphin now does.

[BParks21]

Could this also be added to the libretro core when implemented? It needs it as well.

[LunaMoo]

@OCRBonk SSAA is both a shader flag and an example effect that's using a simple Gauss filter. That example post process has SSAA x2, but with gaming GPU you can easily use x4 and it's much nicer then for use on 1080p standard althrough too slow for bottom end hardware so at least an average gaming gpu might be required. Just edit defaultshaders.ini under ppsspp\assets\shaders and change SSAA=2 to SSAA=4 or create new ini file(name doesn't really matter since PPSSPP searches through that folder) in shaders folder and place this inside:

[SSAA(Gauss)x4]
Name=Super Sampling AA(Gauss) x4
Fragment=GaussianDownscale.fsh
Vertex=fxaa.vsh
OutputResolution=False
SSAA=4

I would say x4 SSAA is optimal for 1080p, but the higher PPI your display is, the LESS AA effect you need. Overall AA is NOT a quality setting and the only trully "quality" AA form is a display of enough pixel density(NOT resolution) to make it impossible to see in the first place, 4k that is slowly becoming standard in gaming monitors is almost there, but might still need some cheap AA depending on the actual PPI.

Your examples are enforcing nearest texture filtering in PPSSPP, this is NOT how the games were designed to look or run, it does introduce a lot of texture shimmering which looking at your examples is also the thing you seem to want to get rid of the most, not geometry aliasing which is minimal and only seen on the no AA example, so it's kind of like you're shooting yourself in the foot and create problems to later seek solutions for.

Either way geometry aliasing nor texture shimmering is the topic of this issue, so if you're into that better to discuss solutions on that in the forums instead of adding it to every of your post in different issues on issue tracker where you can mention why you're into D3D9. Or if you have a specific request about it open a new issue about it, just don't request D3D9 backend to be as compatible as modern ones or other impossible things like that.

Personally I dislike graphic driver hacks and enforcing graphic driver settings on apps. Even through I currently have an Nvidia gpu, I never heard about SGSSAA before and I'll likely never use it myself unless I see an option for it in some PC game without having to use nvidia contol panel.

[hrydgard]

I think I'm just gonna add a setting for this, there's not much new code needed. Yes we could add it as a byproduct of Accurate Frame Timing, but I can see the case for having it separate, too.

So what do we call it? "30Hz Frame Duplication" is not easy to understand for someone not an expert in these things. "Smooth 30Hz Frame Timing" is not much better, neither is just "Frame Duplication" on its own without a number. Ideas?

[mirh]

"Render sleep" or something along that? Isn't that the gist, rather than just duplicating frames for its own sake?

[unknownbrackets]

"Duplicate frames to 60 FPS"? Hm. At least, I think "Render duplicate frames" is better than "Frame duplication".

-[Unknown]

[LunaMoo]

What about #12325? The setting when active will break post process effects use with unthrottle on android/Linux?

About the name, anything as long as it doesn't mention 30hz, since it works for all ranges, duplicating it up to 60, not just for 30. Could also have a tip explaining what it can help with or even be named "frame pacing improvement" as where it can help is probably clearer than what it actually does.

[BParks21]

Render duplicate frames doesn't sound bad.

[hrydgard]

Yeah fixing #12325 might be a good idea to do first...

[OCRBonk]

@OCRBonk

Personally I dislike graphic driver hacks and enforcing graphic driver settings on apps. Even through I currently have an Nvidia gpu, I never heard about SGSSAA before and I'll likely never use it myself unless I see an option for it in some PC game without having to use nvidia contol panel.

Higher pixel density doesn't automagically make aliasing go away. (Maybe at extreme PPI we might see most of it become almost invisible. But on current 400+PPI screens like mobile phones I can still easily see all kinds of aliasing in motion.)Least of all temporally which is the biggest aliasing issue. Aliasing over time in motion. Current solutions to this problem are mostly poor that introduce artifacts into the image that didn't previously exist. There are exceptions to this. But most TAA requires real SSAA on top to make it look good and mask the problems they introduce. (Ghosting, smearing, temporal breakup,flickering, clamping errors,incomplete resolves). Ray tracing with the need for denoising compounds the problems introduced by TAA. (See: Quake 2 RTX, which looks and runs like hot garbage in terms of image quality. You can add 4x Supersampling on top, which will mask some of the issues but not make them disappear. But then the game runs at about 20-25FPS on a 2080)

Also: Using nearest texture filtering is strictly done to asses the raw quality of the AA technique and how it can tackle something that is commonly a problem in a modern renderer. (Plus there are instances where I would intentionally use point because some games look subjectively awful with linear filtering due to the low res sources.) Texture aliasing and texture temporal aliasing. Whether due to poor mipmap rendering,excessive high frequency information present in textures, a negative texture lod bias (Final Fantasy XIV ARR for example) just to name a few. While the problem won't be as severe using linear texture filtering in PPSSPP. The problem exists just as it does in the majority of real time rendered games.
And FWIW, texture aliasing is still a problem in all backends except OpenGL. DX9,11 and Vulkan all have the same texture aliasing problems with Linear Filtering as with Point Filtering. This results in more severe temporal texture flickering. (With the only option to fix it is by forcing AA in DX9. Or playing in OpenGL. ) https://imgsli.com/MTE0Njc

The Gaussian sampling SS shader works well up to 4x, it still does not solve all aliasing problems. But for most scenarios it is more than great enough. So thank you for pointing this out to me(And on a high end GPU barely takes up any GPU usage at all). After 4x, 2 stage resampling is required however. 2 stage resampling with the Gaussian sampler looks pretty fantastic though and solves the majority of aliasing with only a few edge cases remaining.

SGSSAA has been around for almost a decade now (First introduced with Fermi), and is by far the highest quality hardware based Anti Aliasing solution that has been available to an end user on PCs or Consoles. (It isn't perfect mind you. But combined with other AA methods you can get essentially perfect pixel quality)It is a driver hack that is for sure, but with the right compatibility flag and other minor adjustments on a per game basis ensures that when it works, it works entirely without any issues.(Performance requirements not withstanding depending on the GPU and the performance level you want to target). I've been maintaining a list of hundreds of games compatible with this for about 5+ years now. https://www.pcgamingwiki.com/wiki/List_of_anti-aliasing_compatibility_flags_for_Nvidia currently up to 600+ entries (with some duplicates). This brings hardware AA support to a huge number of games that don't have any AA at all or very poor AA. (And not just SGSSAA, but other methods like Transparency Supersampling for alpha test objects, standard OGSSAA and also MSAA)

And I have an old video showing a quintessential example of modern aliasing problems with no AA or only basic post process AA vs being able to add hardware SGSSAA instead if you are interested in seeing the same problems in a modern game. (Old recording at 720p with poor encoding. But represents a real world scenario for me from 5 years ago, I could play the game at 768p on a 768p TV at 60FPS with 4x SGSSAA and have almost perfect image quality. Or I could play the game on a 1080p monitor with only the built in FXAA with the same framerate and it would look significantly worse. Pixel Quality > Pixel Quantity) http://www.mediafire.com/file/8o36djz5fe7yj55/FFXIV_AA.7z/file

I won't say more further. Sorry to bring anything off topic.

I honestly don't care if the DX9 back end is maintained or not. But again the more important thing is having an option to render duplicate frames without that shader test to get proper 30hz frame pacing on a 60hz output (And still be able to use other shaders at the same time without editing files) Or something to achieve the same effect would be a worthwhile option for those people who can actually see the issue. (And just because a bunch of people don't notice it, doesn't mean it doesn't exist either). I can see the issue in multiple backends on Windows and on Android.

I appreciate all the work you guys do on this stuff, really honestly incredible work to do this at all. Don't take anything with negative connotations.

I'm glad there is a semi-working solution now that I am aware of with that shader(Thanks again).

[hrydgard]

There's definitely a lot more that can be done to improve image quality on high-end hardware. PPSSPP has always had a focus on making the low-end run fast first but there will probably be improvements here in the future. The recent VK extension VK_KHR_depth_stencil_resolve, now standardized in VK 1.2, opens the possibility for MSAA to run efficiently in PPSSPP too in the future (though that will be quite a bit of work).

[ghost]

Issue #12614 that got closed said its only relevant for Nvidia GPUs but I got a laptop with both an AMD GPU and Intel GPU that got this issue as well. I tried On my Android TV box using the OpenGL ES renderer and I could not notice any FPS issues and the game worked flawslessly there. I got this issue both on Linux and Windows but i will need to try it again on Linux to be sure. It could be a different issue i am experiencing here but I am not sure. EDIT: the issue is not on Linux so this is a Windows only issue for now.

[LunaMoo]

It doesn't have to be limited to Nvidia, it's just that everyone affected until now used it, but also many people using Nvidia gpu's were NOT affected at all. Portion of that issue also happens to affect at least some android users.

Overall with a modern variable refresh rate display you should not have any issues nor would want to use a software workarounds like vsync, but the older/cheaper fixed refresh rate displays might be a huge variable possibly depending on the operating system and drivers as well and likely why the experience between users still using such displays varies too much to be limited just to human perception.

Either way, the issue can be easily improved by duplicating frames of the lower fps games and possibly it will be a feature of the next release version, but first a different bug with it's interaction with frameskipping has to be fixed, until then you can use any post process effect(any) with 60fps flag activated(you can edit shaders .ini file and place "60fps=True" under the one you like) and if you don't like post process effects, you can use my empty one from here - https://github.com/hrydgard/ppsspp/issues/12460#issuecomment-549103933.

Quickest way to test whenever the future solution solves your problem without editing, downloading or building anything is to use the default "CRT scanlines" post process effect as it does include the frame duplication as a feature to keep animated effect running at constant speed.

[ghost]

Seems like I got a different issue - neither the CRT scanlines shader helps or the "60fps=True" thing with another post processing shader helps. I will open an issue about this later on. Seems like its really a Windows issue (specifically Win10) only for me because other OS and Android TV do not have this problem. OK it's a Vulkan + DX11 issue on Windows...

[JetSetter1984]

Hey, just had my issue #12614 closed as this issue is a duplicate, sorry for not noticing this one first. Thanks for the fix attempt LunaMoo, tried it and made no difference, but thank you anyway. Unless playing competitive games, I use my 50" 4k HDR Panasonic TV @60Hz as I love the bigger screen and no syncing issues in anything else. Just confused as to why for me DX9 completely eliminates the issue windowed or fullscreen and OpenGL only fullscreen is fine too... Strange. Is there any possibility of looking at how DX9 syncs as opposed to the other backends? Maybe using the DX9 method of syncing would help. Thanks again.

[ghost]

Info from the issue I closed. When playing the game Shin Budokai 2 the game will exhibit stutters and micro-stutters while using the DX11 and Vulkan renderers on Windows 10 (while the game still reports 60 fps). The issue does not occur or might not be noticeable on Android TV with the OpenGL ES renderer and on Linux with the Vulkan renderer (unlike Win10). I did notice that the micro stutters begins to occur when aura effects appear in battle. You could see the issue here in this video if you pay attention : https://www.youtube.com/watch?v=fFeLVH8nndo The issue is not solved by using post processing shaders with 60 fps on in the ini file or by using the CRT shader.

What hardware, operating system, and PPSSPP version? On desktop, GPU matters for graphical issues. OS: Windows 10 (Linux and Android TV used for testing) GPU: Radeon 530/Intel UHD 630 CPU : i7 8550U PPSSPP 1.9.3.

[JetSetter1984]

So I recently installed RetroArch to play one of my 16-bit RPGs on my flatscreen without looking awful, and thought to give PPSSPP a try within RetroArch. To my surprise it seems that Vulkan will not load within RetroArch on any game, DX11 crashes on Ridge Racer 2 but works on most titles and OpenGL is fine. Anyways, in RetroArch PPSSPP runs perfectly in window or fullscreen on DX11 or OpenGL with no stutters whatsoever! Smooth as silk. This must be because of RetroArch detecting a refresh rate indepently of the emulator or because of it's DWM implementation. Either way it completely solves the issues mentioned in this section, but you lose vulkan support.

[unknownbrackets]

For those experiencing this issue and using the latest git builds, I'm curious what you see when you enable the frame time graph.

You can enable this by going to: Settings -> Tools -> Developer tools -> Check "Show developer menu" Then during the game, click "DevMenu" in the top left, and check "Draw frametimes graph" (last item, scroll down)

Normally, mine looks like this:

You'll see this isn't very even. The transparent green indicates frame sleep (basically, outside emulation, just waiting for vsync/next frame/etc.) and is of course very uneven, but that's normal.

If I enable "force real clock sync" it of course becomes more stable: (it actually evened out the emulation time too, probably by reducing waiting times.)

For me, vsync makes no difference - the graphs look the same. I'm curious if this is the same, or different, for people experiencing this issue. Do you see drops or jumps in the graph when you experience the stutter, or does the graph indicate that it's still even? Does real clock sync change your graph or the stutter's effect on it?

-[Unknown]

[JetSetter1984]

Just did a quick capture of the frame times. 1st Image is without real clock sync, second with. I still experience the issue with both options. Only Retroarch version is stable frametimes for me.

[unknownbrackets]

Did the stutter correlate with any of the spikes in the opaque green? Or did it happen with no apparent correlation to the graph whatsoever?

-[Unknown]

[eleriaqueen]

Hello, for me stutter doesn't seem to have any correlation to the graph (using Vulkan with Force Real Clock, Fullscreen, Maximum Performance / No Throttle GPU mode, High Performance Win10 Power Plan).

The only spike I saw is when I took the screenshot.

This test was done using driver 442.19, on Phantasy Star Portable 2 (USA, 30 FPS game)) with 60FPS cheat code.

Is what I'm experiencing caused by PSP clock speed not matching screen refresh ? (I tried using 59 FPS screen mode to no avail)

OpenGL on the other hand, with the NVidia 1660 TI graphics card, seems to have less consistent performance but far less stutter overall, though I do get a "Sound is choppy..." message from time to time (only on OGL backend).