libSDL2.0 questions

SDL Development
1

Any guess on when libSDL2.0 will be out? My favorite game uses OpenGL, but
I want to help make it capable of playing on OpenGL ES as well.

Will it only take a few lines to change it for OpenGL or OpenGL ES and for
Windows/Mac/Linux/Android of various processor types?

With any luck, it won’t be too hard to replace the techniques that are not
OpenGL ES compliant.

I have libSDL1.2 and now the compiled libSDL2.0 on my system. I am trying
to convert a screenart project to OpenGL and OpenGL ES by using libSDL2.0,
but I keep having sefaults. My stack is corrupted. I am not having much
luck figuring it out and I am not sure how to tell it to use specifically
libSDL1.2 or libSDL2.0. Any advice?

Sorry about the first message. I could not get gmail to let me edit the
subject line when I clicked reply. This time, it is a fresh email.

2

Will it only take a few lines to change it for OpenGL or OpenGL ES and
for Windows/Mac/Linux/Android of various processor types?

Depends on the program. Modern OpenGL looks a lot like OpenGL ES
already, but if you’re converting an old fixed-function renderer to
modern GLES, you’re going to have a bad time.

SDL2 doesn’t really change what’s needed there (except perhaps the very
start where you initialize GL/GLES).

–ryan.

3

Can you give us some more detail? A good start would be the platform
you’re developing under, which game’s codebase you want to port, what
SDL and GL versions does it use, what build system (if any) you’re
using to compile things with, etc.On Mon, Aug 27, 2012 at 8:34 AM, Ryan C. Gordon wrote:

Will it only take a few lines to change it for OpenGL or OpenGL ES and
for Windows/Mac/Linux/Android of various processor types?

Depends on the program. Modern OpenGL looks a lot like OpenGL ES already,
but if you’re converting an old fixed-function renderer to modern GLES,
you’re going to have a bad time.

SDL2 doesn’t really change what’s needed there (except perhaps the very
start where you initialize GL/GLES).

–ryan.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

4

Ok. I am building using a Raspberry Pi at the moment. I see make files for
other things, but not this. It seems I need to link against source code in
/opt/vc/. This includes calling bcm_host_init() from bcm_host.h before
initializing the video so that I have OpenGL stuff available.
Unfortunately, I have always sucked at modifying makefiles and have no clue
right now about how to add this stuff to the search paths.

More info on that stuff here: http://elinux.org/RPi_VideoCore_APIs

The game I want to compile is called Eternal Lands. It plays on
Mac/Linux/Windows, but the game is hoping to expand to other devices and I
think that SDL2.0 will help with that. It uses a cmake build system. Source
can be looked at here: https://github.com/xaphier/Eternal-Lands

That Eternal Lands code link is specifically for the branch that the guy
that is working on the 3D rewrites is working in. He does have alot of work
ahead of him since the game does have a bunch of static functions and
OpenGL1.0 specific things that do not work with OpenGL2.0. I figured that I
could try to help him out some and help port it to the Raspberry Pi and
then work on helping port it to the Android operating system later. It is a
big project to say the least.

I suppose the first step is to get SDL2.0 to recognize the OpenGL ES 2.0
features that are on my Raspberry Pi. I imagine I should read this
README.porting file in the repository. Any further advice would be greatly
appreciated.

5

Which pi distribution are you running, the bsd base or the linux based one?~
Doug.
On Aug 28, 2012 1:07 PM, “Nathaniel Stenzel” wrote:

Ok. I am building using a Raspberry Pi at the moment. I see make files for
other things, but not this. It seems I need to link against source code in
/opt/vc/. This includes calling bcm_host_init() from bcm_host.h before
initializing the video so that I have OpenGL stuff available.
Unfortunately, I have always sucked at modifying makefiles and have no clue
right now about how to add this stuff to the search paths.

More info on that stuff here: http://elinux.org/RPi_VideoCore_APIs

The game I want to compile is called Eternal Lands. It plays on
Mac/Linux/Windows, but the game is hoping to expand to other devices and I
think that SDL2.0 will help with that. It uses a cmake build system. Source
can be looked at here: https://github.com/xaphier/Eternal-Lands

That Eternal Lands code link is specifically for the branch that the guy
that is working on the 3D rewrites is working in. He does have alot of work
ahead of him since the game does have a bunch of static functions and
OpenGL1.0 specific things that do not work with OpenGL2.0. I figured that I
could try to help him out some and help port it to the Raspberry Pi and
then work on helping port it to the Android operating system later. It is a
big project to say the least.

I suppose the first step is to get SDL2.0 to recognize the OpenGL ES 2.0
features that are on my Raspberry Pi. I imagine I should read this
README.porting file in the repository. Any further advice would be greatly
appreciated.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

6

I am using the debian based Raspbian distro.

7

