(someone can correct me if I'm wrong -- but this is as I see it)

Within DOSBox, emulated display timings exist in conjunction with the emulated video adapter, and the ports to access those values are also emulated (in our case, 0x3DA is important). Consequently, programs which depend on vsync for proper operation are able to run correctly within the DOSBox environment. However, there's nothing in place to sync this with the host display.. and so even though double buffering may prevent you from seeing tearing, you will still unavoidably get inconsistency in the duration of displayed frames in accordance with the lack of sync between host and emulated display. This means you will experience mild stuttering -- which appears much like skipping -- even though you may have your frameskip set to 0. For the most part, this isn't a big problem and few will notice.. and most mainstream software didn't rely on this anyway.. but for certain apps that rely on silky-smooth animation (through use of vsync timing), there can be a qualitative difference to the experience when it is missing.

I agree that keeping host variables out of the emulated environment as much as possible is the best way to do things during development.. but despite that, I've been working a bit on trying to get the emulated ports to use values that work best along with the host display (for example, I made use of DirectDraw's GetScanLine in triggering the emulated display's timer, and in the read of port 0x3DA -- basically, trying to implement an alternate virtual display which interfaces directly to the real display where timing is involved). Though I've had occasional short durations of silky-smoothness while working on this, that was only when I introduced the worst of temporary hacks.. and I've otherwise been messing up. I may work on this later. If someone who understands more about DOSBox's rendering would like to take a shot at this, I think they could have more success.. and I'd be happy to try and help. Hopefully it wouldn't require any big architectural change, but rather just an alternate implementation of some display timing code which could be written to be easily selectable (and perhaps just one or two serious hacks, tops 😉). I'll at least hang around #dosbox a bit on irc to maybe talk about it a bit. I've never seen anyone say anything there before.. but anyway, I'll be there.

Edit: Earlier in the thread, I mentioned Cronologia by Cascada. I think this is a bad example. It exhibits bad behaviour that I haven't seen from any other programs, and I don't have a real MSDOS environment to test it against, so perhaps DOSBox is behaving mostly correctly. So.. I've since switched to using a small (40k) old Arkanoid clone called "Bananoid" for testing, and occasionally looking at the bouncing shape in Second Reality (can be run as part "2"), which is perhaps one good goal to work towards getting to animate smoothly.

That sounds plausible. Please be aware, however, that DirectX is not platform-independent. If SDL doesn't offer such functionality, OpenGL could be employed (I know some people call OpenGL just for doing vsync, nothing else, not even displaying anything).

Ah, didn't think of using OpenGL for that. With a quick check, I didn't see anything in the SDL lib's source for vsync.. so I abstracted the code a bit and was planning to let someone else deal with other platforms 😉

In my opinion, all platform-specific code should go into SDL, because that is SDL's purpose. DOSBox would then use generic SDL calls instead of messy #ifdef stuff. IMHO there's already way too much of it in DOSBox.

Yeah, I agree about that in principle. That was my conclusion too. I'm just doing testing/experimenting though, so can use anything. Unfortunately, the reality is I haven't used cvs, sourceforge, sdl, etc. before and I'm not a Linux user, so I'll try not to get caught up in a bunch of other things to distract me. This is probably the kind of reason that causes SDL to miss out on basic features like this for so long.