Feature request!

[71knight]

Could you please incorporate dosbox SVN v-sync code into your core? It should have option for internal and external timing. Dosbox SVN v-sync works perfectly on Android, so I assume the same would happen for Windows. That would be the last piece of the puzzle to make your core the preferred dosbox version. Do you know maybe if and when that will happen?

[gordon81-afk]

Great proposal.

Dosbox Pure is the best dosbox fork.

To be perfect, it need v-sync support, at least it will need support retroarch timmings.

Please @schellingb , give us v-sync supprt in dos box pure.

Thank you!!.

[PoloniumRain]

This has been reported before: #4 and #26

But what i'm worried about is that if DOSBox Pure worked like DOSBox SVN in this regard then the input lag may be increased. DBP has very low input lag for a DOS emulator, often just a 2 frame delay for me, and i'm just guessing here but i think this might be because the unique way it handles the refresh rate/timing.

DOSBox SVN on the other hand has a 4 - 5 frame input delay when using either the 'external' or 'internal' settings. This is typical for other DOSBox variants. They're poor for playing fast paced games because of this. So if it comes down to it i'd rather have the lower latency of DBP.

I'd still like to see these settings added but only if @schellingb can also keep the low latency, or keep the current implementation as a option.

[schellingb]

Hi All. Thanks @PoloniumRain for linking the other related issues. #128 is also somewhat related as well. This issue was opened just in time when I started trying out some things to improve this.

A huge problem in my opinion with the 'external timing mode' in the other cores is that it doesn't support AUTO/MAX cycle scaling. AUTO is the default mode in DBP and I think it's a big part of what makes DOSBox fun to use. So I'm currently trying to get something like the external timing mode working but with something similar the cycle scaling feature of regular DOSBox. If this works out, it should be a "best-of-both-worlds" thing and would end up being the way forward for DOSBox Pure.

It should actually result in lower input latency because the DOS emulation and the frontend won't run asynchronous anymore. I'm willing to sacrifice a bit of overall performance for this. Adding input latency on the other hand is definitely a no-no. To counter the performance loss either the "Threaded Video" option of the front-end or maybe a core option that brings back some form of asynchronous processing could work.

I can't promise anything at this point just yet because getting that automated scaling right at stable framerates without (noticeable) stuttering is very tricky. But I'm hopeful :-)

[gordon81-afk]

Great notice @schellingb i hope you can bring us these features as soon possible.

I would make donation for your project. Can you tell us how make a donation?.

Thank you!!.

[71knight]

As far as input lag goes, you can either use the run ahead feature in retroarch or drop the audio output latency down near zero to compensate for the SVN core timing. You can do this assuming you have a strong enough CPU to remain within the deviation limit of your estimated frame rate in retroarch. I don't know if threaded video would be a good idea as it's prone to inject its own stutter due to synchronization timing issues. All I know is jazz jackrabbit looks beautiful in SVN version on android. So smooth with vsync like in 1992 DOS computer. So it would also benefit scrolling pinball games and other 2D games like abuse and the king's quest series. It would also help 2D/3D games look nice like bioforge.

[PoloniumRain]

As far as input lag goes, you can either use the run ahead feature in retroarch or drop the audio output latency down near zero to compensate for the SVN core timing.

I'm pretty sure that SVN or any other DOSBox core doesn't support Run-Ahead so there's no real way to properly reduce input lag, apart from simply just using a core with the lowest latency. One example of how bad input lag can be with SVN is firing the pistol in Doom, it will have a ~130ms delay between pressing the button and seeing the weapon fire. Not a good experience at all. Yet with DOSBox Pure it's around 33ms which is great for a emulator.

[schellingb]

Issue #91, #118 and #66, maybe #168 are also related to this.

Some games mentioned to test once done:

• Broken Sword ("shows flickering image")
• Full Throttle ("extremely slow and unplayable")
• Jazz Jackrabbit ("slower than in regular dosbox")

