Very cool! I'll give it a go.

I thought some video drivers implemented vsync so that when the application does the screen flip or update, the function returns immediately without blocking the application, and a back buffer then gets flipped at the correct moment in the background. However, I experimented with SDL's video output a while ago, and if I render a moving bar as fast as possible and set fulldouble to true, SDL (or video driver) busy waits for v-blank in kernel mode 😜

You need triple buffering for that (one buffer drawing to the screen, one waiting for vsync and one rendering on the gpu).

Well, I've decided to give triple buffering a quick trial now... probably again. In my case, the following line has been added to the "Screen" section in /etc/X11/xorg.conf:

1    Option         "TripleBuffer" "True"

For the testing, I've tried running vanilla DOSBox v0.74 on OpenGL with a couple of games, having VSync forced for GL. That has been done with the triple buffering disabled and then enabled. I haven't seen much differences in the behavior, though. Maybe there has been some improvements in the speed, but there are still clear slowdowns.

===

It may be good to tell some more about the way the patch in its current form works. First, the old vanilla DOSBox behavior is achieved by setting vsync=false and framecap=0. To have any frame capping at all (and maybe Vertical Sync too) you want vsync=true *or* framecap>0. The current behavioral differences in regards to the value set for vsync are as follows:
- If vsync=true and framecap=0, the refresh rate is manually measured on DOSBox startup. This never happens when vsync=false.
- If vsync=true and OpenGL is used for the output, VSync is enabled on the GL level, at least if the DOSBox exe is linked against SDL v1.2.11+ (where SDL_GL_SWAP_CONTROL is available).

===

Now, one big problem is that several things are platform-specific. As an example of that, with an earlier revision of the patch, I got VSync with OpenGL to work as expected on Linux, but not on Windows (with things being slower than intended). The reason? Well, SDL_GL_SwapBuffers is not the only GL-related function that may stall DOSBox and wait for VSync. Other GL functions can do the same. As for an explanation, the very first call to SDL_GL_SwapBuffers may return immediately, although the GPU would wait for VSync in the background. As a result, at least for one of specific GL functions called, the GPU may need to wait for VSync before the new function call may be processed.

This leads us to a relevant note written in the following article (page 2):
http://linuxdevcenter.com/pub/a/linux/2003/08 … nim.html?page=2

To the note itself, assuming ordinary non-GL SDL surfaces are used: If a hardware surface is used with double buffering, then the very first call to SDL_Flip may return immediately, rather than wait for VSync. A following attempt to lock a hardware surface may result in such a wait, though.

===