Yep, that codebase looks like fixed-function GL with a heavy
sprinkling of immediate mode. Good luck, man!

It’s going to be a real wrench to rewrite most of that, so if you’re
going to go ahead and move from fixed-function to shaders, you might
as well make sure it’s done to the GL ES 2.0 spec. Remember that
desktop GL 2.0 will let you get away with murder, and you don’t want a
second uphill slog to port everything to mobile.

The latest hg of SDL2 shouldn’t have trouble creating a GL ES context
on the Pi, but when building you need to point out that the Broadcom
graphics libs and headers are ghetto’d off in /opt/vc. Try building
SDL2 again with the following:

…/configure CFLAGS="-I/opt/vc/include
-I/opt/vc/include/interface/vcos/pthreads" LDFLAGS="-L/opt/vc/lib"

Make sure that the “checking for OpenGL ES (EGL) support” test returns a yes.

I’ll have a stab at porting my ES-ready SDL app to the Raspberry Pi
later tonight and report back. I’m really hoping that the only
Pi-specific thing that needs to be added is a call to bcm_host_init().
It won’t be true, but hey! Hoping!On Tue, Aug 28, 2012 at 1:06 PM, Nathaniel Stenzel wrote:

Ok. I am building using a Raspberry Pi at the moment. I see make files for
other things, but not this. It seems I need to link against source code in
/opt/vc/. This includes calling bcm_host_init() from bcm_host.h before
initializing the video so that I have OpenGL stuff available. Unfortunately,
I have always sucked at modifying makefiles and have no clue right now about
how to add this stuff to the search paths.

More info on that stuff here: http://elinux.org/RPi_VideoCore_APIs

The game I want to compile is called Eternal Lands. It plays on
Mac/Linux/Windows, but the game is hoping to expand to other devices and I
think that SDL2.0 will help with that. It uses a cmake build system. Source
can be looked at here: https://github.com/xaphier/Eternal-Lands

That Eternal Lands code link is specifically for the branch that the guy
that is working on the 3D rewrites is working in. He does have alot of work
ahead of him since the game does have a bunch of static functions and
OpenGL1.0 specific things that do not work with OpenGL2.0. I figured that I
could try to help him out some and help port it to the Raspberry Pi and then
work on helping port it to the Android operating system later. It is a big
project to say the least.

I suppose the first step is to get SDL2.0 to recognize the OpenGL ES 2.0
features that are on my Raspberry Pi. I imagine I should read this
README.porting file in the repository. Any further advice would be greatly
appreciated.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

8

Yeah, the immediate mode stuff is painful.? I actually ended up writing
my own renderer, because even trying to render a few tens of thousands
of elements with the SDL API was hurting my frame rate, and I’m running
on really good hardware.

Unfortunately, what I came up with would be rather difficult to implement
in SDL, because it involves a multimap and there’s no good library support
for that in plain C.? But it’s quite possible to add a lot of optimization to the
rendering system with a minimal amount of code if you have a good
multimap available.________________________________
From: Scott Percival
To: SDL Development List
Sent: Tuesday, August 28, 2012 6:35 PM
Subject: Re: [SDL] libSDL2.0 questions

Yep, that codebase looks like fixed-function GL with a heavy
sprinkling of immediate mode. Good luck, man!

It’s going to be a real wrench to rewrite most of that, so if you’re
going to go ahead and move from fixed-function to shaders, you might
as well make sure it’s done to the GL ES 2.0 spec. Remember that
desktop GL 2.0 will let you get away with murder, and you don’t want a
second uphill slog to port everything to mobile.

The latest hg of SDL2 shouldn’t have trouble creating a GL ES context
on the Pi, but when building you need to point out that the Broadcom
graphics libs and headers are ghetto’d off in /opt/vc. Try building
SDL2 again with the following:

…/configure CFLAGS="-I/opt/vc/include
-I/opt/vc/include/interface/vcos/pthreads" LDFLAGS="-L/opt/vc/lib"

Make sure that the “checking for OpenGL ES (EGL) support” test returns a yes.

I’ll have a stab at porting my ES-ready SDL app to the Raspberry Pi
later tonight and report back. I’m really hoping that the only
Pi-specific thing that needs to be added is a call to bcm_host_init().
It won’t be true, but hey! Hoping!

On Tue, Aug 28, 2012 at 1:06 PM, Nathaniel Stenzel wrote:

Ok. I am building using a Raspberry Pi at the moment. I see make files for
other things, but not this. It seems I need to link against source code in
/opt/vc/. This includes calling bcm_host_init() from bcm_host.h before
initializing the video so that I have OpenGL stuff available. Unfortunately,
I have always sucked at modifying makefiles and have no clue right now about
how to add this stuff to the search paths.

More info on that stuff here: http://elinux.org/RPi_VideoCore_APIs

