Neither has vsync been added to dosbox, nor does it work on osx afaik.

what about Linux? I know SDL 1.2.x won't let refresh rate configuration, but maybe someone god it working with vsync on dga/framebuffer/whatever...

Vsync wasnt't been added to the Windows port??? C'mon...it can't be true: the patch is there since 2005!

Then you better get to work then!

C'mon...it can't be true: the patch is there since 2005!

So what now?

I just happened to check VOGONS and see this (I haven't been back in a long while).

To my knowledge, the only person who ever released a build with my vsync patch partially applied was ykhwong (and I didn't notice it until at least several months after he had applied it (!)). Unfortunately, those builds didn't support the hotkey(s) necessary for synchronization.. so they were never able to serve the purpose that I intended. The hotkeys already seemed to be really crowded at that time.. and while developing the patch, I was actually stealing a key away from something that would be useful to some people. When I submitted the patch, I think I commented-out or removed the stealing of that hotkey.. which is probably why ykhwong's build doesn't have it enabled.

I'm not sure how much of the vsync threads you read. If you managed to find it all, then you may have noticed that I was initially intending for it to handle the synchronization automatically (ie. synced to host refresh with no hotkeys required).. and that I had something that was basically working to my satisfaction in Windows. Unfortunately, I wasn't able to get this working on Linux (or other platforms).. and I soon discovered that a Windows-specific patch would never be accepted into the official codebase (in retrospect, I should have left it alone as a Windows-specific patch.. or at least backed up my code or uploaded what I had.. but alas..). I then got a bit cheeky and decided to make it a manual process since there seemed to be no standard way to get it working on Linux. No one called me on it, and the result is that it's a pretty silly patch that only the most hardcore smooth scrolling fan could ever tolerate.

With SDL's progress in recent years, I think it would now be possible to get it working automatically across Windows, Linux (except where the driver sucks), and Mac OSX. High-precision timing on Linux may still be a bit lacking, but I have found in other testing that with a bit of persistence, such synchronization can be done usefully enough even if the timer precision sucks.

If you're able to compile the codebase and have some programming familiarity, then perhaps you can download my patch and reserve the necessary synchronization hotkeys yourself. You seem to already understand that the timing is manual and that hotkeys are required.. so you would be able to see pretty easily in the patch diff what needs to be enabled. Regarding your question about whether or not Mac OSX is supported... If you've got a working driver for your eyes and fingers, then everything is supported! (small print: provided that you got it to compile.. and things seem reasonable) That's the wonder (and horror) of the patch.

I don't really have the time to do it again right now (yeah, I'd make it a rewrite).. but perhaps some other developer will be able to take this on? Ideally someone who has a thing for smooth scrolling and some oldschool development experience involving manual vsync timing. It's a relatively straightforward task.. You can either be lucky and find that the vsync status is queryable, or not be too shy to just enable vsync and experimentally determine the flip rate yourself. The rest can be accomplished by any of an infinite array of hacky approaches.

well, nice to hear from you!

Actually, I am not interested into writing the code myself: I just hoped Vsync was supported by now. DOSBOX is a fun program, I have enough programming at work.
Most DOS games I like are AMIGA conversions. so I'll stick to UAE wich of course supports vsync on an OpenGL backend, with percfectly smooth scrolling. UAE is a lot more mature, and I just can't understand how things like tearing are ignored by most people nowadays: smooth scroll was one of the greatest things in the old days, and if DOSBOX is trying to recreate those experiences..well..I suppose it's not a mature project yet (for my needs, that's it).

I feel sorry for not contriguting, and of course I AM NOT complaining! DosBOX is great in a lot of ways, but it's focused on factors beyond my understanding, I suppose. I just want to play the way I used to...nothing more, and nothing less. But simply that: get home, fire up Jazz JackRabbit and enjoy times when programmers had precise control of timing, framebuffer, etc...

Well, smooth scrolling on DOS was an oddity, from my experiences. I used to have an A500, switched to an A2000 (great machine with lots of add-ons like turbo card, harddisk, etc.), and finally got my first PC around the time Wing Commander was released. I remember being amazed how foul the scrolling on DOS action titles was at the time. There were certain exceptions (like Turrican 2, i think), but the majority of action titles were jerkfests. It wasn't until the 2nd or 3rd generation of DirectX titles (Win9x) that smooth scrolling on the PC would be a standard. I think the Amiga was much more suited for graphical effects like smooth scrolling, because of the "defined" hardware (no great variety of CPU's, graphics cards, chipsets, etc.) and the custom chips. So i think it's a bit unfair to say WinUAE is more advanced than DOSBox, as they are emulating very, very different systems with very different abilities. WinUAE has a great UI, but it's not multiplatform. Basically, comparing these two emulators is like comparing apples to pears (both being fruit, but being different nonetheless).

Anyway, VSync support in DOSBox would be cool, of course. But: forgive me for my ignorance, but isn't it already possible to force VSync on Windows via the graphics card driver? If the game (and thus, DOSBox) outputs 60FPS, and i have a 60Hz screen (LCD), and force VSync via the graphics driver, i get near-perfect smooth scrolling, for example with Turrican 2. Isn't something like that possible on OS X?

well, I don't know how to force vsync in osx: I know my dosbox runs on opengl, but I don't know of any program to FORCE vysnc on opengl in mac osx: if someone knows about one, please tell me.

thanks!

Anyway, VSync support in DOSBox would be cool, of course. But: forgive me for my ignorance, but isn't it already possible to force VSync on Windows via the graphics card driver?

The trouble is that the host vsync isn't synchronized with the emulated vsync frequency. Some games, demos, and other programs intentionally make their changes to the visible surface during the vertical blank or just behind the scan-line which proceeds down the screen, and it can take significant time for it to draw the full scene. When the vertical syncs aren't synchronized in these cases, you can see shear lines.

In theory, if the game is using a 'mode-x' mode and flips the visible surfaces, it seems to me that it might look reasonably okay even if the vsyncs are out of sync.. since presumably the flip should be a very fast operation (and so you shouldn't see a shear line during progress). The only downside is that some frames will be drawn twice, while others will get skipped.. so the animation can't be perfectly smooth. This can be particularly noticeable as hiccups at a certain frequency during very simple constant horizontal or vertical scrolling, but would be nearly undetectable in a 3D game for example.

I used to run a lot of demoscene demos and graphics clips that I wrote myself. It seemed to me that vsync'd stuff was the norm.. but I think you're basically correct in that most major commercial games didn't sync to vsync.. or in cases where they did, it sometimes wasn't very noticeable due to the nature of the game.

If you're looking to eliminate tearing, fulldouble=true and fullscreen should do the job. If the game didn't tear on real hardware, it shouldn't tear on Dosbox. However, fulldouble seems very output/hardware/OS dependent. For me it doesn't seem to work on OSX for example, but on Windows XP it works perfectly.

I guess it's an SDL issue.

If you want to see shearing in action, try running VSYNC.COM (found in the VSYNC directory) in this archive:
download.php?id=2439

(That is a link to the vsync patch that I uploaded in 2005.. VSYNC.COM is designed to make any shearing due to lack of synchronization as obvious as possible. Disassembling it will reveal that it just waits for emulated vblank and draws a scrolling stripe pattern)

In case the link doesn't work for some reason, here is a link to the vsync patch thread in which the download link appears:
Vertical retrace sync patch

You can also try some pinball games (any of the Epic Pinball engine games is a decent example) to look for shearing. The demoscene demo Luminati by Tran is a bit of stress test too. If the sync handling is off, you'll see some nastiness (I forget what happened exactly.. but it didn't look good).

Good to hear that the vsync-problem is nagging other people too. 😉

If the game didn't tear on real hardware, it shouldn't tear on Dosbox

This is not entirely true. I depends on the type of syncing the game/demo did. I encountered some that measured vsync timing and then relied on that. The problem with those is that the timer that is used in DOSBox is not accurate enough (afair) to make them sync properly. Even the vsync path augnober made didn't work very well (maybe because of the lack of adjustment keys though).

Given that the CGA/EGA/VGA vsync frequencies and the basic frequency of a PC's interrupt timer chip are both derived (by integer multiplications and divisions) from the NTSC color carrier frequency of n = 3.57954545454... MHz, it should be possible to at least correlate the emulated vsync with the emulated timer, right? There should be exactly 17062.5 interrupt timer ticks per VGA Mode 13h frame, for example.

Or am I misunderstanding the problem?