Pat86 wrote:

Just gave Crystal Caves a try and yes, that's some smooooth scrolling. glfullvsync=false breaks it, with an ugly tearing line. ;)

Rather, glfullvsync=true fixes it!

Diduz wrote:

First of all, thanks again to Ant_222 and YesterPlay80 for their work. :happy: I know there are various games that use differe […]
Show full quote

First of all, thanks again to Ant_222 and YesterPlay80 for their work. 😀
I know there are various games that use different refresh frequencies between menus and ingame screens. In my opinion a good game to test the effectiveness of Ant's patch should be Apogee's Crystal Caves. Yeah, this sounds a strange choice 😁 , the game is pretty choppy, but the title screen features an incredible silk-smooth EGA 60hz vertical scrolling (just wait for the screen to scroll without pressing any key). "machine=EGA" in dosbox.conf should keep the internal game screen frequency to 60hz.
60Hz is the easiest refresh to match for the vast majority of nowadays monitors, so I think this should be a good test I'm gonna try tonight. Games such as Jazz Jackrabbit are particularly complex, so I'm just afraid the results we get from their behaviour could be misleading.
Another 60hz smooth Apogee EGA game is Monster Bash.

Oh, perhaps one could match a 70hz game refresh by setting the desktop to a 70Hz resolution/refresh and then running DosBox? Just an idea. 😦

I checked Crystal Caves, its indeed very smooth (and without any tearing 😎 ) And Monster Bash too!
PS - too bad that max refresh rate of my monitor is measly 60hz

Ant_222 wrote:

Rather, glfullvsync=true fixes it!

yup! 😀

KainXVIII wrote:

And Monster Bash too!

Is it? I have a micro stutter for Monster Bash. No tearing, just a micro stutter every XY frame. Maybe it's not running on 60hz?

Pat86 wrote:

yup! :) […]
Show full quote

Ant_222 wrote:

Rather, glfullvsync=true fixes it!

yup! 😀

KainXVIII wrote:

And Monster Bash too!

Is it? I have a micro stutter for Monster Bash. No tearing, just a micro stutter every XY frame. Maybe it's not running on 60hz?

Try to increase CPU cycles. But still stutter ≠ tearing.

There are some problems with scaling with this new version... with scaler=tv2x and scaler=tv3x (untested for now scan2x and scan3x) it says 640x400 instead 320x200, and this cause an aspect ratio very wrong... only with scaler=none it works properly... this with output=openglpp

FulValBot wrote:

There are some problems with scaling with this new version... with scaler=tv2x and scaler=tv3x (untested for now scan2x and scan3x) it says 640x400 instead 320x200, and this cause an aspect ratio very wrong... only with scaler=none it works properly... this with output=openglpp

What do you mean by very wrong? What is the resolution of your display and what result do you expect? 640x400 for is correct for a 2x scaler. For ideal aspect-ratio correction you would need at least a resolution of

1640*5 x 400*6 = 3200x2400 ,

although

1640*4 x 400*5 = 2560x2000

would work too.

It stretch all images horizontally

i'm using 1920x1080

FulValBot wrote:

It stretch all images horizontally
i'm using 1920x1080

If so, it should magnify the image to:

1640x400 --[2x2]--> 1280x800

That is the correct behavior in your situation. The aspect ratio will be 8:5—wider than the correct 4:3.

Pat86 wrote:

btw is it possible to configure glfullvsync via DBGL or do i have to edit the config file manually?

DBGL supports my patch, although you might need to register the latest options yourself.

I've just tried out same games. I must say this patch is also a great way to understand if a game syncs with the refresh.
Generally speaking, it seems to me that VGA Mode 13 "chained" games did not sync with the 70hz refresh: e.g., if you choose "glfullvsync=true" on a 60hz monitor, with Monkey Island 2 or Prince of Persia (typical VGA 320x200 70 Hz games) nothing changes, no slowdown. Everything is fine. On the contrary Jazz Jackrabbit (a VGA "Mode-X" / "unchained mode" game) DOES sync with the refresh (70hz/60Hz for menu/game), so you'll get a choppy experience on a 60hz monitor when navigating the 70hz menus. The PC version of Superfrog is a 60hz Mode-X game through and through, and works great with "glfullvsync=true" 😉
As far as EGA games go, this is what I understand: if they're not synced with the refresh, you can leave the default "machine=svga_s3" in dosbox.conf. E.g. "Indiana Jones and the Last Crusade - The Graphic Adventure" (16 colors EGA version) ALWAYS works fine ("glfullvsync=true","glfullvsync=false", "machine=svga_s3", "machine=ega", no visibile change in performance). On the contrary, a more sophisticated game such as Monster Bash NEEDS "machine=ega" to force the 60hz EGA refresh when using "glfullvsync=true", otherwise you'll get a choppy performance on a 60hz monitor in svga_s3 mode (lores VGA always defaults to 70hz).
Sooooooo... I'm pretty much confirming what KainXVIII says... there's no rule 😁 , except those general guidelines I've just tried to come up with.
Let's experiment, let's have fun and again: kudos to Ant and YesterPlay! 😀

P.S.: Monster Bash works fine for me with "machine=EGA" and "glfullvsync=true". Scrolling isn't 100% smooth, but I don't remember it being extrasmooth on original machines, to be honest. Anyway, I'm sure that was one of the smoothest PC platforms ever! DosBox ECE + Ant's patch really brought me back to my 386 days.