I'm still in the process of implementing an automatic MAX cycle finding heuristic that works with the way a libretro core is called. I'm still hopeful. One thing I learned is that original DOSBox is fairly conservative about finding the maximum cycles (ending up around 10% below the absolute maximum the host CPU can handle). So it certainly doesn't have to be perfect :-)

[schellingb]

Still working on this...

Wondering if the people subscribed to this issue could report what settings they find ideal when using either of the other DOSBox cores (dosbox-svn or dosbox-core).

I'm interested in both the core settings (timing mode) and RetroArch settings under Video -> Synchronization. Thanks!

Edit: As most of the trouble I have is related to other RetroArch features like rewinding, slow motion, gpu sync while using the automatic performance cycle mode, I'm also curious if anyone here uses these features.

[71knight]

Still working on this...

Wondering if the people subscribed to this issue could report what settings they find ideal when using either of the other DOSBox cores (dosbox-svn or dosbox-core).

I'm interested in both the core settings (timing mode) and RetroArch settings under Video -> Synchronization. Thanks!

Edit: As most of the trouble I have is related to other RetroArch features like rewinding, slow motion, gpu sync while using the automatic performance cycle mode, I'm also curious if anyone here uses these features.

As far as core timing mode, I use external because it syncs dos content to retroarch's front end timing of 60 hertz no matter the refresh rate of the dos content. And besides I don't see any other way around this since most people don't have 70 Hertz monitors. I don't know if Little big adventure 2 is a 70 Hertz game but it seems to be enjoyable on a 60 hertz screen...not too slow. As far as video synchronization settings I leave them at default. As for input latency, I choose a lower number on the audio latency setting under audio output of retroarch to give me quicker input commands. You can only go lower if you have a strong enough CPU or you'll get crackling audio.

[PoloniumRain]

Wondering if the people subscribed to this issue could report what settings they find ideal when using either of the other DOSBox cores (dosbox-svn or dosbox-core).

For me it entirely depends on the game. I just try out 'internal' 'internal (fixed 60fps)' and 'external' and use whatever is best. But none of these are ideal on a 60Hz display, there's still practically always stutter to some degree. Although at 60Hz DOSBox-Pure occasionally looks slightly smoother than any of those modes in DOSBox Core/SVN, depending on the game, which is one of the reasons i hope you keep your current implementation as a separate option. Maybe call it 'Classic' lol.

And if you implement some equivalent to 'external' mode, will VRR/FreeSync/G-Sync work with it? This is the only way to get full speed and truly stutter-free DOS games, even better than a 70Hz monitor because it always perfectly matches the refresh rate and compensate for fluctuations in frame rates (like slowdown). But Variable Refresh Rate currently doesn't work with DBP because of the way it renders frames, as described here.

RetroArch settings under Video -> Synchronization.

All default settings.

As most of the trouble I have is related to other RetroArch features like rewinding, slow motion, gpu sync while using the automatic performance cycle mode, I'm also curious if anyone here uses these features.

I use rewind but very rarely.

[TiBeN]

Still working on this...

Wondering if the people subscribed to this issue could report what settings they find ideal when using either of the other DOSBox cores (dosbox-svn or dosbox-core).

I'm interested in both the core settings (timing mode) and RetroArch settings under Video -> Synchronization. Thanks!

Edit: As most of the trouble I have is related to other RetroArch features like rewinding, slow motion, gpu sync while using the automatic performance cycle mode, I'm also curious if anyone here uses these features.

@schellingb I have the same issue like others here and stay with Dosbox-Core until this one will be fixed. I'm on Linux (ArchLinux) with a VRR setup. I use external in Dosbox-Core. My settings:

Timing: Frame timing mode: external

Video -> Synchronization: VSync: ON VSync Swap Interval: 1 Frame Delay: 0 Max swapchain images: 3 Sync to Exact Content Framerate (G-Sync, FreeSync): ON

With any core i get perfect sync. In the monitor menu i can see the framerate adapt to content. Eg, launching "Cadaver" for example makes the framerate approching 70Hz. Using Dosbox pure, framerate stay fixed to 144Hz (the native monitor refresh rate, meaning VRR does not work)

