[FR] Sync to host refresh rate to prevent micro-stuttering

[vanfanel]

What should happen

PPSSPP could have an "sync to host refresh" option that could set the games framerate match the host system refresh rate, thus providing smooth movement.

Currently without this option, games show small hiccups once in a while because of the mismatch between the emulated system framerate and the host refresh rate. (For example, if physical video mode is 60.002 Hz and the emulated PSP is 59.94 FPS, the hiccups appear once in a while even if they are close enough. They must be exactly the same, and the easiest way to do it is force emulation to run at EXACTLY the host's refresh rate).

Other emulators, like DuckStation, already have this feature and it works perfectly well.

Who would this benefit

Everyone who can tell smooth and continuous movement on PPSSPP standalone is not perfect.

Platform (if relevant)

No response

Games this would be useful in

Every game with smooth near-60FPS movement, like Ridge Racers for example.

Other emulators or software with a similar feature

DuckStation, which also has a direct KMS/DRM graphics interface.

Checklist

• [X] Check the latest git build in case it's already implemented.
• [X] Search for other requests of the same feature.

[ghost]

This is not the same as Render Duplicate Frames to 60hz? https://github.com/hrydgard/ppsspp/commit/d3850965993c521c09362f140f02067d8de19aed

[vanfanel]

This is not the same as Render Duplicate Frames to 60hz? d385096

No. If you produce 59.54 frames per second, it can't look right on a 60.002Hz video mode. No matter how many frames do you repeat. In fact, repeating frames (ie: you have nothing new to show in an smooth update sequence) causes a stutter to begin with.

[ghost]

Can you try this? 👉 https://github.com/hrydgard/ppsspp/issues/9736#issuecomment-509018634

[hrydgard]

Nah I don't think those options are useful for this.

For 60fps games on a 60hz monitor, just using vsync (in vulkan, FIFO-mode present) should be enough, we'll automatically end up compensating by stretching the audio. The problem is with 30fps games on 60hz displays, or other combinations, where we currently do not have a way to enforce displaying exactly the desired frame rate, instead there will be minor stutters occasionally when the timing "catches up".

Also, currently on Android with Vulkan, we use MAILBOX instead of FIFO mode, subverting the above. This is going to be fixed.

There are upcoming Vulkan extensions that will make exact 30fps display possible. In fact there's already an Android specific extension, but it's a tricky one to use.

[ghost]

There are upcoming Vulkan extensions that will make exact 30fps display possible. In fact there's already an Android specific extension, but it's a tricky one to use.

Just like this? https://developer.android.com/games/sdk/frame-pacing/vulkan/add-functions

[hrydgard]

That's right, there's a utility library called Swappy that uses it, I'm not sure if it's directly applicable by PPSSPP, it might be.

[vanfanel]

@hrydgard So this will be fixed on Vulkan, but what about GLES? The Raspberry Pi 4 for example has fantastic performance for PPSSPP on GLES, it's a real pitty that those micro-stutters are there for a framerate discrepancy.

[LunaMoo]

You can do what some awful frontend does and just run PPSSPP unthrottled and limit frames externally to exactly whatever you desire, you'd still might want to use duplicate frames to 60 option through, in 30 fps games it'll still flip twice as many times which would mean shorter time between each, if you'd get some stutter, it should reduce it to half making it less noticeable.

Personally I'd recommend to just switch to more modern/gaming hardware which RP definitely isn't and never will be. It got popular among emulation casuals due to emulators of older/easier to emulate consoles and ability to make cheap DIY handhelds from. PSP emulation is for the most part very light which might give you false impression that RPi is good enough for it, but not really all that easy to emulate many of it's weird effects which on Pi(to be exact on it's gpu) will either not work at all or perform horribly forcing you to disable those effects or even not being able to play some harder to emulate titles. With any even very low end, but modern gaming pc you would have a display with 1ms response time and VRR between 40 to 75 Hz and a gpu supporting it as well as way better support of most graphic api's extensions, which means less glitches, no tearing, no stutter and no side effects of running games at incorrect speed(like different input timings or broken multiplayer compatibility to name some that could be more annoying).

[vanfanel]

You can do what some awful frontend does and just run PPSSPP unthrottled and limit frames externally to exactly whatever you desire.

Sounds good, but how am I supposed to limit frames externally to exactly the monitor refresh rate, which is what I desire? I guess that to unthrottle PPSSPP I have to disable VSYNC...

