Vsync Support

General chat related to ScummVM, adventure gaming, and so on.

Moderator: ScummVM Team

BigT
Posts: 13
Joined: Sun Jul 15, 2007 9:22 pm

Vsync Support

Post by BigT »

I've tried a few games (Broken Sword, Dig, Full Throttle, COMI, the 2 indy games, etc.) in ScummVM and they all display visual tearing (http://en.wikipedia.org/wiki/Page_tearing). It's easily noticable with any scrolling or animation. Is there a way to turn on vsync within ScummVM to eliminate these artifacts?

I'm using the 0.X.0 Windows build. Also using an X800XT Ati video card on a Dell 2001fp monitor. Forcing vsync in drivers works for all Direct3D and OpenGL programs, but not ScummVM, presumably because it uses SDL/DirectX.

Did I miss some setting? Is this feature simply unavailable?
clem
Posts: 2159
Joined: Mon Oct 31, 2005 11:14 am

Post by clem »

seems to be related to http://forums.scummvm.org/viewtopic.php ... ht=tearing

that post wasn't even that hard to find, looking for "tearing"

clem
BigT
Posts: 13
Joined: Sun Jul 15, 2007 9:22 pm

Post by BigT »

Yeah, I know, I did a search and found two relevant threads. One from a year ago that got no replies and the one you linked.