I don't use the retroarch features mentioned (rewind, slow motion..)

Hope it helps. Thank for your amazing work on this core. Fixing this issue will makes me switch.

[71knight]

So do you think we will be able to play 70 hz content on a 60 hz monitor with vsync? I know retroarch can only correct so much deviation from estimated frame rate and I think 70 Hertz is way above that limit. I'm guessing retroarch would have to have a huge audio buffer in it to do that. I think 60 hertz is easily fixable, but yeah 70 Hertz is going to be tough to put on 60 hertz screens including phones.

[schellingb]

@71knight As far as I understand RetroArch ignores the Video > Synchronization > Vertical Sync (VSync) setting if the Video > Output > Vertical Refresh Rate setting is set to something that is a few Hz below the content frame rate. So yes, 60Hz display with a 70Hz DOS game will run with vsync disabled on the video driver side.

In the end I think this is a frontend problem though. A frontend should be able to have the emulation core calculate 70 frames a second but only render 60 frames to the screen by throwing away 1 out of 7 frames. RetroArch currently can't do that so it can't vsync in that case.

As far as core timing mode, I use external because it syncs dos content to retroarch's front end timing of 60 hertz no matter the refresh rate of the dos content

The option "external (variable fps)" in DOSBox-SVN does not do that. "internal (60fps)" does that, which, as far as I understand, should roughly match the behavior of current DOSBox Pure (except Pure uses the active monitor framerate instead of a fixed 60).

[schellingb]

So I finally felt confident to push a new update with a new mode related to frame timing/video synchronization.

The core should behave as it has before when updating from 0.17 to the new 0.18.

I'm eager to hear from the people in this thread (and anybody else) if the new mode works as good or better than what we had before. To enable the new timing mode, go into the core options under the category Emulation and switch Timing Mode to New Mode. This will reveal further options related to the new mode:

• Force 60 FPS Output: Enable this to force output at 60FPS.
• Show Performance Statistics: Shows some frame time statistics on screen.
• Advanced > Input Latency: Has an advanced mode with a tiny bit of input latency reduction.

When running a 70hz DOS game while using the forced 60FPS option, the core essentially skips rendering every 7th frame.

Regarding the "Lowest Latency" option I was close to removing that feature. I still am not sure if it is of any use or if it is just confusing. I think it's possible that input latency is around 10ms lower with that mode. If someone has a phone or camera that can record at high framerates (like 240FPS on iPhone6 and newer) I'd be curious to see a video with the mode on and one with the mode off that shows a mouse or gamepad button being pressed with Quake (or similar) visible on a screen in the background.

[PoloniumRain]

Been waiting for this!

If someone has a phone or camera that can record at high framerates (like 240FPS on iPhone6 and newer) I'd be curious to see a video with the mode on and one with the mode off that shows a mouse or gamepad button being pressed with Quake (or similar) visible on a screen in the background.

@schellingb I've made a video here.

Setting 'Low latency CPU usage' to 100% will consistently produce lower input latency with Quake. Each input can vary by up to 3 frames though, so overall it looks like this:

Low latency set to 50%: 4 - 6 frames delay Low latency set to 60%: 4 - 5 frames delay Low latency set to 100%: 3 - 4 frames delay

It looks like there's roughly around a 1.5 frame reduction at 100%. Quake seems to have the biggest difference of any game that i've tested so far though, but either way the 'Low latency CPU usage' setting is definitely a useful feature so i'm glad you included it. Maybe make the description text a bit easier to understand though, you could add something like "Increasing the percentage will potentially reduce the input latency". The description also mentions stutter at higher percentages but i haven't seen any, and i think the current 90% default setting is good although maybe a bit conservative. 95% might be ideal.

I'm still testing the other new settings and will report my findings later, but can't test VRR yet because i don't have a VRR display at the moment so hopefully someone else can test if that's working. And btw i've found 2 problems with the 0.18 update, i'll create new threads for each. Edit: #201 and #202