[LunaMoo]

Dunno if there's anything alike for Pi, but you shouldn't really need vsync, if your output would be exactly same as the display refresh rate.

If I recall Vsync in PPSSPP was actually working like that on windows at some point that is it did limit max framerate to display refresh rate, so if you'd unthrottle without frameskip and with vsync you'd already got what you wanted, but that was long time ago, I force disable vsync in everything since I got my first VRR display.

[hrydgard]

I actually think Rasp 4 with Vulkan is quite a fun/interesting target for PPSSPP and if I just had more time I'd work on optimizing for it. It should be capable of running a lot of games quite well. Although before I find the time, it'll probably be outdated :)

[vanfanel]

@hrydgard Even with GLES2, the Pi4 runs a lot of games VERY well: Ridge Racers is rock-solid 60FPS, zero audio or video problems in buffered mode with original PSP internal resolution. So, even if you don't find that time, the Pi4 is interesting for PPSSPP with the GLES renderer as things are now.

The only thing lacking is proper framerate synchronizarion with the host refresh, as I said.

[unknownbrackets]

Well, the VideoCore 6 I think can't handle NAN/cull range, etc. and I think we've seen some other bugs.

Surely there are many games that can run at great speeds and render great, but there are also some games that will simply never be able to run at full speed on that device without artifacts. Not saying it's bad, or necessarily worse than a lot of other mobile devices. But if a PC is an option, I'd definitely pick the PC. Not basically as good.

-[Unknown]

[vanfanel]

@unknownbrackets You are right, but the problem I describe in this issue (lack of sync to host refresh rate) affects any platform, not only the Pi4.

[BParks21]

@unknownbrackets You are right, but the problem I describe in this issue (lack of sync to host refresh rate) affects any platform, not only the Pi4.

@vanfanel You're right about it affecting other platforms! Duplicate frames does work well though for "visually" smoothing things regardless of the numbers you see. I suggested to Exzap (developer of Cemu) implement duplicate frames because it also suffered from 30fps inconsistent frame pacing which lead to visible stutter. He implemented something labeled Match Emulated Display. It only works for Vulkan as of now but he said it will eventually be added to OpenGL. It works well and it solved the 30fps frame pacing stutter with Cemu, for Vulkan at least. I think it might be what your describing but I could be wrong. Read the changelog here when it was added. He gives a good description. http://cemu.info/changelog/cemu_1_22_7.txt

Even the Dolphin team fairly recently implemented duplicate frames to visually smooth frame pacing for 30fps games. 60fps games already had smooth frame pacing just like PPSSPP here. It's well documented and it did indeed fix the visual stutters hiccups I know that you can see. Read this below. https://dolphin-emu.org/blog/2020/02/07/dolphin-progress-report-dec-2019-and-jan-2020/ https://github.com/dolphin-emu/dolphin/commit/a63510a55a25c7bd2777a18069de8497bef0d47b

[vanfanel]

@BParks21 Yes, Match Emulated Display should be implemented on PPSSPP too. That's what DuckStation implements. And what RetroArch does, too.

But I am not using PPSSPP anymore, lost interest after seeing the frame pacing issues it has and how small is the number of people who can tell.

[BParks21]

@BParks21 Yes, Match Emulated Display should be implemented on PPSSPP too. That's what DuckStation implements. And what RetroArch does, too.

But I am not using PPSSPP anymore, lost interest after seeing the frame pacing issues it has and how small is the number of people who can tell.

Have you tried duplicate frames though in PPSSP? With it on there are no micro stutters. It achieves the same result as match emulated display does, it eliminates 30fps micro stutters. It just achieves it a different way. I'm extremely sensitive to the frame pacing stuttering, but if you play on a 60hz screen and have it enabled it visually gets rid of it. The frame times still aren't perfect but I'm telling you you can't see any micro stutters with it on. For instance with the game Daxter. It's a 30 fps game but if you turn on duplicate frames a program like rivatuner it will report 60fps which is a natural result of the duplicate setting. However you'd expect to see a perfect 16.6/16.7 frame time in the graph but you instead get a 17.1/17.2 average. Regardless of this number there are no visual micro stutters. The method does do it's job. Emulators like Beetle PSX and Mupen64Plus-Next and Dolphin all use duplicate frames to solve the issue and it actually works. I'm not sure why you'd still be seeing micro stuttering if you're actually using the setting. Even in Cemu using Exzaps "Match Emulated Display mode" you don't get a perfect 33.3ms frame time reading from rivatuner on a 60hz monitor playing a 30fps game like Twilight Princess HD. Instead you get a similar result to frame duplication. You get about 1 more frame average. So i get about 34/33ms but visually it is actually smooth like the console. I implore you to test it. Visually it's smooth but according to the frame time it shouldn't be. I know it sounds weird but I assure you both methods work.