So, at least originally, I'd thought of avoiding to deal with video memory when no output is actually done. In practice, though, things have changed since then. The following briefly explains what happens when frame capping is in use (and possibly VSync):
- First, the GFX_EndUpdate function has been split into two: A miniature GFX_EndUpdate function called when the drawing of a frame is done (along with a scaler applied if there's any), and GFX_Output which does an actual output to the screen.
- Now, a buffer in system memory is used for the drawing of the scaled frame. If output=surface or output=ddraw, an SDL software surface is used as the buffer.
- Next, when GFX_EndUpdate is called (i.e. the drawing is done), the buffer's contents are copied to somewhere. The specific location to which they are copied depends on the settings.
If output=surface and fulldouble=false, they are simply copied to the SDL Surface returned by SDL_SetVideoMode. Let's call it the primary surface from now on.
If output=surface and fulldouble=true, they are copied to a secondary SDL surface. There are great chances it is a *hardware* surface, though, so maybe this may cause a stall as described before. I think that I haven't seen one on Windows, though. But maybe I'm wrong...
If output=ddraw, the buffer's contents are copied to a secondary SDL surface again. This seems to work well for now...
If output=overlay, the contents are copied to the SDL overlay itself. This seems to work so far here, too.
Finally, if output=opengl or output=openglnb, the contents are copied to another buffer that is always allocated when GL is in use. It seemed to work so far, although that may be the result of both buffers residing in system memory.
- Now, GFX_Events has been used as a place to check for the right time to output something. When this is the case, GFX_Output is called. The contents of GFX_Output are mostly similar to the ones of vanilla/unmodified GFX_EndUpdate.

===

I have thought that it might be better to have some more changes, especially due to SDL Locks being the potential cause of waits for VSync. Although, I haven't had much problems for now...
Here is a list of possible modifications, though:

- First, I think that the fulldouble setting can be removed, since it exists for the same goal of reducing tearing. vsync=true can do the job of fulldouble on its own, depending on the circumstances (to be described soon).
- Now, as before, use a *software* buffer (i.e. in system memory) for drawing what's needed. This is what is done currently. Let's call this the "draw" buffer from now on.
- Furthermore, when the drawing is done (i.e. GFX_EndUpdate is called), always copy the buffer's contents to another *software* buffer. This ensures that we won't get stuck while waiting for VSync. This new buffer would be referred to as the "output" buffer.
- Now we get to GFX_Output. If output=surface, the contents will be copied from the "output" buffer to the primary SDL surface, and then a page flip will be done. So the secondary SDL surface allocated by setting fulldouble=true won't be needed at all. The primary surface should still be double buffered, though (at least when vsync=true).
- As for output=ddraw, we may still need to have the secondary surface (which must be a hardware one). So the same surface will get the contents of "output". This means that four buffers will be used: Two SDL surfaces and the "draw" and "output" buffers. However, maybe we can skip the "output" buffer here and copy "draw" to the secondary surface, since it appears to work alright for me. Anyway, vsync=true should imply that the primary surface is double-buffered.
- When output=overlay, the contents of "output" will simply be copied to the overlay before outputting to screen. In practice, everything works here even by copying contents from "draw" to the overlay directly.
- Finally, for output=opengl and output=openglnb, the OpenGL buffer currently used in vanilla DOSBox may actually have the role of the "output" buffer. Or, well, at least as long as it is a software buffer. This is already the case in the patch.

Here comes an update. Eventually, I haven't went by the way of *never* touching a hardware surface (or overlay) unless it is time to output something to the screen. The real issue might be when such a surface is the one returned by SDL_SetVideoMode (and similarly with the overlay). As long as VSync can be toggled, it never happens now and I don't see any clear slowdown so far...

===
Changes
===

- output=surface,ddraw: The fulldouble setting has been removed. To take advantage of a double buffered surface (or at least try to), set vsync=true. Note that references to the setting are still found in the code after patching, but they're commented out.
- output=surface: A secondary "blit" surface is now used whenever frame-capping is in effect - and only then. To compare, on vanilla DOSBox the blit surface is used in conjunction with a double-buffered screen surface.
- As before, whenever frame capping is toggled on, a software buffer is used for drawing what's needed. There are a few code modifications in regards to that, though.
- output=overlay: An *additional* software buffer is now used. When a screen update is done (i.e. GFX_EndUpdate is called), the relevant contents are copied to this buffer. Only when output to the host display is desired (i.e. GFX_Output is called) these are copied to the overlay itself.
- A totally unexpected and unrelated bugfix? Well, on vanilla DOSBox v0.74/SVN running on Windows, try having the following set: fulldouble=true, output=surface, aspect=true. The aspect correction may not work as expected. However, the current revision of the patch seems to fix this (with vsync=true instead of fulldouble=true).
- Some more changes, mainly in terms of organizing the code modifications.

What may be the most noticeable change for the end-user is that now, "vsync" practically replaces the "fulldouble" setting.

===
How to use
===

First of all, you should set vsync=true. Now, output=opengl and output=openglnb are known to work on Linux and Windows altogether with this; output=surface seems to work here on Windows; And output=overlay may require Linux with an NVidia graphics card.

If there are problems:
- output=opengl,openglnb: Try forcing VSync for GL apps in driver settings, if possible.
- output=overlay: If Linux is used with NVidia and their drivers, load nvidia-settings, select "X Server XVideo Settings" and make sure that "Sync to VBlank" is checked.
- output=surface,ddraw: Try starting DOSBox in a fullscreen.
- Manually set the framecap to the display's refresh rate (in Hz).
- Try playing a bit with the vsyncwait setting. In general, the closer it is to 10000, the more time that DOSBox has to process the emulation. There may some problems if it is too high, though.

===
A known issue
===

Currently, if vsync=true and framecap=0, the refresh rate is measured only once - when DOSBox is launched. In particular, the refresh rate is *not* measured again when toggling between windowed and fullscreen modes while DOSBox is running. This may be problematic, if Vertical Sync is in effect on one of the modes but not on the other. Here are a couple of ways of solving this for now:
- Make sure that DOSBox starts in the mode where VSync actually works (probably fullscreen).
- Alternatively, set framecap to the display's refresh rate.
I guess it can easily be fixed by re-measuring the rate whenever it's needed, although it would make the fullscreen/window switch a bit longer. It isn't *that* much of a problem, though...

===
One more comment regarding a (probably) abandoned idea
===

In an earlier message of mine you may see the mention of "linear motion interpolation", as a workaround for possible judders resulting from having different refresh rates involved. However, I have a feeling it doesn't worth the effort to try and implement it, although it's probably feasible (with the help of OpenGL and Alpha blending).
I've done a simulation of that with the help of VirtualDub. The input is a video of Commander Keen 4 captured by DOSBox. Its framerate is ~70fps, although the game renders ~35fps (i.e. each frame is repeated twice). I've then applied an interpolation to 60fps and checked a preview. As expected, it makes things look more blurry while there is motion. One can think of it as a "ghosting" effect. So, I guess that many would agree it is probably worse to have the ghosting, rather than a few unavoidable judders.

For DirectDraw

Change FullDouble to FullTriple simply by changing the BackBufferCount for the primary surface from 1 to 2 ( in DX5_SetVideoMode )

Instead of polling GetFlipStatus in a busy wait, simply return if the previous flip is still waiting to happen. (in DX5_FlipHWSurface)

The problem is GetFlipStatus() doesn't work on Win7. /facepalm

aqrit wrote:

For DirectDraw […]
Show full quote

For DirectDraw

Change FullDouble to FullTriple simply by changing the BackBufferCount for the primary surface from 1 to 2 ( in DX5_SetVideoMode )

Instead of polling GetFlipStatus in a busy wait, simply return if the previous flip is still waiting to happen. (in DX5_FlipHWSurface)

The problem is GetFlipStatus() doesn't work on Win7. /facepalm

Well, guess it is another example of triple buffering where it isn't, say, well-standardized. So for now, the lack of a standard (and even better, a portable one) means that a change to DOSBox is still desired.

Edit (September 20th, 2012): Please ignore the following note of mine. It seems to work well for me with output=overlay while playing Rayman games (which render ~59.8265fps), but there are noticeable frame skips with opengl. Alright, there are also a few of this with overlay (one minor "jump" per 5-6sec), but this is expected due to to the refresh rate differences.

Original note:

Considering any update to the patch, I can think of just one minor thing at the moment.
Basically, forget what I've said before and always set vsyncwait=10000. The results of using this are that:
- On the one hand, maximal DOSBox emulation performance would be achieved (more or less like vanilla DOSBox).
- On the other hand... assuming a host refresh rate of 60Hz, you'd probably get ~59.7fps more often. Guess it isn't that significant, since there aren't many emulated video modes refreshing at 60Hz exactly.

I do intend to post a diff that removes the "vsyncwait" setting altogether, but vsyncwait=10000 should work for you right now. So, all you should really be interested in are the "vsync" and "framecap" settings.

Hi again,

Another revision that can be tried out is attached. This may not exactly be what I've originally hoped for (a bit more than a week earlier), but it can still be tested.

Changes:
- The "vsyncwait" setting has been removed.
- Somewhat more accurate timing is in use, especially when "framecap" is set to a positive value in the DOSBox configuration.
- Whenever it is found (well, guessed) that the host display's refresh rate is higher than the emulated display's refresh rate (in Hz), vanilla DOSBox behavior is applied. That is, when a new frame is ready, it is outputted to the host display immediately. Note that the "frameskip" setting has an effect here: With frameskip=1 or more, chances are that vanilla behavior is to be applied.
- Otherwise, alternate behavior is in effect. There are a few changes to that in comparison to earlier revisions, though. Suppose that "framecap" is set to "60" and this is the display's refresh rate. Then, in general, one frame is outputted for every 1/60th of a second, approximately. That period may be a bit longer if a new frame is not ready right when it is the time to output one. Furthermore, if it is found that a screen output operation takes 2ms or more, we "refresh" the timing and begin to output once per 1/60th of a second from this very moment.

Note that I have seen a few unexpected judders when frameskip is applied (frameskip=1), while testing Commander Keen 4 and Superfrog (demo).

I wonder if this version would fix slow-down at battle-scene from game: 'Excellent Potato' ?
slow-down only happened at battle scene where the rest of the game seems running at normal speed.

Update: now that i've tried it, i'll reports that it has no effect for that game.
I've tried turning on/off the vsync, and tried various framecap values.
The slowdown still happen like what it was with vanilla 0.74

I wonder if you could try it... 😉

I think it would be a good chance to ask if someone has a better idea, in regards to the following.

Basically, there has been one issue I've been trying to fight against while updating the VSync patch: Performance. You see, while the patch may help with avoiding noticeable slowdowns, DOSBox still stalls a bit from time to time while waiting for vertical retrace. I am sure you can see the impact of that on the performance, especially with cycles=max being set.

While it is not hard to give up some percentage of the performance (using the earlier "vsyncwait" argument or some other method), that is still a potentially great performance loss. So, while I guess the answer to the following is "No!", I've wondered if anybody can come up with a solution.

Here are a few approaches I've thought about. For simplicity, let's assume a host display refresh rate of 60Hz, or ~16.67ms per frame:

- After an output to screen has *ended*, wait 16.67ms before *beginning* to output the next frame (or possibly the same frame). Problem with this approach is that it can result in noticeable judders. Believe me, I have tried this by myself. While I haven't seen judders on Linux with output=overlay, they can be seen with output=opengl. Hard-to-avoid imprecisions with the timing are probably the explanation.
- A potentialy good *and* problematic solution: Do the outputs in a separated thread. That way, we shouldn't worry of timing imprecisions and no harm is done to DOSBox performance. One great issue is that a lot of the SDL functions, like SDL_SetVideoMode and SDL_PollEvent, should all be called from the same thread. In fact, it is safer to assume it must be the main thread. It is probably possible to come up with some kind of a solution, where the emulator itself is actually running in a secondary thread, it fills a queue with SDL calls for the main thread, and another queue is used for SDL events. However, you can probably see why that is more than being a quite problematic solution...
- Maybe in dosbox.cpp there is a chance to "compensate" for the lost time, considering that it appears to leave some free time even with cycles=max at the moment. It may easily be harder than what can one think, though.

Now, if someone actually has a better idea, just remember this: When a buffer swap is done for the very first time, chances are that DOSBox won't stall. Rather, the GPU will stall while waiting for vertical retrace. Similarly, as sufficiently long time passes between two consecutive swaps (a bit more than the time of a single refresh), DOSBox shouldn't stall.

Joey_sw wrote:

Update: now that i've tried it, i'll reports that it has no effect for that game.
I've tried turning on/off the vsync, and tried various framecap values.
The slowdown still happen like what it was with vanilla 0.74

It may help if a few more things are tried out like, say, these:
1. Please tell your currently selected monitor's refresh rate.
2. I'm checking this as it has possibly occurred to myself beforehand: Are you editing the correct configuration file? It should be dosbox-SVN.conf when the patch is applied against a recent SVN revision.
3. Tried a different "core" setting, like core=normal or core=simple?
4. On vanilla DOSBox (without the patch), try playing with the "frameskip" setting using shortcut key combos like Ctrl+F7 and Ctrl+F8. frameskip=1 should halve the game's framerate. With the right choice (usually frameskip=1) the actual framerate should be significantly lower than the display's refresh rate, so this is a good way to test this.
5. On the patched DOSBox, have you tried different outputs? OpenGL is the most compatible across various platforms, although others may work as well.

The slowdown in Excellent Potato is caused by the game reading incorrect display timings because of the mode change delay in DOSBox; not sure how much vsync can really help with that.

There is an experimental build of 0.74 here with a workaround for a timing issue in Flashback that appears to also be effective for Excellent Potato, but it's a hack that can cause problems in other games and not a true solution to the mode change delay issue.

NY00123 wrote:

It may help if a few more things are tried out like, say, these: 1. Please tell your currently selected monitor's refresh rate. […]
Show full quote

It may help if a few more things are tried out like, say, these:
1. Please tell your currently selected monitor's refresh rate.
2. I'm checking this as it has possibly occurred to myself beforehand: Are you editing the correct configuration file? It should be dosbox-SVN.conf when the patch is applied against a recent SVN revision.
3. Tried a different "core" setting, like core=normal or core=simple?
4. On vanilla DOSBox (without the patch), try playing with the "frameskip" setting using shortcut key combos like Ctrl+F7 and Ctrl+F8. frameskip=1 should halve the game's framerate. With the right choice (usually frameskip=1) the actual framerate should be significantly lower than the display's refresh rate, so this is a good way to test this.
5. On the patched DOSBox, have you tried different outputs? OpenGL is the most compatible across various platforms, although others may work as well.

My monitor refresh rate is 60 Hz
I delete the .conf file, let the dosbox recreates it, close the dosbox, then modify the newly created file, saved the file, then re-run the dosbox.
I did try various core settings, none of them seems to affacting the game.
Output also seem doesn't matter for that game on my system.

When i was testing with vannila 0.74 before, i did use the frameskip key, it was ugly as i need to adjust the frameskip when in or out ot battle scene, even then i can't achieve the results i remembered from real system.

...
But, ripsaw8080's experimantal build works for that game.
I need to use loadfix, but its not a problem for me.
Thanks for the experintal build.

NY00123 i wanna say thanks

You build save me.I have a K7 1000 with a old sis card, and your build is the only that give me perfect vsync with surface, and incredible performace

I can play all 2/386 era games whitout problem with you build and vsync

Thanks!!

Thanks a lot, Rayman works perfectly now