Try setting frameskip=0 inside dosbox.conf

framskip is already set to 0...

doublebuffer

sorry, should have mentioned that I have doubebuffer set to true as well...no difference.

You could try using OpenGL as the output setting, or get Gulikoza's CVS and use Direct3D.

i've tried both opengl, openglnb and ddraw output modes but none have corrected the screen tearing so far, but thanks for the suggestion

strange, i tested the game in VDMSound and there is barely any screen tearing present...why is there so much in DOSBox then??

on an unrelated note, is there any way to speed up/slow down VDMSound? in DOSBox you can use the cycles, but what does VDMSound have to offer in this regard?

Does this happen with other Windows games?

Well, I havent tried many in DOSBox yet, but i sure have noticed it in Ripper

DosFreak asked about other Windows games...

oh...for Windows games I have not noticed the screen tearing issue....just noticed it in Ripper so far

so i guess there's really no other way, to correct the screen tearing issue in dosbox??

Problably they need to include better vsync code in dosbox -I notice star gunner will run like it's on fast forward cuz dosbox might be lacking a vsync timer....

is there a util out there that can run alongside DOSBox and provide v-sync capabilities??

Guest: DOSBox does not time anything based on vsync. If a game is running too fast then you need to lower the cycles. If that doesn't help then it is probably a bug that should be reported in its own thread (if there isn't one already).

pfff dosbox has a vsync emulation. don't know what you are talkign about.
maybe the game doesn't like our vsync emulation, but I won't believe that every game has problems with it.

Qbix, are u referring to the doublebuffer option? is that the vsync option?

HunterZ, its not a problem with the game running too fast so cycles have nthing to do with it....it a problem with the screen tearing (or breaking in half slightly) when you scroll side to side....

for example look at the attachment below...the black line i put in there for emphasis but it is an example of screen tearing...see how the black line splits the screen into two section? in the game it is not a black line, the line is the same color as the surroundings....

WhiteKnight: I was talking to that Guest who mentioned StarGunner.

Qbix & WhiteKnight: I think this tearing is not due to emulated vsync inside of DOSBox but rather the final rendering on the host OS side (e.g. Windows). I really think it should work to use Direct3D or OpenGL output and force vsync on in the video drivers, unless the video drivers are broken/stupid and don't do it even if you set them to. Try Gulikoza's DOSBox CVS with output=direct3d (not the same as ddraw) and make sure you have your video drivers set to force vsync enabled in Direct3D apps (not just default enabled)

I really think it should work to use Direct3D or OpenGL output and force vsync on in the video drivers, unless the video drivers are broken/stupid and don't do it even if you set them to. Try Gulikoza's DOSBox CVS with output=direct3d (not the same as ddraw) and make sure you have your video drivers set to force vsync enabled in Direct3D apps (not just default enabled)

I haven't tried this out, but I'll add to this discussion...

Does the implementation of vsync emulation reference my real display driver's vsync status, or does it simply use a timer appropriate to the current state of the emuated graphics mode? If no great care is taken to play nicely with my real display driver's state of refresh, then the latter would lead to a tear-line drifting up or down the screen corresponding to the slight discrepancy between the state of the emulated display and my real display's state of refresh (and this is in the ideal case where the real hardware's refresh rate is set to basically the same frequency as the emulated one).

Not knowing how it currently works, I think it would be best to make both implementations available. The former would be best for the most faithful emulation (most compatible), and the latter would be best for the smoothest rendering (lovely, and good for most people).

(There may also be the possibility of other options that make an effort to make an intelligent decision, or to mostly do the former but also avoid any tearing on the real display.. but I think it's best to keep the option transparent and in the hands of the user)