Didn't notice the doublebuffer setting when I made my post... I guess that may be like one of the more complicated things I mentioned at the end of my post.. decoupling the final rendering from the emulated state. Not a bad way, though I like the simpler solutions.
(sorry for spamming the board in multiple posts.. 😀)
Following HunterZ's suggestion, I enabled vsync in my display driver and used direct3d. It makes sound skip whenever I'm in fullscreen, and I don't want to cause some extra latency through messing with the sound buffer, so I've disabled it again. Maybe the driver's sleeping the application and preventing the audio from being processed.. or something. Ah well.
wrote:(sorry for spamming the board in multiple posts.. 😀)
Well use the edit function then 😒
Try adjusting your # of cylces or frameskip.
Of course it will make DOSBox sleep. That's the point of vsync-wait (and the reason why it's called "wait"). You can't work around that one easily, unless your video hardware can do triple-buffering.
And even if inside-dosbox and outside-dosbox refresh rates (seem to) match, it won't avoid delays, because DOSBox doesn't synchronize it's internal timing with the external vsync, so it will always drift a little, causing forced waiting. Triple-buffering is the only solution, though it adds one frame of latency. (Triple buffering could be emulated via multi-thraded rendering, but that's a painful thing)
I tried Hunterz suggestion also, but I still notice the screen tearing...
Moe: In my vid card drivers, I noticed on the OpenGL tab that Triple Buffering is an option. However, on he Direct3D tab, i did not see Triple Buffering as an option. Where can I find the Triple Buffering for Direct3D?
For ATI you can't, at least as far as I know. ATI offers triple buffering only for OpenGL, and it breaks some programs.
Yeah, I understood about the 'sleep' thing. I was less sure about the terminology I was using (sleep? block? pause?), and didn't want to start thinking in detail about how sound emulation may be handled by the emulator.. preferred to figure there's something along the chain to audio output that isn't being polled often enough, and leave it at that.
What I was hinting at is that the optimal vsync solution is something that would need to be a part of DOSBos. If the vsync of the real display is similar to the emulated display mode (very likely, since ~60Hz is widespread in each), then it's quite possible to make a very nice solution that satisfies a lot of situations/people. No tearing, low latency, very low penalty to authenticity (in many cases, effectively enhancing it by reproducing the original sensation of smoothness), ah.. 😀
Maybe it's in DOSBox already in some way, but I can't find it. I got the source now, so I'll look through it. I'd like to apply gulikoza's direct3d patches first.. will be interesting since I'm not familiar with CVS.
Gulikoza releases pre-built CVS versions of DOSBox with his Direct3D patch already included. Ykhwong's builds probably have it too.
Yeah, I got his build. I'm trying to get his direct3d changes applied to my copy of the dosbox source so I can make some changes (direct3d output is my favourite -- easy to get scaling with no blurring that way). I've just finished grabbing the source through the sourceforge cvs, as opposed to the zip snapshot.. and am about to read up on applying diffs to cvs projects.. hopefully I'm on the right track 😀
I once opened up a topic for this problem and the bottom line is that it cannot be solved. Most dos games simply do not wait for vsync to refresh the picture (probably performance issues? Triple buffering was too expensive memory-wise at that time and waiting would result in worse performance). The worst case I have is Tie Fighter which updates only a few lines each frame, it needs 5 or 6 frames to completely update the screen, so 95% of the frames have tearing (and yes, I have tested this on a real machine). I'd say that when dosbox' speed increases the problem will be less visible but it will not go away.
Dosbox however does make matters slightly worse. Since it updates picture in parts, 1 frame can have 2 or 3 split parts. My D3D patch changes this to only use 1 part and vasyl recently submited a patch (it's on sourceforge) that makes some additional changes as well.
@augnober: patching shouldn't be difficult 😁. Be sure to run autogen.sh after patching (you need autoconf/autoheader installed)...
@WhiteKnight: TB cannot be forced in D3D like in OpenGL. The application has to explicitly ask for it (well, there are some tweak tools that allow you to force TB in D3D, but that is not how it should be done). My D3D patch for dosbox will activate TB when fulldouble is set to true.
I think the concept of vsync in most DOS games was meaningless due to the fact that you couldn't really do full-screen blitting on ISA video cards. I guess there was page flipping, so I probably don't really know what I'm talking about :p I do know that most older games just draw directly to the screen, so vsync is meaningless. Many other games probably didn't aim for a full 60 or so frames per second, so they probably weren't concerned with smooth graphics.
It's also definitely the case that people weren't as bothered by it back then because we weren't spoiled by hardware-accelerated 3D with vsync yet. Playing DOS games at 60Hz is even more distracting to me personally.
It's disappointing to hear about the difficulty of fixing this in DOSBox, but I very much disagree about what you guys (the past two posts 😀) are saying about DOS software. Lots of software made use of VGA scroll registers and/or pallette modification along with use of vsync timing. These things updated the whole screen immediately with very little performance cost, and then just a few small things had to be cheaply updated overtop of it. It was fully expected that this would occur without "shearing" 😀 I have a bit of a (huge) bias, because I used to watch lots of demos (future crew, etc.) and vsync'ed smoothness was the norm... and because I used vsync timing in my own stuff, and I see it crapping out when I run it in dosbox.. There were also various modex solutions that allowed large flatshaded polygons to be drawn quickly by blitting several pixels at one time. This got some games running surprisingly smoothly.
Anyway, I'm still working on getting that patch applied. I spent a while downloading cygwin last night, just to get patch.exe 😵 Hopefully that's what I'm supposed to use. I'm a little worried that I'm about to try applying the patch overtop of a cvs state that's too recent, but we'll see... I don't have a clue what you're talking about when you mention autogen.sh and autoconf/autoheader, but I'll try to learn. I'm not a *nix guy 😀
Find an example that works differently on a real computer and I'm sure someone will take a look at it 😁
You don't need cygwin, mingw has all the required utilities. I try to keep my patches updated so they apply to current cvs. There's a script named autogen.sh in the cvs you downloaded which sets all the stuff required for compilation. Or wait...are you gonna be compiling with Visual Studio? Then you don't need autoheader/autoconf, just update the project to include the new files...
Yeah, I'm compiling with Visual Studio. I'd already gotten the regular cvs to build properly (after running the gauntlet of missing components and project settings for a few hours..). It builds with a lot of warnings 😉
I got your direct3d patch applied (by renaming the dosbox directory to dosbox_org and then running "patch -p0 -i dosbox_direct3d.diff" under cygwin). I just had to manually fix 4 conflicts.. looking through the .rej, .diff, and .cpp files manually with gvim. Anyway, it wasn't hard at that point 😀 Then, manually added the few files to the src\gui\ folder of the project, added d3d9.lib and d3d9x.lib to the dependencies, defined HAVE_D3D9_H, and fixed a couple errors involving "#if" being used in the middle of an 'if-statement' (MSVC apparently doesn't like it). Then copied the applicable dll's to the Debug and Release folders, and it worked 😵
For some reason, it's never scaling in fullscreen, no matter what I set fullfixed to. I'll try to figure out what's going on. (I just got it to compile now)
Ok. The scaling works. I had an unnoticed problem with WIN32 not being defined, so certain things were compiling happily without taking in the d3d stuff, and then I'd forgotten that the description of 'fullfixed' in the conf file is reversed. So, saying you don't want it fixed in fullscreen makes it stay the same fixed size... and saying you do want it fixed lets it be scaled to fit the screen 😖
I didn't mention a couple other things I needed to do to get things working, but it was mostly due to my decision to not make many global definitions in MSVC.
Anyway, works now.. So I can mess around with stuff.
Here's an example of a demo that I think (I wish I had access to an old computer..) is timed much differently in DOSBox than in real DOS. It's the first publicly available thing I tried, since it makes massive use of scroll registers and was very smooth. It's Cronologia by Cascada. There are three download sites on this page:
http://www.mindcandydvd.com/demos
Or, here are three download links expanded (I bought the DVD, so it's okay for me to link, right? 😀):
http://www.mindcandydvd.com/demos/oldskool/Cronologia.zip
ftp://ftp.mindcandydvd.com/pub/MindCandy/Volu … /Cronologia.zip
ftp://ftp.gathering.org/Scene/MindCandy/Volum … /Cronologia.zip
The first site download site worked for me.
Anyway, I remember this as the most silky smooth thing on a 16MHz 386. You'll notice that in DOSBox, the main scroller part at the beginning runs like mad with no speed throttling. In a WinXP dosbox, though it has graphics artifacts and doesn't respond to the ESC key, it runs at the correct speed and you can generally see what's supposed to be happening. If it weren't for this, I'd have thought maybe the demo doesn't contain proper throttling. Strangely, the demo is speed-limited within DOSBox for the non-scroller parts of the demo.
Edit: I just noticed that the credits part (which begins with a bent loop of red vectorbobs) seems to use some horizontal and vertical scrolling for the credits, and is properly timed. It may be interesting to use this part for comparison.
Edit #2: Reposted with a little more info in the Games/Apps thread - Timing issue? - Cronologia by Cascada
wrote:... and then I'd forgotten that the description of 'fullfixed' in the conf file is reversed. So, saying you don't want it fixed in fullscreen makes it stay the same fixed size... and saying you do want it fixed lets it be scaled to fit the screen
Fullscreen is always [meant to be] scaled to fit the available screen area, regardless of "fullfixed" setting. With output=surface, that doesn't work, however, leading to the (unintended) behaviour you observed. Fullfixed is meant for LCD users who get better image quality by using the LCD's native resolution.
wow...never expected there'd be so many replies to this one...so any update as to whether DOSBox can properly do vsync or not?? and 3rd party tools that may work?
People have moved on to the "Optimized video output" patch 😉
I guess you can expect significant changes in rendering behaviour not too far from now. Unfortunately it seems good syncing/doublebuffering and optimized output performance don't work together.
It's only surface that has problems with double buffering and optimized scaler patch. Opengl and D3D work fine 😎. I think I'll repeat myself, dosbox can do vsync just fine, it's the games that don't wait for it.