[ghost]

Dolphin sync to host refresh rate but get cancelled https://github.com/dolphin-emu/dolphin/pull/7803

[BParks21]

The sync host refresh rate has issues when run with g-sync while frame duplication doesn't. I prefer frame duplication method. Both methods run 30fps games without stutter. Thats likely why dolphin went with frame duplication instead, maybe?

[vanfanel]

I am not talking about 30FPS games: those of course don't move so smoothly. I am not interested in running 30FPS at 60FPS. I am OK with 30FPS games.

I am talking about ~60FPS games on ~60FPS displays. If the refresh rate on the emulated system does not exactly match the refresh rate of the host display, there will be small hiccups (very small), in fact there are in PPSSPP outside LibRetro. Take Ridge Racers, for example. It's totally smooth on real hardware (and so it is on the LibRetro port, provided one as a powerful enough machine to run that core).

The only possible way to avoid the hiccups is a "sync to refresh rate" setting.

I am not interested in expensive GSYNC/FREESYNC displays relying on closed source videodrivers or closer source GL/VK implementations. "Sync to host refresh rate" is a solution accessible to everybody, with every monitor and videocard combination. For me, it's that or nothing. No-one is forced to do it for me, of course. But if it's not for everyone, I am not interested.

[BParks21]

I am not talking about 30FPS games: those of course don't move so smoothly. I am not interested in running 30FPS at 60FPS. I am OK with 30FPS games.

I am talking about ~60FPS games on ~60FPS displays. If the refresh rate on the emulated system does not exactly match the refresh rate of the host display, there will be small hiccups (very small), in fact there are in PPSSPP outside LibRetro. Take Ridge Racers, for example. It's totally smooth on real hardware (and so it is on the LibRetro port, provided one as a powerful enough machine to run that core).

The only possible way to avoid the hiccups is a "sync to refresh rate" setting.

I am not interested in expensive GSYNC/FREESYNC displays relying on closed source videodrivers or closer source GL/VK implementations. "Sync to host refresh rate" is a solution accessible to everybody, with every monitor and videocard combination. For me, it's that or nothing. No-one is forced to do it for me, of course. But if it's not for everyone, I am not interested.

I see

[LunaMoo]

I am not interested in expensive GSYNC/FREESYNC displays relying on closed source videodrivers or closer source GL/VK implementations.

Gsync and freesync are completely different. Freesync is neither expensive nor closed source, it also became a standard which even Nvidia's supports starting from few years back which is what most "emulation enthusiasts" are using.

If this is still about Raspberry Pi, then a reminder that typical use case of those computing units doesn't even include outputting graphics whatsoever and gaming(outside of really old/simple stuff) on it will never come without issues or sacrifices.

If someone prefers libretro which cares more about quick solutions satisfying patreons than a proper emulation then it exists for them to do so, no reason for everything to work the same way, especially when it's the wrong way and the libretro to many of us is just a bunch of bad decisions slapped together. The literally only thing I envied that project was a post process shader support, but nowadays PPSSPP's post process shaders are more robust and have additional features found nowhere else, it maybe took more time, but in the end it's better.

[vanfanel]

@LunaMoo Ah! So you will pay me a Freesync-capable monitor then? I can give you my banking number, I'll be glad to enjoy it!

[kristianity77]

Hopefully something can happen regarding this issue. I've just received my odin pro (amazing device by the way) but it has a 61hz screen so ppsspp doesn't work nicely with it. I'm getting a one frame stutter, every second, like clockwork.

Having the emulator able to sync to screen refresh would completely solve this issue.

[hrydgard]

Yeah that sounds pretty painful, I have a plan to improve that.

Very strange choice to have a 61hz screen on an emulation focused device though!

[mirh]

You can add refresh rates with CRU, and even sporadically force support for freesync (which is also supported by the open source drivers on linux, so no lame proprietary excuses). It's also not unheard of monitors that already have "NTSC frequency" out of the box. If possible though, you should switch to the highest multiple of the refresh rate.

Stretching the emulation sounds awful instead.

[ghost]

The micro stuttering in 60fps games now using the latest build is very annoying :(

[vanfanel]

The micro stuttering in 60fps games now using the latest build is very annoying :(

I don't even care anymore about standalone PPSSPP. Use the Libretro core, it's stutter-free! :D

[JetSetter1984]

Nah I don't think those options are useful for this.

For 60fps games on a 60hz monitor, just using vsync (in vulkan, FIFO-mode present) should be enough, we'll automatically end up compensating by stretching the audio. The problem is with 30fps games on 60hz displays, or other combinations, where we currently do not have a way to enforce displaying exactly the desired frame rate, instead there will be minor stutters occasionally when the timing "catches up".

Also, currently on Android with Vulkan, we use MAILBOX instead of FIFO mode, subverting the above. This is going to be fixed.

There are upcoming Vulkan extensions that will make exact 30fps display possible. In fact there's already an Android specific extension, but it's a tricky one to use.

Sorry to drag up an old matter and thank you for creating such an awesome piece of software. I believe games output 59.94fps but my refresh rate is 60.002hz. My friend has a monitor with 59.89hz. All monitors are slightly different. They do not adhere to a standard so they just aim for 'close enough'. NVidia control panel will tell you 60 or 59.94hz, but if you use vsync tester online you will see this is not exactly true of almost all monitors or LCD/OLED TV's. This mismatch does cause intermittent stutter sometimes, usually at consistent intervals. I had this issue in PCSX2 and they have added a feature called 'sync to host refresh rate' which is seperate from the actual vsync toggle. Enabling both off them caused my games to run absolutely stutter free. This is because PCSX2 is now syncing to my exact refresh rate, not the 59.94 which was uniform for CRT TV's of that era. It is a game changer for any emulator going forward and my games are running without a hiccup now! I think trying to implement this in PPSSPP would be absolutely brilliant and solve this issue once and for all.

[unknownbrackets]

In theory, of course, this would make most rhythm games slightly harder as the game would run a bit faster (though much more or less depending on screen, as you correctly point out.) And if you used a 75 Hz display - that'd be like a 25% speed increase. I guess if the game wasn't designed with enough difficulty settings for you, you just need to buy a monitor with a high enough frame rate that isn't a clean multiple of 60.

Obviously speeding up graphics like this will mean needing to speed up sound output too, but that'd be automatic if we changed timing like that. I think the quest VR thing is already doing this, making games run 25% faster to avoid the motion sickness low FPS VR can induce.

-[Unknown]

[JetSetter1984]

If you have a 75 HZ monitor, you can always set it to 60Hz in windows, or have the sync to host refresh rate as an option to toggle. Regarding games speeding up and slowing down, if your monitor has a 60hz mode and I have never seen a modern one that does not, it will have a 'true' refresh rate within 1% of 60Hz. This means any effect on game speed would be so small you would not even realise. As mentioned in my previous comment, this feature is working superbly on PCSX2. It is also proven to be effective in Duckstation and for any emulator within Retroarch, where PPSSPP runs without hiccup as you can force this option through Retroarch. Emulators should all be implementing this going forward. A problem that has existed for so long can be so easily solved by simply syncing to the monitors 'true' refresh rate. You could have writing in brackets telling users to switch their display to 60hz prior to using this.

[vanfanel]

If you have a 75 HZ monitor, you can always set it to 60Hz in windows, or have the sync to host refresh rate as an option to toggle.

This. I was talking about an option. You have a 60Hz-uncompatible monitor? Disable the option and that's all.

[JetSetter1984]

Just wanted to note the setting we need implemented is 'scale to host refresh rate', not 'sync to host refresh rate'.

[mirh]

All monitors are slightly different.

They are. But as I already said, you can very much customize their refresh rate. Big increases or decreases aren't going to work for most, but something like a 0.5% adjustment should be a no-brainer everywhere.

In this sense.. I guess this might still be a welcome addition on consoles and mobile platforms (even though even them are getting variable refresh now), but it seems pretty contrived to want and use this on a fully controllable desktop.

Enabling both off them caused my games to run absolutely stutter free.

I really feel like this is due to idiot balls with DWM syncing that yo v-sync based pacing, rather than the emulation and the display per se being mismatched

Wait were you saying this was also a problem in linux?

This. I was talking about an option. You have a 60Hz-uncompatible monitor?

I don't think that's really a thing... Unless you are trying to output to some old PAL tv.

Just wanted to note the setting we need implemented is 'scale to host refresh rate', not 'sync to host refresh rate'.

Technically https://github.com/PCSX2/pcsx2/pull/5488 can do both of them.

[hrydgard]

What we technically want to do here, in a "sync to host refresh rate" mode, I think, is to switch presentation to FIFO (vsync) if the display monitor refresh rate is close to 60, and enforce "duplicate frames to 60hz", and additionally entirely turn off our own timing. Our audio already self-adjusts as needed.

I'm gonna make an option for it soon.

This option will self-disable if the display refresh rate is outside say 58-62 Hz. We could also support 90Hz and 120Hz with frame interpolation, maybe.

[JetSetter1984]

You clearly understood nothing of what is being said. The PCSX2 team did. You can not customize a monitor refresh rate to decimals successfully! It's to do with different panels, you can set it to a fixed value ie 60hz or 59 and attempt decimals but you then go online to vsync checker or see it live in retroarch and see it isn't exactly that and it's impossible to do so. A game that outputs @ 59.94 hz ie. every 60fps psp game is going to hitch with varying degrees of frequency on a monitor with a refresh which doesn't exactly match this, depending how far away from 59.94hz it is. A frame must either be dropped or shown twice at some point in order for the conversion. Man only a crt TV in this regard is guaranteed not to stutter. Most, if not all monitors will hitch and stutter a little @ different intervals due to the mismatch. Some can't see it, or don't care, but they're the type of people who think unreal engine 4 games on pc are acceptable... 'Scale to host refresh rate' solved the problem by syncing to the monitors exact reported refresh rate, not a generic 59.94 or 60.00 value. I have a 120hz 4k display. I set 59.94hz. It reports 60.02. I set 60hz. It's still 60.02. PPSSPP uses a generic value, it doesn't derive the vsync blank interval from the monitor itself. I get little hitches now and then. I toggle this setting in PCSX2. Now they're gone. It works and it's clearly a feature every emulator would benefit from.

On Fri, 16 Sept 2022, 18:07 mirh, @.***> wrote:

All monitors are slightly different.

They are. But as I already said, you can very much customize their refresh rate. Big increases or decreases aren't going to work for most, but something like a 0.5% adjustment should be a no-brainer everywhere.

In this sense.. I guess this might still be a welcome addition on consoles and mobile platforms (even though even them are getting variable refresh now), but it seems pretty contrived to want and use this on a fully controllable desktop.

Enabling both off them caused my games to run absolutely stutter free.

I really feel like this is due to idiot balls with DWM syncing that yo v-sync based pacing, rather than the emulation and the display per se being mismatched

Wait were you saying this was also a problem in linux?

This. I was talking about an option. You have a 60Hz-uncompatible monitor?

I don't think that's really a thing... Unless you are trying to output to some old PAL tv.

Just wanted to note the setting we need implemented is 'scale to host refresh rate', not 'sync to host refresh rate'.

Technically PCSX2/pcsx2#5488 https://github.com/PCSX2/pcsx2/pull/5488 can do both of them.

— Reply to this email directly, view it on GitHub https://github.com/hrydgard/ppsspp/issues/15081#issuecomment-1249592965, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOO2VJXPZU6JDMYBEK5CGD3V6SSODANCNFSM5HEHLLEQ . You are receiving this because you commented.Message ID: @.***>

[JetSetter1984]

What we technically want to do here, in a "sync to host refresh rate" mode, I think, is to switch presentation to FIFO (vsync) if the display monitor refresh rate is close to 60, and enforce "duplicate frames to 60hz", and additionally entirely turn off our own timing. Our audio already self-adjusts as needed.

I'm gonna make an option for it soon.

This option will self-disable if the display refresh rate is outside say 58-62 Hz. We could also support 90Hz and 120Hz with frame interpolation, maybe.

My reply was addressed to mirh on the last message. I appreciate you are making things happen hrydgard. What is needed is for the emulator to sync to the monitors reported refresh rate instead of a generic 59.94 or 60 etc. This way you would not need a duplicate frames setting for anything other than 30fps games. Doubling will not help if a frame needs to be dropped instead of duplicated.

[JetSetter1984]

What we technically want to do here, in a "sync to host refresh rate" mode, I think, is to switch presentation to FIFO (vsync) if the display monitor refresh rate is close to 60, and enforce "duplicate frames to 60hz", and additionally entirely turn off our own timing. Our audio already self-adjusts as needed.

I'm gonna make an option for it soon.

This option will self-disable if the display refresh rate is outside say 58-62 Hz. We could also support 90Hz and 120Hz with frame interpolation, maybe.

Sounds perfect. If somehow you can sync to the reported refresh rate instead of a generic value, then the game could be run at that same fps to perfectly match. Buttery smooth it would be :)

[mirh]

You can not customize a monitor refresh rate to decimals successfully!

Yes you can? You are talking about monitors usually coming with some two rando ~59 and ~60 hertz frequencies. I'm telling you about making a custom resolution. Just specify porch, sync and blank and you are good to go. (in fact, if ppsspp really wanted.. it could even take care of forcing everything by itself with the GPU vendors tools)

A frame must either be dropped or shown twice at some point in order for the conversion.

I see where you are coming from, and I'd like to underline again that this FR is useful besides this use case.. but nevertheless I'm somewhat skeptical that such a small difference could be noticeable. In pcsx2 case for instance, there's this lingering issue were somehow a lot of users seems absolutely and totally fine with the program, while some others could swear on their grandma that input lag is outrageously unbearable. And after some brief search.. it seems like ppsspp is also experiencing some of this voodoo. Where somehow refresh rate has something to do with the symptoms, but it's still not inherently the deal.

Man only a crt TV in this regard is guaranteed not to stutter.

You are thinking about exclusive fullscreen with tearing allowed perhaps. The display technology, regardless of the fact that this may actually be about refresh rate mismatch or something else, has nothing to do with this. (except perhaps indirectly if we consider VRR and HFR monitors exist)

Some can't see it, or don't care, but they're the type of people who think unreal engine 4 games on pc are acceptable...

Because of course people not agreeing with you now must be so handicapped not to notice seconds-long freezes.

[JetSetter1984]

Please go get CRT, set your refresh rate to whatever and the decimal points too. Now go on vsync checker online or get a software which measures vsync interval accurately to two or three decimal points. Does it match what you set to the decimal? No, it does not.

Input lag is off subject, so...

We are talking about full screen or windowed with vsync ON. CRT TV's in the NTSC regions were universally 59.94HZ. Monitors never adhered to that, so a monitor advertising 60Hz as a supported display output only has to be within I believe 100ms (or 0.1 seconds simplified) of that. Also, monitor panels do have everything to do with it, as they can only display refresh rates they are equipped to display, they can not be 'fine tuned' in decimal points to where you want them with any software, hence my screen not being able to do 59.94. Even a freesync monitor may match the refresh rate of a game but can not be manually set to a value within 2 decimal points in CRU and sit there. It is like you do not understand the subject dude. The refresh rate and the rate at which a game updates the display has EVERYTHING to do with it. The game is sending 59.94 frames of animation to a display which is showing 60.02. Do you see the problem? If you look closely in camera panning or whatever you will see a stutter/hitch every now and then. This is because If they are mismatched by 0.08ms, it will take 750 frames until a hitch is occured, which is every 12.5 seconds you get a stutter. This is precisely what I am experiencing, hence the frequency and consistency of the stutter in relation to the display. Somebody else closer to 59.94hz will get them at longer intervals and vice versa, quick math. I only play with vsync. I can not stand tearing and janky animation. I do not know how PCSX2 did it, because the game must now also be outputting 60.02hz, maybe it speeds up the game to match the refresh by 0.08% for my screen or something, I am not sure, but it works. I am not calling anyone handicapped, just that some have higher expectations from a game than others. Those expectations should not include a game which stutters each time you load a new area or have dialogue... Like youtubers hyping stray on pc when it stutters like mad all the way through yet they fail to mention it. There are then other youtubers that do mention it and call the game for what it is, a turd or average at best lol.

[mirh]

Does it match what you set to the decimal? No, it does not.

Do you understand what I even just told you? There are people playing everything and the kitchen sink this way.. but you can't even tell me "I have already tried this thing and it didn't work"?

Input lag is off subject, so...

I know it's a different matter. But it was an example of some people really having a totally different experience for no discernible reason - and I don't think that was due to personal sensibility.

but can not be manually set to a value within 2 decimal points in CRT and sit there.

I literally just did that with my 27GN850 (added 59.941Hz besides its default 59.951Hz) and the usual test was good. Maybe there's some >0.001% variance when you have just loaded the page (too bad the nvidia control panel doesn't have "live monitoring like the amd one IIRC) but still.

This is because If they are mismatched by 0.08ms, it will take 750 frames until a hitch is occured, which is every 12.5 seconds you get a stutter. This is precisely what I am experiencing, hence the frequency and consistency of the stutter in relation to the display.

Well, if you really have some kind of proven mathematical formula to predict the stuttering, I guess there really isn't many other ways out... Maybe I'm just too pessimistic into thinking everything must be a compositor/driver conspiracy

I only play with vsync. I can not stand tearing and janky animation.

Well, to be sure it would be pretty easy to see if that way, exclusive v-sync on presents the same issue, while exclusive v-sync off is fine (tearing aside).

because the game must now also be outputting 60.02hz, maybe it speeds up the game to match the refresh by 0.08% for my screen or something

That's what happens, yes.

I am not calling anyone handicapped, just that some have higher expectations from a game than others.

The UE4 example is pretty offensive, you know.

[JetSetter1984]

1 - People playing this way does not mean that it is not an issue.

2 - Ok, yh.

3 - What was the usual test? Because the app stating your refresh rate in a list is not the same as having it reported to you live. It does not work like that, I have tried it on a Lenovo 144hz gsync monitor and now my 4k 120hz freesync tv. It never goes exactly where you set it. Use this and then tell me, or check within retroarch screen reported refresh rate... https://www.vsynctester.com/detect.html

4 - The way out is clear as it has been solved already elsewhere, using 'scale to host refresh', or maybe Duckstation and PCSX2 do not know what they are doing and just added it for a laugh

5 - If your eyes perceive vsync off being as smooth as vsync on then you do not have the eyes required for this

6 - Great

7 - Oops

[LunaMoo]

5 - If your eyes perceive vsync off being as smooth as vsync on then you do not have the eyes required for this

That's like the most stupid argument ever, people have diferent setups, most of us with modern hardware doesn't even use vsync at all nor suffer from your setup problems and it has nothing to do with our eyes see or not see frame stutter or frame tearing. PC is not standardized to the point of providing same perfect experience to everyone. The problem being reported by under 1% of the userbase means just that - it happening to small fraction of people - and has nothing to do about faulty eyes, being less sensitive or not caring.

I just hope if the option for this will be made it will:

• be an actual option and not just turned on for everyone based on some range,
• have a warning printed on the screen on game boot when W-LAN is on together with such option that it might affect compatibility of multiplayer.

[JetSetter1984]

5 - If your eyes perceive vsync off being as smooth as vsync on then you do not have the eyes required for this

That's like the most stupid argument ever, people have diferent setups, most of us with modern hardware doesn't even use vsync at all nor suffer from your setup problems and it has nothing to do with our eyes see or not see frame stutter or frame tearing. PC is not standardized to the point of providing same perfect experience to everyone. The problem being reported by under 1% of the userbase means just that - it happening to small fraction of people - and has nothing to do about faulty eyes, being less sensitive or not caring.

I just hope if the option for this will be made it will:

* be an actual option and not just turned on for everyone based on some range,

* have a warning printed on the screen on game boot when W-LAN is on together with such option that it might affect compatibility of multiplayer.

I have zero set up problems. I run a 12700k with a 3090. Been using computers to game for nearly 20 years ffs. Fine here. You have vsync off but can not see the difference in smoothness of animation? It does have everything to do with eyes if you can not see the difference in smoothness between vsync on or off, damn. I have a Sony android with a 120hz display too and ppsspp does the exact same thing there, oh and on two of my buddies pc's and my daughters laptop and my sons desktop, so it's just 1%...

[mirh]

I'm completely appalled from what you are saying. What have phones (where there's no way to disable vsync) to do with anything? And what part of "different setups" did you miss? To the very extreme least, pixel response time is one of the most important aspects when it comes to the awfulness of tearing. E.g. I never really cared about it on my ~gaming monitors. But the moment I disable vsync on my TV I almost puke.

