I’ve experimented with an OpenGL implementation of the SDL 2D API,
and it seems like it would be possible to code a usable OpenGL
rendering backend for SDL. Practically all SDL applications would
work with OpenGL, and most would run much faster, BUT, there are
issues with the way SDL 1.2.x does certain things. ("Partial Locking"
of the screen surface would be very useful.) Also, it’s not
possible to transparently take advantage of interpolated
scaling/stretching in any reliable way. (My
implementation runs with NEAREST filtering for everything, which
makes it look exactly like software/2D SDL.)
Wow - you mean you have hacked an OpenGL backend for SDL? This is truly
interesting, how about making it public, or even part of SDL?
It’s included as an optional “experimental” build time option in Kobo
Deluxe v0.3, to be released RSN. (No major issues remaining; I just need
test it some on Windows as well…)
Note however, that this is a quick proof-of-concept hack, that won’t work
on any 64 bit platforms, cannot safely be mixed with SDL "add-on"
libraries, and that doesn’t even work properly in all respects.
SDL is a
very clean and powerfull library, but it’s often limited in it’s
performances by it’s backends. Having an OpenGL backend available would
virtually make hardware acceleration available to X, and would make SDL
even more portable.
Needless to mention, that anti-aliasing on the
screen surface would rock too.
There’s a major problem: It’s not possible to do transparently. Kobo
Deluxe does AA in the scaled software modes, but that requires background
tiles, fonts and sprites to be treated differently - and still, the way
tiles are handled isn’t even correct. (The engine will eventually be able
to understand and manipulate tiled map data and generate new tiles in
order to deal with that.)
I don’t know much about OpenGL itself,
but it seems to be that it’s not really good at 2D blitting, can you
confirm/infirm this?
OpenGL is excellent for 2D rendering - it’s just that it doesn’t work
at all like traditional software 2D rendering. It’s definitely possible
to come up with a 2D rendering API that would enable optimal
implementations in software as well as over various 3D acceleration API.
However, SDL wasn’t designed with that in mind, and it shows.
SDL-on-OpenGL with the 1.2.x API will have have performance/compatibility
issues, but it might still turn out to be usable - if only because h/w
accelerated rendering is so much faster than software rendering.
More specifically;
SDL-on-OpenGL: SDL software:On Monday 22 October 2001 21:48, Alexandre Courbot wrote:
Blitting from display No issues; VERY fast. No major issues.
format surfaces to
screen:
Blitting from “dynamic” First blit after mod. First blit after mod.
surfaces to screen: results in conversion results in conversion
and downloading and/or encoding
overhead. overhead.
Entire surface has to Locking a surface
be considered changed, forces unpacking of
as there is no RLE encoded surfaces.
"UpdateRects" for
normal surfaces.
Blitting from screen Depends on OpenGL Depends on target.
to surface: implementation. Usually slow due to
Generally very slow. CPU reads from VRAM.
Direct manipulation of Has to be emulated by Low bandwidth, but
VRAM frame buffer: reading the entire only pixels actually
OpenGL frame buffer accessed count.
when the screen is
locked! Dog slow.
Blitting from surface Done in software by Can be accelerated on
to surface: SDL. (Cannot be h/w some targets.
accelerated.)
Blitting to (or (What happens when you
FillRect of) areas in blit to an RLE surface?)
surfaces that are later
blitted to screen can
be optimized.
SDL_Flip(): Very fast, even if Slow when SDL has to
emulated with a back-> emulate it with a s/w
front blit in the back->front blit.
driver.
Alpha blending: Always h/w accelerated. Cannot be h/w accelerated.
Minor overhead. Massive overhead, despite
very efficient code.
Colorkey blitting: Emulated using the Can be accelerated on
alpha channel. some targets.
Minor overhead. Insignificant overhead
in software with RLE.
Memory: Temporary buffers for No “hidden” buffers.
texture conversion.
As you probably can tell by thinking some about these points, the biggest
issues are results of the possibility of SDL being used in ways that
leave our OpenGL backend with insufficient information to do it’s job
efficiently. (As when you lock the entire screen to change a few hundred
pixels directly with the CPU, forcing the OpenGL backend to grab and then
update the entire screen, as it can’t know what was actually changed.)
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -’