Taff wrote:So vsync just wasn't a thing back in the days of software rendering, people just lived with screen tearing?
Didn't pretty much all dos games use software rendering? Why is there even a vsync section if nothing benefits from it?
I think that screen tearing wasn't a problem back then because hardware wasn't good enough to render more than 60fps and framerates were often capped. With the advent of 3D acceleration, games had the hardware power to push past 60fps and developers stopped capping framerates to allow for it. Daggerfall couldn't get even close to 60fps on 1996 hardware, so there wasn't a problem, but there may be if you play it on today's hardware.
It's not that you can't use vsync with software rendering--you can--but I believe that it depends on the API. For example, if a game uses DirectDraw, you can force vsync because that's an API that supports it. Direct3D and OpenGL do, as well. The thing is that most DOS games didn't use any API. They talked to the hardware directly, so there's no middle man to manipulate how the game is run. I'm taking a guess here, but my hunch is that the [vsync] section that's supported in some builds of DOSBox is intended for the few APIs that did exist for DOS, particularly Glide. There weren't that many 3Dfx-enabled DOS games, though, which could be why [vsync] isn't an option in official DOSBox (AFAIK).
All of that said, I'm no DOSBox expert and it is an emulator that acts like a middle man and can output to DirectDraw and OpenGL, so it's possible that I could be wrong and it can force vsync if you're using one of those output modes and your DOSBox build supports it. Try it, but, if it doesn't work, it could be for the reasons that I gave.