People playing this way does not mean that it is not an issue.

Right right right. People somehow pulling out CRTs from storage are really known to have low standards.

What was the usual test? Because the app stating your refresh rate in a list is not the same as having it reported to you live.

https://www.testufo.com/refreshrate Jesus christ.. Does it take all that much of an effort to explicitly mention CRU, and whether you actually did all the steps I hinted rather than continuing with this pronoun guess game?

The problem being reported by under 1% of the userbase means just that - it happening to small fraction of people - and has nothing to do about faulty eyes, being less sensitive or not caring.

I mean, it could be. The fringes of any population are expected to be special. On the other hand, it seems hard that interpersonal variability can explain such hard swings from day to night. It's not just passively that "a lot of users don't complain about it", but that even when you are out there with the specific intent of cherry-picking problems they cannot report any thing.

[JetSetter1984]

mirh you are just being a doozy. Sending a link to blurbusters does not make you correct. I have already told you I used cru. Use vsync tester.com, which is explicitly mentioned at the top of blurbusters and is a much faster and instantaneous 'live reported refresh rate'. It does not change the fact that you can not set a specific value to the decimal succesfully, it will always be slightly off unless your display can output at exactly 59.94hz, which most can not, so in regards to this feature being requested, it will be useful to many, maybe not you, which seems most important. I have nothing further to say. It is clearly a great feature request and useful otherwise it would not be implemented on two of the best emulators out there and one of the best launchers for retro games. Fact is, I have tested this on a multitude of setups and ppsspp always exhibits this issue to a varying degree, yet when using the core through retroarch, it does not, go figure...