I've tried several games (Duke3d, Shadow Warrior, Legend of Kyrandia, Kyrandia 2, Ultima VIII, Hocus Pocus, Dungeon Keeper) with openglpp and glfullvsync=true and false. Everything in fullscreen, of course. So far I've noticed zero visual or any other difference in behaviour between surfacepp with double buffering and openglpp with vsync. Likewise, I've noticed zero difference between surfacepp without double buffering and openglpp without vsync. Seems to me that double buffering in surfacepp mode essentially acts exactly the same as vsync in openglpp with exactly the same results in behaviour (like slowing down of MIDI or MT-32 music under some circumstances) and visually (removing tearing). Also AFAIK all opengl modes seem to ignore double buffering setting completely, at least I didn't notice any difference between double buffering turned on and off in these modes (unlike surface modes, where it basically acts as vsync).

syche wrote:

I've tried several games (Duke3d, Shadow Warrior, Legend of Kyrandia, Kyrandia 2, Ultima VIII, Hocus Pocus, Dungeon Keeper) with openglpp and glfullvsync=true and false. Everything in fullscreen, of course. So far I've noticed zero visual or any other difference in behaviour between surfacepp with double buffering and openglpp with vsync.

Try the menu and in-game of Jazz Jackrabbit. On my machine, surfacepp with double buffering is much heavier on the CPU than openglpp with vsync. Tested on the dial8 demo.

syche wrote:

Also AFAIK all opengl modes seem to ignore double buffering setting completely, at least I didn't notice any difference between double buffering turned on and off in these modes (unlike surface modes, where it basically acts as vsync).

Correct. DOSBox always uses OpenGL with double buffering on.

syche wrote:

Likewise, I've noticed zero difference between surfacepp without double buffering and openglpp without vsync. Seems to me that double buffering in surfacepp mode essentially acts exactly the same as vsync in openglpp with exactly the same results in behaviour (like slowing down of MIDI or MT-32 music under some circumstances) and visually (removing tearing).

Which is exactly what it's supposed to be. Except it reduces CPU load so the CPU can care more about actual emulation. 😉

Ant_222 wrote:

Try the menu and in-game of Jazz Jackrabbit. On my machine, surfacepp with double buffering is much havier on the CPU than openglpp with vsync. Tested on the dial8 demo.

Frankly, on my PC the difference is negligible to non-existant. Although, admittedly, I don't know how to measure it correctly and precisely in full screen. But both modes work just fine on my machine. Checked just now with Jazz Jackrabbit (full version) and Epic Pinball (full version). But my point was not about performance, but rather about the difference visually and in behaviour between surfacepp double buffering and openglpp vsync. These modes are practically interchangeable in this regard, i. e. there is no real difference between them (other than in performance). So everything that is problematic with surafecepp double buffering (like music slowdowns under some circumstances) stays problematic under openglpp with vsync and everything good about surfacepp double buffering (like unteared scrolling and smooth fades ins / fade outs) is likewise good under openglpp with vsync. Oh, how I wish DosBox supported borderless fullscreen, because for some reason there are much less problems when playing in windowed mode than in fullscreen, but, of course, playing in a window is not a good way to play games, in my opinion.

Ant_222 wrote:

Correct. DOSBox always uses OpenGL with double buffering on.

Ah, that explains a lot. But do you know the reason why in surface modes double buffering acts essentially as vsync?

PS Also, Jazz Jackrabbit was not Vsync-ed in the first place under real DOS. I remember it being the king of tearing among all the games I've ever played. 🤣 Not that I mind, because I hate tearing with all my heart, but for purists, who don't really know how it was back then - you should play it without all that modern bells and whistles for true experience.

syche wrote:

Oh, how I wish DosBox supported borderless fullscreen, because for some reason there are much less problems when playing in windowed mode than in fullscreen

I might get around to it.

syche wrote:

So everything that is problematic with surafecepp double buffering (like music slowdowns under some circumstances) stays problematic under openglpp with vsync

I thought that a lower CPU load with openglpp would help to keep music smooth...

syche wrote:

But do you know the reason why in surface modes double buffering acts essentially as vsync?

Yes. According to the documentation, on hardware that supports double-buffering, this function sets up a flip and returns. The hardware will wait for vertical retrace, and then swap video buffers before the next video surface blit or lock will return.

i guess most modern CPUs are capable of being nearly on pair with hardware acceleration. i guess hardware acceleration would only help people with weak cpu to gain some more performance.

Pat86 wrote:

i guess most modern CPUs are capable of being nearly on pair with hardware acceleration. i guess hardware acceleration would only help people with weak cpu to gain some more performance.

Only for simple tasks with relatively small monitors.

At least with openglpp Steam overlay (and other overlays, like MSI Afterburner) should work now, while maintaining pixel-perfect image 😎

syche wrote:

Oh, how I wish DosBox supported borderless fullscreen, because for some reason there are much less problems when playing in windowed mode than in fullscreen, but, of course, playing in a window is not a good way to play games, in my opinion.

I have just tried it, and failed. I am not sure it is at all possible in SDL 1.2. How can I align this window with the screen boundaries? Edit: This method seems to work :-) I will update the patch as time permits.

I don't know about the particulars of borderless fullscreen but when modifying SDL to get DOSBox to work on NT 3.50 I had to disable fullscreen support in SDL. So when you switch DOSBox to "fullscreen" it's a fullscreen window. You can also tell it's a window see there's no desktop icon mess or lag when switching between fullscreen and window mode and there's the DOSBox title bar at the top of the screen. Dunno if useful for your purposes since it's likely overkill but it was fun figuring it out.

See:
DOSBox Compilation Guides