[schellingb]

Thanks for the video and the feedback. Interesting :-)

In the end, the percentage of the Low latency CPU usage setting scales the speed of the emulated CPU. The lower it is, the lower will the framerate in Quake be. The actual time it takes from the input event until it reaches the DOS emulation is not affected by the percentage. But because the emulated CPU speed changes, different DOS games might react different to the setting.

I don't think setting to 100% makes much sense, because you won't ever have 100% of the time available for emulation because the frontend needs at least some time to pass the video and audio output to the hardware etc. It might work with the setting "threaded video" enabled but that itself introduces more latency again. Do you have that enabled?

So what usually happens when set to 100%, the core can't run at the emulated refresh rate and one ends up with stuttering/crackling sound and actual slowdown.

The new Show Performance Statistics setting can be used to see if the emulated CPU can be emulated at full speed and when set to Detailed Information other neat details like how many different images are actually drawn per second by the game.

[71knight]

Just tried version 0.18 on Android 10 but could not access the options menu through retroarch because the core would crash on Android 10 with retroarch version 1.9.5 using opengl. Did play some jazz jackrabbit at default settings at 60hz and the vsync is still broken....video jerks every 3 seconds.

[schellingb]

Without activating the new Timing Mode core option to New Mode the core is intended to run as it did before, so I consider this a success :-) I'll see if I can test RetroArch version 1.9.5 and make things work. But to fully use the new timing mode, a nightly build of RetroArch (or the next release v1.9.12) is needed. Newest RetroArch adds a new feature for cores to detect various frontend behaviors like slow-motion, rewinding, rate throttling, etc. which is very useful for what we're trying to achieve.

[PoloniumRain]

I don't think setting to 100% makes much sense, because you won't ever have 100% of the time available for emulation because the frontend needs at least some time to pass the video and audio output to the hardware etc. It might work with the setting "threaded video" enabled but that itself introduces more latency again. Do you have that enabled?

So what usually happens when set to 100%, the core can't run at the emulated refresh rate and one ends up with stuttering/crackling sound and actual slowdown.

I don't have 'Threaded Video' enabled. 100% works well for me so far but i have an overclocked 24 core AMD Threadripper 3960X so it's kind of overkill, and when making that video 'Show Performance Statistics' was enabled (but it's cut off in the vid) and the emulation speed was always at 100% with 'Low latency CPU usage' set to 100%. Obviously very few of those 24 CPU cores will be used, but i had no audio crackling and the Performance Statistics reported 70 drawn images. I can see how using 100% will be an issue on slower CPU's though. I'll probably leave it on something like 96% just to be safe.

I really like the Performance Statistics by the way, very useful :)

[schellingb]

Haha, that's quite a beast of a CPU. That actually makes sense then, in code, that 100% is rounded down to something more like 99%, so there is a tiny bit available for stuff outside just the raw DOS emulation. As mentioned, I wasn't eager to include the option due to how hard it is to describe and for a user to make sense of it. But it seems like it works for you so I'll probably leave it in. Unlike "New Mode" and "Old Mode" which have tons of completely different code, the new low latency setting is quite simple. We'll see how we progress from here. Maybe at first "New Mode" could become the default and then later "Old Mode" can hopefully be removed.

[71knight]

Without activating the new Timing Mode core option to New Mode the core is intended to run as it did before, so I consider this a success :-) I'll see if I can test RetroArch version 1.9.5 and make things work. But to fully use the new timing mode, a nightly build of RetroArch (or the next release v1.9.12) is needed. Newest RetroArch adds a new feature for cores to detect various frontend behaviors like slow-motion, rewinding, rate throttling, etc. which is very useful for what we're trying to achieve.

Nevermind.... The problem with Android crashing on dosbox pure 0.18 is indeed older versions of retroarch. I upgraded to latest nightly of retroarch and no more crashes when trying to access options. Still testing everything else.

[71knight]