[mirh]

Use vsync tester.com

Same results (except anything but 144Hz somehow has the synchronization indicator flickering, but whatever). If you wait long enough for everything to stabilize, reported frequencies are within one millihertz from the one I specified.

It does not change the fact that you can not set a specific value to the decimal succesfully

I could even get down to three decimals actually. Full disclosure: at least with the cheap ass CVT-RB2 timings that I use, the refresh rate in the EDID may be rounded up or down by one in the last digit.

unless your display can output at exactly 59.94hz, which most can not

Not that this would have made much sense even 15 years ago, but it really seems even more insane to claim with freesync monitors existing. As if somehow games waited fixed "discrete" intervals to render frames.

it will be useful to many

I already said that to be the case... Arguing that it's going to be far less useful than "most" is pretty different.

I have already told you I used cru.

Then, god.. I guess then something is not checking out in here, but at least I'm trying to pitch ideas.

[JetSetter1984]

You're pitching nothing, just being a douche and taking your own experience and placing that above and beyond everybody else. You can make stupid comments and claims, proving your knowledge to be questionable at best and claim whatever about setting your refresh rate, I have a different experience.

On Sun, 18 Sept 2022, 02:40 mirh, @.***> wrote:

Use vsync tester.com

Same results (except anything but 144Hz somehow has the synchronization indicator flickering, but whatever). If you wait long enough for everything to stabilize, reported frequencies are within one millihertz from the one I specified.

