Hello there
I've been trying to compile SCUMMVM against SDL 1.3. Why? Because SDL 1.3 brings several alternative backends for graphics drawing. These can be acivated with the enviroment variable SDL_VIDEODRIVER, and it seems glSDL is supported in SDL 1.3.
That would fix the tearing issues we all know about, since OPENGL backend is double buffered & VSYNCED on the MAC by default.
I've followed the README and the WIKI section on OSX compiling. I've of course compiled & installed my own SDL 1.3 binaries & devel headers in UNIX style. But I'm still getting silly lexical errors on the SDL.h included with SDL 1.3 when trying to make SCUMMVM (SDL 1.3 compiled and installed fine itself).
So my question for the OSX porter is: Have you tried to compile against the most recent SDL 1.3? Can you provide binaries compiled against this new SDL version? The new backends would be faster and more advanced: just look at this:
2009-09-23 21:31:03.288 scummvm[1047:10b] Warning once: This application, or a library it uses, is using NSQuickDrawView, which has been deprecated. Apps should cease use of QuickDraw and move to Quartz.
No wonder SCUMMVM tears in OSX...it's SDL is using the ancient QuickDraw! I'm sure you can fix it very easily...
Thanks!!
Compiling on OSX against SDL 1.3
Moderator: ScummVM Team
SDL 1.2.14 actually will use CoreGraphics instead of QuickDraw. You can use SDL 1.2 SVN to get that and see if it helps at all with your visual experience.
However, note that modifications of SDL are out of *our* scope, you should ask about them with the SDL folks.
As for SDL 1.3: It is not fully compatible with SDL 1.2 (and never was meant to); one can compiles some 1.2.x apps against it, using a compatibility layer, but that doesn't always work and often incurs slowdowns. Code has to be adapted to take full advantage of SDL 1.3, too. And we won't do that until it's ready, which could take anywhere from several months to several years.
However, note that modifications of SDL are out of *our* scope, you should ask about them with the SDL folks.
As for SDL 1.3: It is not fully compatible with SDL 1.2 (and never was meant to); one can compiles some 1.2.x apps against it, using a compatibility layer, but that doesn't always work and often incurs slowdowns. Code has to be adapted to take full advantage of SDL 1.3, too. And we won't do that until it's ready, which could take anywhere from several months to several years.
Actually I'm unsure what has to be changed to do that ;-). After all it rather looks like you just need to setup your "SDL_VIDEODRIVER" to the correct output driver to achieve that.Mr_Nutz wrote:And what about moving the default SDL backend from QuickDraw to Quartz? The latest stable SDL 1.2.x releases support Quartz as rendering method. It would make SCUMMVM smoother and faster on macs: using a deprecated API isn't that good.
Anyway http://www.libsdl.org/cgi/docwiki.cgi/SDL_envvars gives the impression that (at least the last) SDL release does try to initialize Quartz output first.
So either the current release builds are made with an older version of SDL (which might be possible) or your SDL_VIDEODRIVER variable is not setup correctly.
The MAC OSX binaries are ALL compiled against an older version of libsdl.
And even worse, it's STATICALLY linked against that SDL version! So no Quartz.
A verson linked against the latest compatible SDL (1.2.x) would help, indeed. Using that OS9-like API is no good, as I pointed out.
And yes, my SDL_VIDEODRIVER is set up currectly. I can type export on my unix console...
Can you do it, mr Mac OSX porter? Please!
And even worse, it's STATICALLY linked against that SDL version! So no Quartz.
A verson linked against the latest compatible SDL (1.2.x) would help, indeed. Using that OS9-like API is no good, as I pointed out.
And yes, my SDL_VIDEODRIVER is set up currectly. I can type export on my unix console...
Can you do it, mr Mac OSX porter? Please!
It's actually statically linked for a good reason: so no one has to install a SDL library of his/her own first.
Anyway the OS X port should be definitely linked against a 1.2.x SDL. I would probably guess that the SDL version just still includes the QuickDraw use in another driver, thus you get that warning.
EDIT:
I just checked out the SDL 1.2.13 source. It seems they do use QuickDraw in their Quartz video driver too. Here's a small comment from the source code for the Quartz video driver:
So I guess the only possibility is to wait for 1.2.14. Or as Max suggested build an version yourself with the latest SDL-1.2 branch checkout.
Anyway the OS X port should be definitely linked against a 1.2.x SDL. I would probably guess that the SDL version just still includes the QuickDraw use in another driver, thus you get that warning.
EDIT:
I just checked out the SDL 1.2.13 source. It seems they do use QuickDraw in their Quartz video driver too. Here's a small comment from the source code for the Quartz video driver:
Code: Select all
/* For 2D, we set the subview to an NSQuickDrawView */
Seeing that it is only a patch level release, there should be no API changes at all, thus it should work just fine. Also it is not released yet :-), which is way Fingolfin suggested to wait for it to be released OR to use the latest checkout of the 1.2 branch (there's advice on how to get it over here: http://www.libsdl.org/svn.php).
Read again what I wrote: There is no SDL 1.2.14 yet, that'S the upcoming version! SDL on Mac OS X always had only one backend (well, if I ignore the X11 backend, at least), which is somewhat confusingly named quartz. Up to and including SDL 1.2.13, it was QuickDraw based. In current SDL SVN, some of the code has been replaced by CoreGraphics based code.
However, this SDL version HAS NOT YET BEEN RELEASED.
Of course once SDL 1.2.14 is out, we'll base our binaries on it, but until then, we won't. If you know how to compile SDL (which you seem to do, since you built 1.3 yourself), just go and get the latest SDL 1.2 SVN, compile that, and then build your own version of ScummVM against that.
However, this SDL version HAS NOT YET BEEN RELEASED.
Of course once SDL 1.2.14 is out, we'll base our binaries on it, but until then, we won't. If you know how to compile SDL (which you seem to do, since you built 1.3 yourself), just go and get the latest SDL 1.2 SVN, compile that, and then build your own version of ScummVM against that.
I compiled SCUMMVM against libSDL SVN (1.2.x branch).
It compiled right: it works right and it renders on Quartz instear of Quckdraw. No error on start anymore. But tearing is still present. Do you want the binaries to replace the one in the OSX build?
I tried playing with the SDL_SetVideoMode funtion parameters, forcing SDL_DOUBLBUF|SDL_HWSURFACE|SDL_FULLSCREEN in the video init.
It works well, no errors, but it IS NOT double-buffered: it still tears as hell. So.. do you know if it should work? Any other ideas, please? I feel we're close o fix it....
It compiled right: it works right and it renders on Quartz instear of Quckdraw. No error on start anymore. But tearing is still present. Do you want the binaries to replace the one in the OSX build?
I tried playing with the SDL_SetVideoMode funtion parameters, forcing SDL_DOUBLBUF|SDL_HWSURFACE|SDL_FULLSCREEN in the video init.
It works well, no errors, but it IS NOT double-buffered: it still tears as hell. So.. do you know if it should work? Any other ideas, please? I feel we're close o fix it....
Thank you, we don't need your binaries, we can make our owns easily .
And I am not surprised that things didn't change. I didn't expect them, using CoreGraphics does not change anything in that effect. it was all along you personal theory that QuickDraw somehow was at fault with regards to tearing.
Many people believe that using Cocoa or CoreGraphics or OpenGL magically solves tearing issues, or that double buffering does. Unfortunately, none of these appears to be unconditonally true, especially in full-screen mode :/.
.And I am not surprised that things didn't change. I didn't expect them, using CoreGraphics does not change anything in that effect. it was all along you personal theory that QuickDraw somehow was at fault with regards to tearing
.Many people believe that using Cocoa or CoreGraphics or OpenGL magically solves tearing issues, or that double buffering does. Unfortunately, none of these appears to be unconditonally true, especially in full-screen mode :/.
Here's a note on how to implement tearing free OpenGL in OS X:
http://developer.apple.com/mac/library/ ... a1385.html
The SDL folks might be willing to consider using that in SDL 1.3 (which is OpenGL based, unlike SDL 1.2), you could file a feature request on their bug tracker.
http://developer.apple.com/mac/library/ ... a1385.html
The SDL folks might be willing to consider using that in SDL 1.3 (which is OpenGL based, unlike SDL 1.2), you could file a feature request on their bug tracker.
Hey hey, mr elf, I know you can make your own binaries 
Just trying to help a little, little bit...
And about believing Quartz or OpenGL could fix tearing, it has a reason: OpenGL has vsync ON by default with a lot of OSX drivers, and most of us believe Quartz uses an OpenGL backend for graphics acceleration.
Ok, understood. SDL 1.3 then. I wonder if it will ever be released...
Thanks!
Just trying to help a little, little bit...
And about believing Quartz or OpenGL could fix tearing, it has a reason: OpenGL has vsync ON by default with a lot of OSX drivers, and most of us believe Quartz uses an OpenGL backend for graphics acceleration.
Ok, understood. SDL 1.3 then. I wonder if it will ever be released...
Thanks!
I've been looking at SLDMAME 0.134 sources: It's interesting because it makes use of openGL as it's libSDL backend, and archieves perfect scrolling with vsync. No tearing at all.
And it uses libSDL 1.2.13, the latest published stable version in the libSDL site. It uses the headers in the MscOSX framework for defines and structures.
So, fingolfin, have you looked at it? Do you think I could use the surface pointer initialization instructions to archieve a smooth-scrooling Scummmvm? what's you opinion?
thanks!
And it uses libSDL 1.2.13, the latest published stable version in the libSDL site. It uses the headers in the MscOSX framework for defines and structures.
So, fingolfin, have you looked at it? Do you think I could use the surface pointer initialization instructions to archieve a smooth-scrooling Scummmvm? what's you opinion?
thanks!