Yes! I am happy to report that the vsync fixes that you implemented are working! Jazz jackrabbit (60Hz) is scrolling smoothly, while bioforge (70Hz?) Is synced and smooth using the force 60 fps output with new mode timing. Maybe one small hiccup is there is still a slight video jerk that repeats not to often with 60 fps output enabled using 60 hz content. With it off everything is smooth. Best seen repeatedly firing jazz jackrabbits round bullets. Using ver 0.19. Thank you for your hard work with this great core.

[PoloniumRain]

@schellingb i've done more testing and made a much more in-depth video.

The 'New Mode' is looking identical to the 'External' mode in DOSBox Core and SVN, and 'Force 60fps Output' is identical to 'Internal (variable fps)' in DOSBox Core/SVN. I expected that, but this is what you actually did right?

With Quake, the New Mode is showing less frames on screen when compared to the Old Mode. The Performance Statistics say the New Mode is drawing ~70 frames, and the display used here is 60Hz, but the number of frames actually being displayed on screen is clearly a lower number than 60fps. You can easily see in the video that the Old Mode is looking smoother than the New Mode because it's outputting more frames. But both modes have uneven frame pacing where some frames are displayed on the screen for longer periods of time than others. It's considerably more noticeable with the Old Mode during gameplay (even though it has a higher visible frame rate) and this is the "stutter" people always complain about with DOSBox in general. It's unavoidable with a 70Hz game on a 60Hz display and all other DOSBox variants that i'm aware of have this issue. So overall each mode has it's own pros and cons - Old Mode has a higher number of frames that are actually shown on the screen, but it has more stutter because of the worse frame pacing. But if i had a VRR display to test with i'd expect the New Mode to look vastly superior.

Quake is also running faster with the New Mode - The camera is turning quicker so you can see it get out of sync with the Old Mode in the split screen comparison at 52 seconds into the video. The New Mode is running Quake at the same speed as the DOSBox Core/SVN 'External' timing mode. So i'm guessing this is actually the correct game speed...

'Force 60fps' looks extremely similar to Old Mode. The amount of visible frames on screen and the frame pacing are practically the same.

Blood is a mess in slow motion lol. Loads of screen tearing even with the Force 60fps mode, but that's expected because this mode seems the same as 'Internal (fixed 60fps)' on DOSBox Core/SVN. These Forced/Fixed 60fps modes in any DOSBox variants never actually get rid of screen tearing but i keep seeing people assuming that they're meant to do this. I think they just render at 70fps and only send out 60fps? Either way they don't actually have v-sync, and enabling v-sync in RetroArch wont do anything. At the end of the video i show Screamer 2 because the horizontally animated logos perfectly show the screen tearing - It's all the same on DOSBox-Pure/Core/SVN. Anyway with Blood, again, the New Mode is clearly outputting a lower number of frames than the Old Mode. And again, the Force 60fps and Old Mode practically look identical.

A weird thing about Blood is that the Old Mode and the New Mode are both running the game at the same speed, unlike Quake. You can see they never get out of sync in the video.

New Mode has lower input latency than the Old Mode. I only show it once in the video but i tested it many times and the New Mode latency has a 7 - 20% improvement. But counting the number of frames is no longer an accurate measurement being as the New Mode outputs less frames than the Old Mode, so frame counting has become pointless. Instead the input latency now needs to be timed, like in the video. Overall the New Mode is the fastest of all modes. Btw the 60Hz TV i used in the video has 21ms latency, so the actual input delay is at least 15% less than what you see.

Force 60fps and Old Mode have identical input latency. Considering they also look the same you'll be happy to hear that it's looking like there isn't any point in keeping the Old Mode around lol...

And while testing i noticed that the 'default' setting for 'Input Latency' is the same as having 'Low latency CPU usage' set to 100%. The number of cycles is exactly the same for both of these modes on any game i try. Is this intentional?

[schellingb]

Thanks for the detailed analysis. I'll try to respond a bit more in-depth when I have time but a quick reminder for testing with Quake. You should also try its built-in benchmark. Open the Quake console (with the tilde ~ key) and then enter timedemo demo3 and press tilde as soon as possible to close the console. Once the demo is done, open the console again to see the results. Here's what I have with the various modes, while running at a resolution of 800x600:

Settings	Time demo result demo3 at 800x600
Old Mode	21 seconds (51.9 FPS)
New Mode (default)	19.5 seconds (55.9 FPS)
New Mode (Force 60FPS w/ vsync)	19.6 seconds (55.7 FPS)
New Mode (Low latency @ 95%)	20.5 seconds (53.2 FPS)
New Mode (Force 60FPS w/ vsync + low latency @ 50%)	42.5 seconds (25.6 FPS)

Combining low latency with vsync forces me to put CPU usage down to 50% otherwise RetroArch isn't able to run the emulator at 100% speed. That is because both vsync and low latency are things that have to wait on things (vsync waits for the monitor, low latency waits until the frame is finished). Without 'low latency' the core can draw frames in the background while vsync waits.

As far as I understand the descriptions in dosbox-core/dosbox-svn (I have not looked at its code), the modes named "internal" should be similar to DOSBox Pure's "Old Mode". DOSBox Pure was always targeting the reported monitor refresh rate so it can be both "fixed 60fps" or "variable" depending on the monitor. I think "external" matches "New Mode" with "Lowest latency" active. The default of the "New Mode" is a compromise which should offer best performance while still allowing the frontend to time the rendering of each frame.

Edit1: @PoloniumRain

With Quake, the New Mode is showing less frames on screen when compared to the Old Mode. The Performance Statistics say the New Mode is drawing ~70 frames, and the display used here is 60Hz, but the number of frames actually being displayed on screen is clearly a lower number than 60fps

That part of the video was shocking for sure :-) Can you enable RetroArch's FPS display (Settings ->On-Screen Display -> On-Screen Notifications -> Notification Visibility -> Display Framerate) and render statistics (Settings ->On-Screen Display -> On-Screen Notifications -> Notification Visibility -> Display Statistics) in addition to New Mode + Pure's performance statistics? After closing the menu, let it settle a bit and take a screenshot. I'm curious what the state of RetroArch is there. If RetroArch says it runs the core at 70 fps there, it really should be getting 70 different frames every second. Is it not displaying 60 of them? Kinda weird... Maybe you have vsync forced in the graphics card driver?

Edit 2:

And while testing i noticed that the 'default' setting for 'Input Latency' is the same as having 'Low latency CPU usage' set to 100%. The number of cycles is exactly the same for both of these modes on any game i try. Is this intentional?

Without low latency, the emulation always has 100% cpu time available because it runs in the background while the frontend processes and submits the video and audio data. So yes, it should be how you describe it. But having CPU usage at 100% and still running the emulation at full speed is only possible on high spec PCs.

Edit 3: I ended up recording a bunch of videos at 240 fps. Here's 2 seconds of each slowed down 8 times. I ended up counting how many different images did show on the screen.

Game	Settings	Video	Frames Counted
Quake	New Mode, Default, 60hz monitor	QuakeNewModeDefault60hzMonitor_105	105
Quake	New Mode, Force 60 fps, 60hz monitor	QuakeNewModeForce60FPS60hzMonitor_120	120
Quake	New Mode, Default, 144hz monitor	QuakeNewModeDefault144hzMonitor_138	138
Blood	New Mode, Default, 60hz monitor	BloodNewModeDefault60hzMonitor_120	120
Blood	New Mode, Force 60 fps, 60hz monitor	BloodNewModeForce60FPS60hzMonitor_120	120
Blood	New Mode, Default, 144hz monitor	BloodNewModeDefault144hzMonitor_140	140

Running the games at 640x480 probably made it easier to make the games hit the rates as good as it did. And I think because Blood is simpler than Quake it ends up returning the finished frames quicker so even without forcing 60FPS+vsync it ended up showing 60 different frames.

[PoloniumRain]

Ah i found the problem! It's the RA Vulkan video driver that produces 35fps with the New Mode/External. Ffs... When using GLcore or GL i get totally different results.