The game I want to compile is called Eternal Lands. It plays on
Mac/Linux/Windows, but the game is hoping to expand to other devices and I
think that SDL2.0 will help with that. It uses a cmake build system. Source
can be looked at here: https://github.com/xaphier/Eternal-Lands

That Eternal Lands code link is specifically for the branch that the guy
that is working on the 3D rewrites is working in. He does have alot of work
ahead of him since the game does have a bunch of static functions and
OpenGL1.0 specific things that do not work with OpenGL2.0. I figured that I
could try to help him out some and help port it to the Raspberry Pi and then
work on helping port it to the Android operating system later. It is a big
project to say the least.

I suppose the first step is to get SDL2.0 to recognize the OpenGL ES 2.0
features that are on my Raspberry Pi. I imagine I should read this
README.porting file in the repository. Any further advice would be greatly
appreciated.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

9

Yes, the plan is to use OpenGL ES 2.0 and the desktop computers would be
restricted to that. It would still be a way above what the current system
can do.

Thanks much for the compile flags.

Glad to hear there is another Raspberry Pi user on the SDL lists.

Cc:
Yep, that codebase looks like fixed-function GL with a heavy
sprinkling of immediate mode. Good luck, man!

It’s going to be a real wrench to rewrite most of that, so if you’re
going to go ahead and move from fixed-function to shaders, you might
as well make sure it’s done to the GL ES 2.0 spec. Remember that
desktop GL 2.0 will let you get away with murder, and you don’t want a
second uphill slog to port everything to mobile.

The latest hg of SDL2 shouldn’t have trouble creating a GL ES context
on the Pi, but when building you need to point out that the Broadcom
graphics libs and headers are ghetto’d off in /opt/vc. Try building
SDL2 again with the following:

…/configure CFLAGS="-I/opt/vc/include
-I/opt/vc/include/interface/vcos/pthreads" LDFLAGS="-L/opt/vc/lib"

Make sure that the “checking for OpenGL ES (EGL) support” test returns a
yes.>From: Scott Percival
To: SDL Development List
Date: Wed, 29 Aug 2012 09:35:38 +0800
Subject: Re: [SDL] libSDL2.0 questions

I’ll have a stab at porting my ES-ready SDL app to the Raspberry Pi
later tonight and report back. I’m really hoping that the only
Pi-specific thing that needs to be added is a call to bcm_host_init().
It won’t be true, but hey! Hoping!

10

Well, I gave the compile flags a shot.
I got this.
./testgles: error while loading shared libraries: libGLESv1_CM.so.1:
cannot open shared object file: No such file or directory
When I tried a symbolic link to use the /opt/vc/lib/libGLESv2.so
library (that sounds like a really bad idea that could crash stuff), I
then got the message about no matching GLX visual.

And yes, it said OpenGL ES (EGL) support test was a “yes”.
I imagine this is because I need to call the bcm function to start
everything. not sure.>…/configure CFLAGS="-I/opt/vc/include

-I/opt/vc/include/interface/vcos/pthreads" LDFLAGS="-L/opt/vc/lib"

Make sure that the “checking for OpenGL ES (EGL) support” test returns a yes.

11

From SDL/test/testgles when I use a symbolic link named
libGLESv1_CM.so.1 to /opt/vc/lib/libGLESv2.so:

Built-in video drivers: x11, dummy
Video driver: x11
Number of displays: 1
Display 0:
Current mode: 1440x900 at 0Hz, 16 bits-per-pixel (SDL_PIXELFORMAT_RGB565)
Red Mask = 0x0000f800
Green Mask = 0x000007e0
Blue Mask = 0x0000001f
Fullscreen video modes:
Mode 0: 1440x900 at 0Hz, 16 bits-per-pixel (SDL_PIXELFORMAT_RGB565)
Red Mask = 0x0000f800
Green Mask = 0x000007e0
Blue Mask = 0x0000001f
Built-in render drivers:
Renderer opengl:
Flags: 0x0000000E (Accelerated | PresentVSync | 0x00000008)
Texture formats (1): ARGB8888
Renderer opengles2:
Flags: 0x0000000E (Accelerated | PresentVSync | 0x00000008)
Texture formats (4): ABGR8888, ARGB8888, RGB888, BGR888
Renderer opengles:
Flags: 0x0000000E (Accelerated | PresentVSync | 0x00000008)
Texture formats (1): ABGR8888
Renderer software:
Flags: 0x00000009 (0x00000001 | 0x00000008)
Texture formats (8): RGB555, RGB565, RGB888, BGR888, ARGB8888,
RGBA8888, ABGR8888, BGRA8888
Couldn’t create window: Couldn’t find matching GLX visual

12

Yeah… saying it’s a bit of a mess is an understatement. The GLX
message is troubling, as that indicates that SDL is trying to fall
back on ordinary OpenGL. And the lack of a libGLESv1_CM in the path
(even just a symlink) is irritating, having the methods all glommed
together in libGLESv2 is no excuse.

