Sounds like a brilliant idea, and hopefully shouldn’t be too much work.
“Video” driver is a bit of a misnomer with SDL, as they also contain the
platform-specific hooks for input and event wrangling. For that reason you
might not want to implement EGL as a whole discrete video driver per se,
but perhaps a subset of common methods that get called by the current stack
of of video drivers.
Right now, the way it works is that the top level SDL_VideoDevice struct
has pointers to the GL context handling methods in the device driver (see
http://hg.libsdl.org/SDL/file/53df899db00b/src/video/SDL_sysvideo.h#l220 ).
In the X11 driver for instance, that means _this->GL_GetProcAddress can be
set to point at X11_GL_GetProcAddress (defined in
/src/video/x11/SDL_x11opengl.c) or X11_GLES_GetProcAddress (defined in
/src/video/x11/SDL_x11opengles.c). There’s also a generic struct pointer of
type SDL_PrivateGLESData in there, which is later defined in the video
driver (e.g. /src/vide/x11/SDL_x11opengles.h) to be a container for all of
the EGL function pointers and so forth.
The tricky part is that SDL is generally not linked to WGL/GLX/GL or
EGL/GLES at compile time, but the application most likely is. And since
there’s only one set of GL context functions in SDL, and there are cases
like X11 where you can have both GLX and EGL present on the system, they
need to be pointing at the right one for the application to work properly.
For this reason there’s an SDL_GL attribute flag SDL_GL_CONTEXT_EGL, which
hints to the video driver whether to demand an EGL display and fall over if
there isn’t one.
A good place to start might be to take /src/video/x11/SDL_x11opengl.c and
try and sieve out the platform specific bits (i.e. the LoadLibrary and
GetVisual parts).
Interestingly, Canonical have been jonesing for AMD/NVIDIA to make their
Linux desktop drivers accessible through EGL. If this happens, then we
might have to do some rework to fix all the naming and remove the
assumption that EGL implies GLES.On 24 May 2013 01:01, Jos? Luis Pereira wrote:
I will start implementing in a separate EGL driver (folder). I dont have
complete knowledge on how SDL implements the video drivers, mainly how the
macro checks are working. Any recommendations?
Also, again about Android, i would say that a OpenSLES implementation
could also be very favourable for audio, however i dont have
an immediate interest on it ATM.
Best
Jos? Pereira
Personal blog http://www.onaips.com
On Thu, May 23, 2013 at 8:43 AM, Sam Lantinga wrote:
That would be great. I’d love to unify the EGL code in SDL.
Cheers!
On Thu, May 23, 2013 at 7:02 AM, Scott Smith wrote:
From: Ryan C. Gordon
To: SDL Development List
Sent: Wed, May 22, 2013 7:20:50 PM
Subject: Re: [SDL] Android EGL-fu
Is there any particular reason to use all EGL-related calls with JNI?
I’ve dug a little bit on the AOSP code, and realized that all java egl
related classes are merely a JNI wrapper to the proper EGL C library.
This means that when SDL is p.e. flipping buffers, it will go from C to
Java to C again.
This is a stupid question, but: is the EGL on Android any different from
the EGL for Pandora, or the Raspberry Pi, or Wayland or Mir (etc)?
(Beyond a few typedefs for display handles, etc.)
If this is basically all the same, I’d sorta like to move all of this to
one “egl” video target with a little bit of platform-specific glue code for
the different platform variations.
Which is to say, yes, in any case, it seems to me that less JNI is
better than more.
–ryan.
Ryan,
I think your assertion is correct. I found the EGL parts could be the
same and there are 2 platform specific parts. One to get the platform
display and the other for the platform window surface.
I have a small little project that basically shows this:
http://sourceforge.net/projects/eglport/
It support RAW framebuffer, SDL 1.2 (X) surface, and raspberry pi.
I was actually planning to incorporate this into SDL2 so that it would
better suit devices like pandora and rpi.
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
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org