Same thing happens on the Windows port, which also appears to use SDL.
Tearing is present on all games I've tried. It's more noticable in certain games than others based on the type of animation used.
But nevertheless, vsync is not respected by ScummVM.
Of course, I remember that some of the original games played on original hardware did not respect vsync (e.g., COMI). But still, it would be nice to have as a feature to be able to turn on vsync.
Dosbox builds that use Direct3D for output can easily be forced to flip on vblank using a video card's control panel. SDL programs like ScummVM cannot; but, I'd bet there's a way to support vsync within the code (although I'm clueless when it comes to SDL).
ScummVM MAC OSX and VSYNC
Moderator: ScummVM Team
I am bringing back this topic because I think I've found some interesting facts:
-In Mac OSX from 10.4.x on, desktop is double-buffered, so running ScummVM in windowed mode avoids tearing in all those games we've reported.
-I think it would be TRIVIAL to add double-buffer/vsync to fullscreen mode in OSX, knowing this.
-Lots of games on mac use SDL and they don't tear at all (Jasper's Journeys, etc..)
Could that be done?
Thanks
-In Mac OSX from 10.4.x on, desktop is double-buffered, so running ScummVM in windowed mode avoids tearing in all those games we've reported.
-I think it would be TRIVIAL to add double-buffer/vsync to fullscreen mode in OSX, knowing this.
-Lots of games on mac use SDL and they don't tear at all (Jasper's Journeys, etc..)
Could that be done?
Thanks
Side-scrolling intros in:
-Ween
-Dott
-FT
Side-scrolling scenario movement in:
-Monkey Island 1, 2 & 3
-The Dig
..ETC
ALL those sequences DIDN'T tear on the original DOS versions (except for COMI, wich did tear since it didn'r respect vsync on Win95)
you can see previous posts for people who also noticed tearing in those games.
BTW, vsync has NOTHING to do with 2D or 3D: Vista Aero and OSX Aqua with Quartz extreme are both 2D desktop systems and they both have a double-buffered display TO PREVET TEARING: Tering is a problem in 2D,too. It can be seen in videos and animations on a normal Windows XP desktop.
-Ween
-Dott
-FT
Side-scrolling scenario movement in:
-Monkey Island 1, 2 & 3
-The Dig
..ETC
ALL those sequences DIDN'T tear on the original DOS versions (except for COMI, wich did tear since it didn'r respect vsync on Win95)
you can see previous posts for people who also noticed tearing in those games.
BTW, vsync has NOTHING to do with 2D or 3D: Vista Aero and OSX Aqua with Quartz extreme are both 2D desktop systems and they both have a double-buffered display TO PREVET TEARING: Tering is a problem in 2D,too. It can be seen in videos and animations on a normal Windows XP desktop.
Actually, Aero and quartz make heavy use of 3D acceleration, despite being 2D environments (just as a side remark , but of course you are right, tearing has nothing to do with 2D vs. 3D.
However, neither has double buffering, at least on its own: You can do double buffering and still will get tearing if you don't vsync. To avoid tearing you need to vsync. Although double buffering makes it easier to implement tear free drawing.
Anyway, yeah, we know all about that. Oh, and by the way, if anybody submits a patch that solves all tearing issues across all (SDL) platforms ScummVM runs on, we'll happily apply it! (Or, for that matter, one that just fixes it on a few platforms).
However, neither has double buffering, at least on its own: You can do double buffering and still will get tearing if you don't vsync. To avoid tearing you need to vsync. Although double buffering makes it easier to implement tear free drawing.
Anyway, yeah, we know all about that. Oh, and by the way, if anybody submits a patch that solves all tearing issues across all (SDL) platforms ScummVM runs on, we'll happily apply it! (Or, for that matter, one that just fixes it on a few platforms).
We have thought about OpenGL (although not really in this context); it is even on our list of open tasks.
The fact remains that somebody would have to implement it. Apparently nobody of the active team members is interested in working on this (be it tearning or OpenGL). Since we are all volunteers, we tend to only work on things that we enjoy and that benefits ourselves.
So, as long as nobody here is able to either point out an "easy" solution or provides a patch, there isn't much to discuss, everything has already been said several times by now, I think .
The fact remains that somebody would have to implement it. Apparently nobody of the active team members is interested in working on this (be it tearning or OpenGL). Since we are all volunteers, we tend to only work on things that we enjoy and that benefits ourselves.
So, as long as nobody here is able to either point out an "easy" solution or provides a patch, there isn't much to discuss, everything has already been said several times by now, I think .