I’m at the point where I can build SDL2 and my application (amazing
how long it can take to get stuff done without a LAN connection), only
EGL dies at the context creation stage. If I had to guess, it’d be
related to how SDL_x11opengles.c seems to be missing a call to
eglCreateWindowSurface. (the OMAP3 and Tegra 2 drivers don’t seem to
care)

From what I read in the literature, Broadcom haven’t added X11 window
support to their EGL library? So the expectation is to insert a chunk
of platform-specific boilerplate to call vc_dispmanx_* which manually
specifies the region of framebuffer to clobber with your 3D graphics.
And if this thread is any indicator (
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=63&t=6768 ), adding
such support has been officially written off. Not cool, Broadcom.

I’m disappointed, nearly all of blog posts I saw before about this
were along the lines of “oh I’m sure Broadcom will come up with a
proper fix, in the meantime here’s some shim code to workaround the
problem”. But if they’re not touching it, then we need to think of
which way to handle this in SDL:

1.) Make a seperate fullscreen-only SDL video driver for the Pi (very
similar to the Pandora one) that only uses X11 for input
2.) Make a huge #ifdef block in the X11 code and fill it with Broadcom
window emulation hacks, similar to
http://code.google.com/p/pingl/source/browse/src/EGLWindow.cpp
3.) Use a shim like
http://releases.merproject.org/~carsten/x11-hack-libegl , which has a
good chance of breaking Pi-ready applications

I’m thinking of trying option 1, because it’s the quickest and least
likely to mystify people. Thoughts? Suggestions?On Fri, Aug 31, 2012 at 9:08 AM, Nathaniel Stenzel wrote:

Well, I gave the compile flags a shot.
I got this.
./testgles: error while loading shared libraries: libGLESv1_CM.so.1:
cannot open shared object file: No such file or directory
When I tried a symbolic link to use the /opt/vc/lib/libGLESv2.so
library (that sounds like a really bad idea that could crash stuff), I
then got the message about no matching GLX visual.

And yes, it said OpenGL ES (EGL) support test was a “yes”.
I imagine this is because I need to call the bcm function to start
everything. not sure.

…/configure CFLAGS="-I/opt/vc/include
-I/opt/vc/include/interface/vcos/pthreads" LDFLAGS="-L/opt/vc/lib"

Make sure that the “checking for OpenGL ES (EGL) support” test returns a yes.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

13

1.) Make a seperate fullscreen-only SDL video driver for the Pi (very
similar to the Pandora one) that only uses X11 for input
2.) Make a huge #ifdef block in the X11 code and fill it with Broadcom
window emulation hacks, similar to
http://code.google.com/p/pingl/source/browse/src/EGLWindow.cpp
3.) Use a shim like
http://releases.merproject.org/~carsten/x11-hack-libegl , which has a
good chance of breaking Pi-ready applications

I’m thinking of trying option 1, because it’s the quickest and least
likely to mystify people. Thoughts? Suggestions?

I’m very interested in supporting the Raspberry Pi with SDL2 but at this
point I know very little about it besides having tried the stock Debian
distro they ship. My plan was to eventually use the library via DirectFB
and OpenGLES2, skipping X11 entirely…would this approach work (at least
in theory)?

Gabriel.>

On Fri, Aug 31, 2012 at 9:08 AM, Nathaniel Stenzel wrote:

Well, I gave the compile flags a shot.
I got this.
./testgles: error while loading shared libraries: libGLESv1_CM.so.1:
cannot open shared object file: No such file or directory
When I tried a symbolic link to use the /opt/vc/lib/libGLESv2.so
library (that sounds like a really bad idea that could crash stuff), I
then got the message about no matching GLX visual.

And yes, it said OpenGL ES (EGL) support test was a “yes”.
I imagine this is because I need to call the bcm function to start
everything. not sure.

…/configure CFLAGS="-I/opt/vc/include
-I/opt/vc/include/interface/vcos/pthreads" LDFLAGS="-L/opt/vc/lib"

Make sure that the “checking for OpenGL ES (EGL) support” test returns a
yes.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
Gabriel.

14

Depends on the program. Modern OpenGL looks a lot like OpenGL ES already,
but if you’re converting an old fixed-function renderer to modern GLES,
you’re going to have a bad time.

But actual android & ios games, use the fixed function pipeline with GL ES
1.1 or the modern API with GLES 2.0?

GLES 2.0 is supported only from 3GS+ on ios, and 2.2 on android, isn’t it?–
Ing. Gabriele Greco, DARTS Engineering
Tel: +39-0100980150 Fax: +39-0100980184
s-mail: Piazza Della Vittoria 9/3 - 16121 GENOVA (ITALY)