- Can't the blurriness of OpenGL be resolved using openglnb?
- I guess the slowdown with aspect=true comes from some form of software rendering (DirectDraw emulation probably being such an example).
- What about using OpenGL (either opengl or openglnb), disabling VSync *and* running in a non-fullscreen window? I have some feeling that the Windows compositor will apply some form of VSync independently of the program, while not having the usual slowdowns expected with DOSBox+VSync on some occassions. It may not work so well, though.

Strange coincidence that I also discovered this behavior yesterday. With vanilla Dosbox 0.74 and Dosbox daum, it's impossible to get tearing-free rendering and auto-adjusted cycles working together with any output setting. However, with NY00123's great vsync patch, ddraw and surface outputs both work perfectly without tearing and without slowing down Dosbox.

I noticed that there is something wrong with opengl+vsync many years ago with prehistorik2's hybrid logo

ripa wrote:

Strange coincidence that I also discovered this behavior yesterday. With vanilla Dosbox 0.74 and Dosbox daum, it's impossible to get tearing-free rendering and auto-adjusted cycles working together with any output setting. However, with NY00123's great vsync patch, ddraw and surface outputs both work perfectly without tearing and without slowing down Dosbox.

Two things to mention:
1. First, this is relevant to the above quote. Thanks for trying the patch out! Problem is that it can easily become (very) unusable as changes to DOSBox are being done, due to the way dual-threading is used (actually three or more as there is also a thread for the mixer callback).
2. Somehow, just as I've read your post earlier I have realized what is the actual problem discussed here. I have seen it before without knowing of any cause! Basically, if vanilla DOSBox is used with VSync and auto-adjusted cycles, motion can be more jarring. With fixed cycles it's smoother, *but* it is still working differently than intended. (You can roughly think that you force a different refresh rate in the emulated machine - although that may be very far from an accurate description of the phenomenon.)

Regardless of anything, turning vSync off solves the emulation speed problems and most DOS games run 70 FPS anyways when they themselves are vSynced, while most modern LCDs run 60 Hz, so really, I don't see this as such a glaring problem that DOSBox needs to be "fixed". What I WOULD suggest is that information about this be added to the section in the manual that talks about what to do if the gameplay is not behaving as expected. I would also suggest DOSBox attempt to force vSync off when it starts up.

Win8 only uses DWM
DWM is always vsync'd ...?

aqrit wrote:

Win8 only uses DWM
DWM is always vsync'd ...?

Good question actually...

Vertical retrace synchronization simply means drawing the frame when a vertical retrace op is in progress, so my guess is that DWM itself is not vsynced, since there's not point in doing so as it only ever updates areas that need to be updated, but that the application itself can still vSync itself and when it updates, DWM will pick up on it and redraw the inside of the window.

That's just a guess but it's what makes the most sense. (Yes, I'm aware that "sense" and "Microsoft" don't always go together.)

aqrit wrote:

Win8 only uses DWM
DWM is always vsync'd ...?

Well, quoting a guess of mine regarding that:

NY00123 wrote:

- What about using OpenGL (either opengl or openglnb), disabling VSync *and* running in a non-fullscreen window? I have some feeling that the Windows compositor will apply some form of VSync independently of the program, while not having the usual slowdowns expected with DOSBox+VSync on some occassions. It may not work so well, though.

As expected it's irrelevant when the window is a fullscreen.

Try openglnb