It does not change the fact that you can not set a specific value to the decimal succesfully

I could even get down to three decimals actually. Full disclosure: at least with the cheap ass CVT-RB2 timings that I use, the refresh rate in the EDID may be rounded up or down by one in the last digit.

unless your display can output at exactly 59.94hz, which most can not

Not that this would have made much sense even 15 years ago, but it really seems even more insane to claim with freesync monitors existing. As if somehow games waited fixed "discrete" intervals to render frames.

it will be useful to many

I already said that to be the case... Arguing that it's going to be far less useful than "most" is pretty different.

I have already told you I used cru.

Then, god.. I guess then something is not checking out in here, but at least I'm trying to pitch ideas.

— Reply to this email directly, view it on GitHub https://github.com/hrydgard/ppsspp/issues/15081#issuecomment-1250172051, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOO2VJQH53JM3VP7STWL6XTV6ZXJ5ANCNFSM5HEHLLEQ . You are receiving this because you commented.Message ID: @.***>

[unknownbrackets]

I'm going to lock this if there are any more comments about personal attributes rather than just the subject matter, which seem to be present in a few of the comments above. Let's all play nice, this is a video game emulator - it's meant to be fun.

Whatever is added, it should be optional, so everyone can have what they want.

-[Unknown]

[vanfanel]

Did any related options get added in the end?