As you can see, I even made a post in the thread you linked several days ago. I waited for any update or reply. However, it is in that Other Ports section, which very few people seem to read (there hasn't been a post made in that section for about a week). Plus that post was more geared to the Mac OSX port, while I am reporting that the same graphical issue is present in the Windows port.

Are there any SDL experts here? I'm pretty clueless when it comes to SDL. A quick search of SDL documents shows that setting up wait for vblank is possible:

Code: Select all

SDL_Flip
Name
SDL_Flip -- Swaps screen buffers
Synopsis


#include "SDL.h"

int SDL_Flip(SDL_Surface *screen);

Description

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. On hardware that doesn't support double-buffering, this is equivalent to calling SDL_UpdateRect(screen, 0, 0, 0, 0)

The SDL_DOUBLEBUF flag must have been passed to SDL_SetVideoMode, when setting the video mode for this function to perform hardware flipping.
Return Value

This function returns 0 if successful, or -1 if there was an error.
See Also

SDL_SetVideoMode, SDL_UpdateRect, SDL_Surface
User avatar
thanius
Posts: 75
Joined: Sat Jun 30, 2007 12:42 pm

Well, I'm blank.

Post by thanius »

Didn't the originals tear during scrolling as well? I think it's charming.
fingolfin
Retired
Posts: 1452
Joined: Wed Sep 21, 2005 4:12 pm

Post by fingolfin »

Yes, we are aware of the problem. No, the vsync issue is far more complicated than just switching to SDL_Flip. No, there is no trivial solution in general. Yes, it will require changes to SDL, not ScummVM, at least for the OS X port.

But yes, in the Windows specific case, there might be a workaround (I can't test it, lacking a Windows machine): Try setting the SDL_VIDEODRIVER environment variable to "directx" to enable the DirectX driver in SDL. Some people claim that this solves the tearing issues.

Luckily, in SDL 1.3 aka 2.0, this should be fixed, at least on the Mac OS X port, probably also on the Windows port (I can't test that, so I don't know for sure). But it's rather unclear when/if that will be released... could easily be another year.

In the meantime, you could also play in windowed mode, then no tearing should occur.
BigT
Posts: 13
Joined: Sun Jul 15, 2007 9:22 pm

Post by BigT »

Awesome, you guys are great.

I will try to play around with the environment vars when I have some free time and I'll post any results.

Thanks again!
Mr_Nutz
Posts: 32
Joined: Sat Jun 23, 2007 7:14 pm

Post by Mr_Nutz »

sorry to bump and old thread, but having set the enviroment variable SDL_VIDEODRIVER to directx, I get THE SAME tearing as before (in the windows version, that's it!).
My chipset is intel GMA 950. Other SDL programs souch as DOSBOX DO VYSNC well.
Can you please test that solution, guys? And NO, DOTT did not tear in MS-DOS original version...

Thanks!
User avatar
raina
Posts: 237
Joined: Thu Jan 12, 2006 12:31 pm
Location: Oulu, Finland
Contact:

Post by raina »

Mr_Nutz wrote:And NO, DOTT did not tear in MS-DOS original version...
Depends on the hardware.
Mr_Nutz
Posts: 32
Joined: Sat Jun 23, 2007 7:14 pm

Post by Mr_Nutz »

well, lucas arts games didn't tear in on my ardware od any hardware I saw.
Ween didn't tear in the scrolling part of the intro.
etc...

If there's a way to turn on vsync on the Windows port, I want to know it.
Other ports NOT SDL-BASED look just GREAT with vsync on! (GAME CUBE).
With directX as a backend (or d3d, or opengl...), SDL must be able to vsync somehow.
ancalimonungol
Posts: 22
Joined: Mon Feb 23, 2009 2:59 am

Post by ancalimonungol »

Even if there was a way to enable vsync, scrolling wouldn't be proper. (with PC games that used smooth scrolling, or Amiga games)

Because on Amiga smooth scrolling was tied to 50hz Pal. If your monitor can't do 50hz, than there is no way to achieve smooth scrolling. With many PC games, there was always screen tearing and scrolling usually wasn't smooth. (never seen smooth scrolling on a dos game)

But as far as I remember there was a VESA standard for PC games but can't remember the refresh rates.

You can use the utility PowerStrip to change your refresh rates. But make sure your monitor has protection against unsupported refresh rates.
User avatar
Freddo
Posts: 287
Joined: Mon Oct 31, 2005 4:41 pm

Post by Freddo »

ancalimonungol wrote:Even if there was a way to enable vsync, scrolling wouldn't be proper. (with PC games that used smooth scrolling, or Amiga games)
That's not really true. Sure, the Amiga ran at 50Hz, but if it's run at 60Hz instead it just means it's slightly faster, the scrolling will still be very smooth.

The amiga smooth scrolling wasn't tied to 50hz Pal. It just used the amiga hardware (which truely excelled at scrolling thanks to the planar modes compared to the modern graphic cards that use chunky modes that are less scroll friendly) and the vsync for double buffering. Be it 50Hz or 60Hz, it doesn't matter.

I often ran my Amiga with 60Hz NTSC screen instead cause then the game would run faster. And the scrolling was still very smooth and without tearing.
BigT
Posts: 13
Joined: Sun Jul 15, 2007 9:22 pm

Post by BigT »

Mr_Nutz wrote:well, lucas arts games didn't tear in on my ardware od any hardware I saw.
Ween didn't tear in the scrolling part of the intro.
etc...

If there's a way to turn on vsync on the Windows port, I want to know it.
Other ports NOT SDL-BASED look just GREAT with vsync on! (GAME CUBE).
With directX as a backend (or d3d, or opengl...), SDL must be able to vsync somehow.
SDL uses an ancient version of DirectX: Direct X 5.0 circa 1997. Your other option is the even more ancient GDI.

There are tools available to force vsync in DirectDraw or Direct3D... but they don't work for such an old version of DirectX rendering... http://www.guru3d.com/index.php?page=rivatuner D3Doverrider can force triple buffering and vsync.

The devs of ScummVM do not seem very interested in adding vsync support to this program.
User avatar
md5
ScummVM Developer
Posts: 2250
Joined: Thu Nov 03, 2005 9:31 pm
Location: Athens, Greece

Post by md5 »

BigT wrote:The devs of ScummVM do not seem very interested in adding vsync support to this program.
We are interested, but noone wants to work on this. Plus, it's a feature more targeted for SDL, rather than ScummVM itself (i.e. it's best to tell all this to the SDL people). If you do want to add vsync support, you can always contribute to the project yourself, and work on it. But then again, most people prefer to demand rather than contribute, cause demanding is easy...

We do all this in our spare time, you know, so, if noone wants to work on this feature, that's too bad. Kindly, do not respond like this, it's really not helpful, not at all. You're not paying anything for all this, so don't expect to have developers jump through hoops to satisfy everyone's needs.
ancalimonungol
Posts: 22
Joined: Mon Feb 23, 2009 2:59 am

Post by ancalimonungol »

Freddo wrote:The amiga smooth scrolling wasn't tied to 50hz Pal. It just used the amiga hardware (which truely excelled at scrolling thanks to the planar modes compared to the modern graphic cards that use chunky modes that are less scroll friendly) and the vsync for double buffering. Be it 50Hz or 60Hz, it doesn't matter.

I often ran my Amiga with 60Hz NTSC screen instead cause then the game would run faster. And the scrolling was still very smooth and without tearing.
Truth is when you run games that are made for PAL at 60hz NTSC, everything will be faster including music. And that is never desirable and the games were not meant to be played that way. For example if you run a Pal(50hz) game using WinUAE at a resolution with 60hz refresh rate, the game will not run faster but scrolling will be jumpy including any moving object (mouse pointer as well) The only and only way to play pal games is by using a resolution that is 50hz. It took me a year to find a solution to this. On an Amiga monitor (or a TV) when you run the game at 60hz NTSC screen, the TV or the monitor would sync to 60hz too meaning scrolling would be perfect. But todays monitors does always support many refresh rates if used with an Amiga. And today's operating systems are difficult to configure to support different resolutions with different refresh rates.

I think to play games using Scummvm without tearing, all you need is the correct refresh rates. Meaning the refresh rate they were meant to be played at.
You need to configure the right resolution.
BigT
Posts: 13
Joined: Sun Jul 15, 2007 9:22 pm

Post by BigT »

md5 wrote:
BigT wrote:The devs of ScummVM do not seem very interested in adding vsync support to this program.
We are interested, but noone wants to work on this. Plus, it's a feature more targeted for SDL, rather than ScummVM itself (i.e. it's best to tell all this to the SDL people). If you do want to add vsync support, you can always contribute to the project yourself, and work on it. But then again, most people prefer to demand rather than contribute, cause demanding is easy...

We do all this in our spare time, you know, so, if noone wants to work on this feature, that's too bad. Kindly, do not respond like this, it's really not helpful, not at all. You're not paying anything for all this, so don't expect to have developers jump through hoops to satisfy everyone's needs.
The comment was not meant as an attack or demand... simply pointing out that vsync support does not seam to be a priority for ScummVM (no progress on the issue for several years). :(

It's a pretty basic feature... is there any other emulator that does not support vsync? Even old dos emulators from the late 90s supported it: Nesticle, Callus, Genecyst, Magic Engine, Snes9x...

I'd love to contribute, but I haven't written a line of code since the DOS/ Watcom C days... and I know nothing about SDL or Windows programming in general... plus working 6 days and 70-90 hours per week leaves little free time... I'd have to wait until I'm unemployed... :D

...so if anyone out there knows how to work with SDL, please help out... Dosbox uses SDL and supports vsync with some workarounds!

I agree that an overhaul of SDL would be the ideal solution, but development on that doesn't exactly move very fast. :wink:
Post Reply