Vsync Support
Moderator: ScummVM Team
Vsync Support
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?
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?
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
that post wasn't even that hard to find, looking for "tearing"
clem
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:
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
Well, I'm blank.
Didn't the originals tear during scrolling as well? I think it's charming.
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.
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.
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!
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!
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.
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.
-
- Posts: 22
- Joined: Mon Feb 23, 2009 2:59 am
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.
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.
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.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)
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.
SDL uses an ancient version of DirectX: Direct X 5.0 circa 1997. Your other option is the even more ancient GDI.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.
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.
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...BigT wrote:The devs of ScummVM do not seem very interested in adding vsync support to this program.
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.
-
- Posts: 22
- Joined: Mon Feb 23, 2009 2:59 am
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.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.
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.
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).md5 wrote: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...BigT wrote:The devs of ScummVM do not seem very interested in adding vsync support to this program.
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.
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...
...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.