I've been playing around with ScummVM on my litte MAC MINI G4 computer, and I wonder if there's some way to enable VSYNC for the games: tearing is SOOO UGLY!
What backend does the MAC OSX version use? Is it a GL aplication? Is there a way to specfy an enviroment variable to activate VSYNC in all the applications using the same backend SCUMMVM uses on the MAC OSX? (NO: it doesn't use SDL...that's fr sure: and that's great, because SDL sucks on the MAC on terms of performance...)
Thanks!
ScummVM MAC OSX and VSYNC
Moderator: ScummVM Team
You haven't noticed tearing because you haven't looked close enough: it has A LOT of tearing! TEARING is NOT the same as smoothness: the games run very smootyhly, and I can assure they don't drop any frames: It's just that SCUMMVM has NOT VSYNC enabled by default on MAC OSX (ask developers: it's not a personal impression: it's a fact) and that makes tearing appear.
I understand you don't know how to enable Vsync (as I don't know, either), but please don't assure you can't see the ugly efect, because it's, in fact, there. Thanks
I understand you don't know how to enable Vsync (as I don't know, either), but please don't assure you can't see the ugly efect, because it's, in fact, there. Thanks
Woa, I didn't look close enough and I mixed it up with smoothness? Tsk tsk, my my, and there I thought I knew what tearing is, and what vsync (=vertical retrace sync) is. I even thought that I was a developer myself, and knew how to activate VSync on various devices from the 80s, 90s and the present, including Mac OS X. Heck, I even was under the firm believe I knew how to look closely at a screen 
. Thanks for showing me the errors of my way...
Of course then again, all you said is that some unspecified version of ScummVM produces tearing with some unspecified game(s) under some unspecified conditions. Instead told us that we don't use SDL (even though we clearly do. Maybe you should learn to describe better before telling people that they are not looking close enough, hmmmm? . In particular, I still do not observe any tearing in my setup here (with Monkey Island and with FT, in windowed mode, on an external LCD).
Some background (not based on guessing, by the way, but on knowledge): All standard Mac OS X window drawing is by defaul double buffered automatically and synced to the vbl by the OS itself. However, it is possible to bypass this by using certain APIs (most notably, OpenGL, for which one has to explicitly enable it, which SDL supports; but we don't use OpenGL, so this is irrelevant). In particular, SDL calls QDFlushPortBuffer, instead of QDSetDirtyRegion. This might be the cause of sync problems, but it's not clear whether a switch would be possible w/o causing other annoying problem.
Then there is the problem that for many LCDs, the system does not use a real refresh rate (as LCDs don't use a cathode ray, so there is no actual "refresh" happening in the classical sense, nor a "vertical retrace"). This can lead to problems, too.
Finally, of course it is well-known that LCDs cause tearing effects by themselves (also visible in e.g. movie players), unless you happen to have one of those "gamer ready" ones which have extra low screen switch latencies. There is nothing ScummVM (or, for that matter, those video playback applications like QuickTime, VLC etc.) can do about that, as it's a characteristic of the screen, not the software.
I would look into this, if you could deign to lower yourself to actually describe a specific situation in which you observe tearing.
Some references:
http://developer.apple.com/documentatio ... ntent.html
http://lists.apple.com/archives/mac-ope ... 00081.html
http://lists.apple.com/archives/Mac-gam ... 00021.html
http://zuster.org/blender/drawingArchitecture.html
. Thanks for showing me the errors of my way... Of course then again, all you said is that some unspecified version of ScummVM produces tearing with some unspecified game(s) under some unspecified conditions. Instead told us that we don't use SDL (even though we clearly do
. Maybe you should learn to describe better before telling people that they are not looking close enough, hmmmm? . In particular, I still do not observe any tearing in my setup here (with Monkey Island and with FT, in windowed mode, on an external LCD).Some background (not based on guessing, by the way, but on knowledge): All standard Mac OS X window drawing is by defaul double buffered automatically and synced to the vbl by the OS itself. However, it is possible to bypass this by using certain APIs (most notably, OpenGL, for which one has to explicitly enable it, which SDL supports; but we don't use OpenGL, so this is irrelevant). In particular, SDL calls QDFlushPortBuffer, instead of QDSetDirtyRegion. This might be the cause of sync problems, but it's not clear whether a switch would be possible w/o causing other annoying problem.
Then there is the problem that for many LCDs, the system does not use a real refresh rate (as LCDs don't use a cathode ray, so there is no actual "refresh" happening in the classical sense, nor a "vertical retrace"). This can lead to problems, too.
Finally, of course it is well-known that LCDs cause tearing effects by themselves (also visible in e.g. movie players), unless you happen to have one of those "gamer ready" ones which have extra low screen switch latencies. There is nothing ScummVM (or, for that matter, those video playback applications like QuickTime, VLC etc.) can do about that, as it's a characteristic of the screen, not the software.
I would look into this, if you could deign to lower yourself to actually describe a specific situation in which you observe tearing
.Some references:
http://developer.apple.com/documentatio ... ntent.html
http://lists.apple.com/archives/mac-ope ... 00081.html
http://lists.apple.com/archives/Mac-gam ... 00021.html
http://zuster.org/blender/drawingArchitecture.html
To correct what I said about LCDs: The effect visible there is of course not the same as tearing. However its effect is very similar. The content of one (or multiple) prior frames is still visible as a "ghost" image next to the new active frame. The resulting "trail" is a close cousin of the classic "tearing", where one part of the screen shows already the new frame while another part still shows the previous frame. Only that instead of occurring along a single horizontal line, this effect now occurs in the whole image, at all spots where something moved.
Hi everyone,
I can actually confirm the tearing. On my rig it's occuring in fullscreen when the whole screen changes. Like in the DOTT intro or when scrolling.
[OS X 10.4.10 on Powerbook G4 12" + SCUMMVM 0.10.0]
http://www.250kb.de/u/070626/p/e3d55f2d.png
I can actually confirm the tearing. On my rig it's occuring in fullscreen when the whole screen changes. Like in the DOTT intro or when scrolling.
[OS X 10.4.10 on Powerbook G4 12" + SCUMMVM 0.10.0]
http://www.250kb.de/u/070626/p/e3d55f2d.png
My deepest apologies here, guys. I didn't know I was speaking to actual SCMMVM developers or people with technical knowledge far surpassing mine.
I though SCUMMVM isn't using an SDL backend on MAC OSX because I haven installed any runtime SDL libraries to run it. As for "SDL being an slow" in macosX, it's a recurrent idea on the E-UAE mailing list: E-UAE seems to have performance problems under MAC OSX because of the poor implementation of SDL.
I am not mistaking tearing for ghosting: tearing is happening with scrolling scenes in full-screen mode: but, as you said, it could be because of my monitor (a SAMSUNG 711MP LCD TV). In some other emulators (yes...I know SCUMMVM is a reimplementation of engines strictly speaking) souch as SNES9x 1.51 or E-UAE I can enable or disable VSYNC, and tearing DOES NOT ocurr with VSYNC ON, even on my monitor.
I am NOT asking for this option, nor am I asking for anything from you guys. I really appreciate the work you've done with SCUMMVM so far, and I understand you do it just for fun, as programming should always be done. I am only notifiying an annoying graphical defect. Thanks"!
I though SCUMMVM isn't using an SDL backend on MAC OSX because I haven installed any runtime SDL libraries to run it. As for "SDL being an slow" in macosX, it's a recurrent idea on the E-UAE mailing list: E-UAE seems to have performance problems under MAC OSX because of the poor implementation of SDL.
I am not mistaking tearing for ghosting: tearing is happening with scrolling scenes in full-screen mode: but, as you said, it could be because of my monitor (a SAMSUNG 711MP LCD TV). In some other emulators (yes...I know SCUMMVM is a reimplementation of engines strictly speaking) souch as SNES9x 1.51 or E-UAE I can enable or disable VSYNC, and tearing DOES NOT ocurr with VSYNC ON, even on my monitor.
I am NOT asking for this option, nor am I asking for anything from you guys. I really appreciate the work you've done with SCUMMVM so far, and I understand you do it just for fun, as programming should always be done. I am only notifiying an annoying graphical defect. Thanks"!
SDL is static linked, so you don't have to install it as an extra dependency, nor can you see it by looking at the package content. But we do mention it in the about dialog (but that's all not really important).
So, I am willing to look into this, as I am also working on SDL on occasion. But for that I need a precise description so that I can try to reproduce the game. So at least now I know you get the problem in full screen mode (do you get it in windowed mode at all?). Could you name a specific game with a specific scene? E.g. does it occur in the intros of FT or The Dig (both of which perform scrolling?).
I can't try this out right now myself as I am not near my own computer, but I'll try to look a bit at this if I can find some spare time.
So, I am willing to look into this, as I am also working on SDL on occasion. But for that I need a precise description so that I can try to reproduce the game. So at least now I know you get the problem in full screen mode (do you get it in windowed mode at all?). Could you name a specific game with a specific scene? E.g. does it occur in the intros of FT or The Dig (both of which perform scrolling?).
I can't try this out right now myself as I am not near my own computer, but I'll try to look a bit at this if I can find some spare time.
Yup,
occurs in the FT intro. Can't check The Dig, though. Sorry. But I guess it should be happening there, too.
Would be really cool if you had the time to look into this issue fingolfin. I certainly don't think of it as a major flaw, but the overall experience would sure be nicer without it...
Although, come to think of it... that would kinda break the scale of my Nice-O-Meter (TM), since SCUMMVM already is at 100% niceness.
Hope you don't mind me answering Mr_Nutz... I feel a little bit like hijacking you're discussion... it's just that I really care about this issue.
occurs in the FT intro. Can't check The Dig, though. Sorry. But I guess it should be happening there, too.
Would be really cool if you had the time to look into this issue fingolfin. I certainly don't think of it as a major flaw, but the overall experience would sure be nicer without it...
Although, come to think of it... that would kinda break the scale of my Nice-O-Meter (TM), since SCUMMVM already is at 100% niceness.
Hope you don't mind me answering Mr_Nutz... I feel a little bit like hijacking you're discussion... it's just that I really care about this issue.
No poblem at all!
I have confirmed this effect in DOTT intro, at WEEN scrolling sequence in the intro (just before Okhram appears speaking for the first time), FT, Loom intro...
In general, I would say it happens in every scrolling scene. That's why I callec it "no Vsync!".
Thanks everyone interested in this matter!
I have confirmed this effect in DOTT intro, at WEEN scrolling sequence in the intro (just before Okhram appears speaking for the first time), FT, Loom intro...
In general, I would say it happens in every scrolling scene. That's why I callec it "no Vsync!".
Thanks everyone interested in this matter!