Compiling on OSX against SDL 1.3

[fingolfin]

We have several threads on this forum dealing with tearing and vsync. Please search for them and read up there to find out about my opinion in more detail.

In brief, yes, it would be possible to use OpenGL with SDL (or even without SDL), but it's a major task to do that, and while it's certainly possible, nobody seems to be interested in writing that code. If you want to provide a patch, you are welcome to submit one.

[Mr_Nutz]

Correct me if I'm wrong, please:

all we need is to get an openGL surface pinter in the sdl_videodriver() call. With the SDL_OPENGLBLIT parameter, it should return a surface pointer tht sould allow normal blitting operation for 2D graphics. From the SDL documentation, for the SDL_OPENGLBLIT:

"Create an OpenGL rendering context, like above, but allow normal blitting operations. The screen (2D) surface may have an alpha channel, and SDL_UpdateRects must be used for updating changes to the screen surface."

I've tried to pass with SDL_OPENGLBLIT parametesr in the surface initialization call, I've also set up the OpenGL video attributes with SDL_GL_SetAttribute. But all I get is a white screen in windowed mode, and a black one in fullscreen mode.
What other modifications would be needed? Could the screen updates methods used be incompatible with the SDL_OPENGLBLIT surface? could be the alpha channel? I'm a bit lost, but I'll try.

Thanks

[LordHoto]

Probably using SDL_OPENGLBLIT is not a good idea because of this:

NOTE: This option is kept for compatibility only, and will be removed in next versions. Is not recommended for new code.

[Mr_Nutz]

Yes, I read that. But future versions of Scummvm will use libSDL 1.3 or whatever. We're talking about init parameters for surface creation for the actual version or next version, not future versions.

Of course you'll come with another solution for libSDL 1.3, but I don't get why you shouldn't use what we've now in the stable libSDl version. Just look at SDLMame for OSX: it's a perfect port with flawless scroll, and it uses the actual libSDL parameters. Maybe in the future they will change, but that's something to expect from a developing API like libSDL.

[LordHoto]

Actually the documentation says you shouldn't use it for new code, thus I think it would be better to follow that, since the authors probably put it there for a reason. Maybe even the implementation of that feature is buggy / slow or otherwise flawed, thus it became obsolete. All in all I personally think a "proper" OpenGL backend (which does all OpenGL access by itself, maybe only leaves the initialization to SDL or the like) would be preferable.

Also of course we can not enable SDL_OPENGLBLIT for all platforms supported by our SDL backend, since some do not feature any OpenGL acceleration at all. If we plan to use SDL_OPENGLBLIT as flag (and all additional handling of possibly screen surface alpha) it should be only conditionally compilable. Also it might be nice in some cases, where this support is compiled in, that it also might be disabled on runtime. Think of a Linux distro distributing a build with it enabled, but the user without any graphic card with OpenGL acceleration... it would be probably annoying as hell to use Mesa as a software backend, while the plain SDL backend would be so much faster. (I don't know if SDL refuses to enable that flag when only software OpenGL support is available).

Of course all that is only relevant for official inclusion in ScummVM. You are free to use that in your personal builds, but if you distribute your builds, you should follow the GPL and provide the source you build from (hopefully in a patch format, so one can easily see the changes).

EDIT:

Just look at SDLMame for OSX: it's a perfect port with flawless scroll, and it uses the actual libSDL parameters.

I don't know which sources you are talking about exactly but:
http://rbelmont.mameworld.info/sdlmame0134.zip from http://rbelmont.mameworld.info/?page_id=163 (which claims to be the official SDLMame homepage) does not use "SDL_OPENGLBLIT", but "SDL_OPENGL", which is a different flag.

Looking further at the source, it looks like they do use OpenGL directly for drawing, thus the same way as I proposed above.

[fingolfin]

Yes, I read that. But future versions of Scummvm will use libSDL 1.3 or whatever.

That's not clear yet. You are talking about a product that does not yet exist, so what you are saying is pure speculation.

We're talking about init parameters for surface creation for the actual version or next version, not future versions.

You were talking about an obsolete deprecated init parameter. Which has issues, AFAIK... But yeah, if it works that simple, we could give it a try. But apparently, in your tests it doesn't even produce sane video output, right?

Of course you'll come with another solution for libSDL 1.3, but I don't get why you shouldn't use what we've now in the stable libSDl version. Just look at SDLMame for OSX: it's a perfect port with flawless scroll, and it uses the actual libSDL parameters. Maybe in the future they will change, but that's something to expect from a developing API like libSDL.

SDLMame uses OpenGL for its graphic output, I thought (wrapped around SDL). I grabbed the latest version of their code from their website, but it seems they already switched to SDL 1.3; there they indeed offer to rendering modes, one based on pure SDL, and one based on SDL+OpenGL. Maybe that second rendering path already existed in older versions of SDLMame based on SDL 1.2 ? I can't tell, but in any case: Whatever they do, it is *not* using SDL_OPENGLBLIT .

Maybe you can point us to the version of the code you are looking at?

In any case, please stop jumping to conclusions -- because either you really know what you are talking about, and then I'd hope you'd code instead of talk (and submit a patch to us, or at least some *concrete* ways/hints to improve things). Or you are really clueless and just guessing, and in that case, well...