I counted the frames with Vulkan and GLcore and here's a comparison:

Settings	Vulkan + Quake at 800x600
Old Mode	59 - 60 fps (every 60 - 80-ish frames it misses 1 frame)
New Mode (default)	35 fps
New Mode (Force 60fps)	59 - 60 fps
DOSBox Core/SVN (external)	35 fps
DOSBox Core/SVN (Internal (fixed 60fps))	59 - 60 fps

Settings	GLcore + Quake at 800x600
Old Mode	57 - 58 fps (every 20 - 25-ish frames it misses 1 frame)
New Mode (default)	57 - 58 fps
New Mode (Force 60fps)	57 - 58 fps

And the GL display driver exactly matches GLcore. But i didn't have time to test all this with my camera, so these tests were done with screen capture software (recorded at 60.00fps with Nvidia Shadowplay). When comparing my camera footage to the screen capture videos the visible frames match up, and recordings of other cores like Flycast show a perfect 60fps with no missing frames, so Shadowplay seems to be giving accurate results here. It's only the DOSBox cores that are all showing 57, 58 and 59fps. But can't be 100% sure that it's not Shadowplay doing this unless i test with my camera. Either way it's definitely Vulkan that's showing the weird 35fps with the New Mode/External.

A bit pointless now that i've found the problem, but i'd already run all these tests so i'll post the results anyway lol...

Settings	Time demo result demo3 at 800x600
Old Mode	14.6 seconds (74.4 fps)
New Mode (default)	13.8 seconds (79.1 fps)
New Mode (Force 60FPS w/ vsync)	13.9 seconds (78.4 fps)
New Mode (Low latency @ 95%)	14.6 seconds (74.6 fps)
New Mode (Force 60FPS w/ vsync + low latency @ 50%)	29.4 seconds (37.0 fps)
New Mode (Force 60FPS w/ vsync + low latency @ 100%)	13.9 seconds (78.6 fps)

...Those results are with Vulkan. But they're basically identical with the GL display driver (up to 0.2 second differences).

RetroArch Statistics with Vulkan:

[schellingb]

Ah good find there with the vulkan video driver! I always run with GL so I haven't thought of that. Although for me it isn't that drastic of a change. Vulkan and GL are very similar in terms of frames shown. Screen capture software like Shadowplay or OBS seem indeed enough to verify this.

Well, I don't really know I can do anything in this case. RetroArch gets 70 unique video frames a second but it somehow isn't able to show 60 of them... The number shown after "Drawn:" is correct as far as I can tell, it compares every frame with the one before and counts if there is a pixel difference.

Force 60fps and Old Mode have identical input latency. Considering they also look the same you'll be happy to hear that it's looking like there isn't any point in keeping the Old Mode around lol...

After thinking about this for a while, I think the behavior of "Old Mode" makes sense on low spec devices. Currently "Old Mode" and "New Mode" have a lot of separate code so for me I need to get rid of one of them. But I think I can implement the behavior of the old mode (run DOSBox fully in the background and whenever the frontend is ready to get a frame of video, pass the latest finished frame) under the new mode. But I think I'll call it something like "Variable latency with better performance for low-end devices" and put it into the "Input Latency" option. Names like "internal" and "external" never made that much sense to me and I doubt they do for most users. I'll probably resort to putting the technical explanation into the core's README because I doubt it fits into the description of the core option.

[schellingb]

So this "new" and "experimental" mode is now the only mode in 0.21 because I haven't really heard any feedback except positive (better or much better than before) or neutral (no improvement really) reactions. So I'm hoping this won't cause too much problem. Fingers crossed! Thanks everyone for the replies and testing, it sure took a while. I'll close this issue if nothing major pops up in the next few weeks (or months).

[Tasosgemah]

Now that you mentioned it, i did find some minor issues with this. In DOOM, when there is a transition, like a new level loading, it doesnt go smoothly, it feels a bit janky, like the sound cuts off and the screen glitches for a fraction of a second. Nothing major and its the better option, but i thought i would mention it anyway