IMHO OpenGL is the best 2D API for Linux, was Re: SDL1.3 - surface for created windows?

SDL Development
1

Thanks for pointing that out.

Since I left university (1999), I was forced to move slowly back into
Windows as
my main OS, because of some of my hobbies. So I tend not to follow all Linux
developments
as I used to.

I assume that the only way to manage 2D acceleration in Linux would be with
the
XRender extension, right?

Actually, the best way to make sure you have hardware acceleration
under X is still to use OpenGL. :slight_smile:
In '99 setting up 3D graphics drivers on Linux was still fairly
difficult. For quite sometime installing the NVidia drivers has been
simple and now that the ATI drivers are being/have been opened up
installing them is also simple.

The fact is that while a few Linux distribution still seem to want to
make using your computer difficult, the leading distros, especially
Ubuntu, wil detect and install all the drivers needed by your machine.
That includes the full set of the notoriously difficult 3D and
wireless drivers.

So, really, if you want to work on Linux use SDL and OpenGL and you
have full access to the abilities of your graphics card.

Pretty much everything else in X is currently up in the air. A major
redesign of everything to do with graphics acceleration and the X
server has recently been completed and work is under ways to move X
toward “the promised land” :slight_smile: The glory of open source is that it is
not a product, but a process. The main problem with open source is
that it is not a product, but a process


Right now on Linux, OpenGL works, it works very well, accelerated
OpenGL is ubiquitous and supported by all the major 3D graphics
vendors.

So, I for one, wouldn’t mess with anything else.

I know that a lot of people seem to have trouble with the idea of
using a 3D API for 2D work. (I am not directing this at you, or any
one in specific.) Usually, I hear that it seems rather heavy for the
job. They are worried about weighing down their code with slow 3D
operations when they want quick 2D operations. The logic seems
reasonable because 3D is harder to do than 2D. The reality is that
your computer probably has 10s to 100s or special purpose processors
designed to off load that “heavy” work. The graphics processor on a
modern PC may well out perform the main CPU on floating pointer
operations by a factor of several hundred to several thousand times.
It is sort of like find out that your 1968 VW bug has a Mac truck in
the trunk
 Which is very handy when you find you need to haul
several tons of rocks, but how did it get in there
?

Not suggesting, just asking, how would people like a simple 2D API
that is compatible with SDL but uses OpenGL for all operations. What
would you want in it? And, most importantly, what would be in it that
isn’t already in SDL?

Bob PendletonOn Sat, May 9, 2009 at 12:02 PM, Paulo Pinto wrote:

–
Paulo

On Fri, May 8, 2009 at 11:41 PM, Pierre Phaneuf wrote:

Many of the old 2D acelerated operations are no longer there. If you are
lucky you’ll get hardware cursors and the most common GUI operations
accelerated,
everything else are pure 3D operations.

Note that in games, 2D acceleration was very rarely used! SDL could
use it, mostly on Windows with the DirectDraw backend, but it’s been
replaced by a pretty much entirely software GDI backend. It was pretty
awful, though, having a game that would work fine on Windows, then
boot into Linux on the same machine and have it be unbearably slow

So you just had to do like everyone, assume no acceleration and code
like the good old DOS days!

–
http://pphaneuf.livejournal.com/

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

–
±----------------------------------------------------------

2

Actually, the best way to make sure you have hardware acceleration
under X is still to use OpenGL. :slight_smile:

Because if a user doesn’t have it, they’ll ditch your game after about
15 seconds, and most because your app will be so sluggish, they might
have some trouble quitting it!

In '99 setting up 3D graphics drivers on Linux was still fairly
difficult. For quite sometime installing the NVidia drivers has been
simple and now that the ATI drivers are being/have been opened up
installing them is also simple.

Installing drivers is one thing, but we’ve still got a long tail of
computers that don’t have the hardware at all. I have an older laptop
here that’s still quite usable and otherwise nice (a Toshiba R100),
which has a Trident Cyberblade video card, which gets you nowhere at
all with OpenGL.

Make no mistake, it’s definitely where this is going (with even cell
phones starting to get 3D hardware!), but you still have to think of
who you’re targeting for a particular game. Some games need to have
low requirement for a wide reach, others can afford to require the 3D
hardware. If yours is in the latter category, by all means,
OpenGL-based rendering is totally the way!

I’ve got to say that I really love Intel’s GMA, for being in the
process of putting 3D hardware in everything, down to my bloody
toaster oven. They might be really iffy for actual 3D work, but they
work beautifully for 2D-with-3D work! They’re almost done, too, so I
expect what I just wrote should be obsolete within a couple of years,
even for the low-end games
 Oh, and Vista, too, for upping hardware
requirements right into the stratosphere.On Sun, May 10, 2009 at 2:47 PM, Bob Pendleton wrote:

–
http://pphaneuf.livejournal.com/

3

Ideally it’d be nice to have a 2D API which is transparent for the user that 3D is used behind. Just the same way opengl does it, but with 2D primitives 

I imagine something like

glBegin(segment)
point(a)
point(b)
glEnd(segment)

:smiley: that’s a crappy example of course

I wish I didn’t send this amateur message :smiley:

Julien

— En date de?: Lun 11.5.09, Pierre Phaneuf a ?crit?:de: Pierre Phaneuf
Objet: Re: [SDL] IMHO OpenGL is the best 2D API for Linux, was Re: SDL1.3 - surface for created windows?
?: “A list for developers using the SDL library. (includes SDL-announce)”
Date: Lundi 11 Mai 2009, 10h56

On Sun, May 10, 2009 at 2:47 PM, Bob Pendleton wrote:

Actually, the best way to make sure you have hardware acceleration
under X is still to use OpenGL. :slight_smile:

Because if a user doesn’t have it, they’ll ditch your game after about
15 seconds, and most because your app will be so sluggish, they might
have some trouble quitting it!

In '99 setting up 3D graphics drivers on Linux was still fairly
difficult. For quite sometime installing the NVidia drivers has been
simple and now that the ATI drivers are being/have been opened up
installing them is also simple.

Installing drivers is one thing, but we’ve still got a long tail of
computers that don’t have the hardware at all. I have an older laptop
here that’s still quite usable and otherwise nice (a Toshiba R100),
which has a Trident Cyberblade video card, which gets you nowhere at
all with OpenGL.

Make no mistake, it’s definitely where this is going (with even cell
phones starting to get 3D hardware!), but you still have to think of
who you’re targeting for a particular game. Some games need to have
low requirement for a wide reach, others can afford to require the 3D
hardware. If yours is in the latter category, by all means,
OpenGL-based rendering is totally the way!

I’ve got to say that I really love Intel’s GMA, for being in the
process of putting 3D hardware in everything, down to my bloody
toaster oven. They might be really iffy for actual 3D work, but they
work beautifully for 2D-with-3D work! They’re almost done, too, so I
expect what I just wrote should be obsolete within a couple of years,
even for the low-end games
 Oh, and Vista, too, for upping hardware
requirements right into the stratosphere.

–
http://pphaneuf.livejournal.com/

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

4

Ideally it’d be nice to have a 2D API which is transparent for the user that
3D is used behind. Just the same way opengl does it, but with 2D primitives

From what I understand, that’s pretty much precisely what SDL 1.3 does
with the OpenGL renderer backend. :slight_smile:

That’s why you’ve got to use static textures rather than streamable
and locking, if possible, because that OpenGL readback performance (or
lack thereof), it hurts
On Mon, May 11, 2009 at 5:06 AM, julien CLEMENT wrote:

–
http://pphaneuf.livejournal.com/

5

In '99 setting up 3D graphics drivers on Linux was still fairly
difficult. For quite sometime installing the NVidia drivers has been
simple and now that the ATI drivers are being/have been opened up
installing them is also simple.

Installing drivers is one thing, but we’ve still got a long tail of
computers that don’t have the hardware at all. I have an older laptop
here that’s still quite usable and otherwise nice (a Toshiba R100),
which has a Trident Cyberblade video card, which gets you nowhere at
all with OpenGL.

That brings back some memories. My fist latptop, a Toshiba CDT 4070 also
with a Cyberblade video card only had Win98 D3D (DX5 level) drivers. So in
Windows
2000 and Linux I had to live with 2D only support.

For me Trident always left a bad impression with their products.

Make no mistake, it’s definitely where this is going (with even cell
phones starting to get 3D hardware!), but you still have to think of
who you’re targeting for a particular game. Some games need to have
low requirement for a wide reach, others can afford to require the 3D
hardware. If yours is in the latter category, by all means,
OpenGL-based rendering is totally the way!

Completly true. I always see people trying to give every last drop of
performance from a given system, when actually for some types of
games it doesn’t actually matter at all.

I’ve got to say that I really love Intel’s GMA, for being in the
process of putting 3D hardware in everything, down to my bloody
toaster oven. They might be really iffy for actual 3D work, but they
work beautifully for 2D-with-3D work! They’re almost done, too, so I
expect what I just wrote should be obsolete within a couple of years,
even for the low-end games
 Oh, and Vista, too, for upping hardware
requirements right into the stratosphere.

I have been having some fun reading the Michael Abrash’s articles about
the upcoming Larrabee, lets see how it will change the computing scenario
there.On Mon, May 11, 2009 at 10:56 AM, Pierre Phaneuf wrote:

–
Paulo

6

I know that a lot of people seem to have trouble with the idea of
using a 3D API for 2D work. (I am not directing this at you, or any
one in specific.)

No problem, even though I only do graphics related stuff as an hobby. I
don’t
have such problems. :slight_smile:

I may even add, that GLSL book provides very nice examples how to use
shaders
to do image processing. Cool stuff.

Not suggesting, just asking, how would people like a simple 2D API
that is compatible with SDL but uses OpenGL for all operations. What
would you want in it? And, most importantly, what would be in it that
isn’t already in SDL?

But isn’t SDL already moving into this direction with the new OpenGL and
DirectX backends?On Sun, May 10, 2009 at 8:47 PM, Bob Pendleton wrote:

–
Paulo

7

That brings back some memories. My fist latptop, a Toshiba CDT 4070 also
with a Cyberblade video card only had Win98 D3D (DX5 level) drivers. So in
Windows 2000 and Linux I had to live with 2D only support.

That Toshiba R100 came out in 2004, and had Windows XP on it, so it’s
not old as dirt either (it’s 1 GHz I think?). It’s competitive, both
in size (wider and deeper, but much thinner!) and performance to
today’s crop of netbooks. I’m not entirely sure if that CyberBlade XP4
chip has any transistors for 3D at all, but it’s 2D blitter parts do
work fine (no Matrox G200, but that one had MAD blitter performance,
still faster than the 2D core in today’s nVidias!).

Completly true. I always see people trying to give every last drop of
performance from a given system, when actually for some types of
games it doesn’t actually matter at all.

Yep, for 2D stuff using OpenGL, you can program like a dog, and it’ll
probably be fine. And those Intel GMA’s that sweat really hard playing
Quake3 and can’t even play anything better can do it in their sleep


I have been having some fun reading the Michael Abrash’s articles about
the upcoming Larrabee, lets see how it will change the computing scenario
there.

That’s going to be good stuff. Not sure if it’ll be built-in to most
motherboards like GMA is, but it’ll be really nice and super flexible.On Mon, May 11, 2009 at 5:30 AM, Paulo Pinto wrote:

–
http://pphaneuf.livejournal.com/

8

[
]

Not suggesting, just asking, how would people like a simple 2D API
that is compatible with SDL but uses OpenGL for all operations. What
would you want in it? And, most importantly, what would be in it
that isn’t already in SDL?

Some people have been using modified versions of glSDL, which is the
SDL 2D API, with a few (OpenGL mode only) extensions:On Sunday 10 May 2009, Bob Pendleton wrote:

/*

  • Set alpha multiplier. This is multiplied with any full
  • surface alpha or alpha channels of surfaces.
  • The default value is 255, which makes glSDL render like
  • the standard SDL 2D backends, ie based only on the
  • surface settings.
  • This function affects the global state of glSDL.
  • NOTE: NOT available without OpenGL acceleration!
    */
    void glSDL_SetBlendAlpha(Uint8 alpha);

/*

  • Set color multipliers. These are multiplied with the
  • respective color channers of rendered surfaces,
  • modulating the brightness of the resulting output.
  • The default values are 255, which makes glSDL render
  • like the standard SDL 2D backends.
  • This function affects the global state of glSDL.
  • NOTE: NOT available without OpenGL acceleration!
    */
    void glSDL_SetBlendColor(Uint8 r, Uint8 g, Uint8 b);

/*

  • Set center offset in pixels for scaling and rotation.
  • The default is (0, 0), which makes surfaces rotate and
  • scale around their centers.
  • This function affects the global state of glSDL.
  • NOTE: NOT available without OpenGL acceleration!
    */
    void glSDL_SetCenter(float x, float y);

/*

  • Set rotation angle in degrees. Rotation is done around
  • the center point, which is defined as
  •  (w/2 + cx, h/2 + cy)
  • where w and h are the width and height of the source
  • surface, and cx and cy are the center offsets set by
  • glSDL_SetCenter().
  • The default value is 0.0f, which makes glSDL render
  • like a normal SDL 2D backend.
  • This function affects the global state of glSDL.
  • NOTE: NOT available without OpenGL acceleration!
    */
    void glSDL_SetRotation(float angle);

/*

  • Set scale factor. Scaling is centered around around
  • the point
  •  (w/2 + cx, h/2 + cy)
  • where w and h are the width and height of the source
  • surface, and cx and cy are the center offsets set by
  • glSDL_SetCenter().
  • The default value is 1.0f, which makes glSDL render
  • like a normal SDL 2D backend.
  • This function affects the global state of glSDL.
  • NOTE: NOT available without OpenGL acceleration!
    */
    void glSDL_SetScale(float x, float y);

/*

  • Reset glSDL global state to defaults.
    */
    void glSDL_ResetState(void);

Personally, I’d prefer something slightly more flexible than the SDL
API for rendering, more like the OpenGL style API below. (Started
hacking this in 2006, but never got around to finish it. The idea was
to implement it over OpenGL, Direct3D and software.)

/*

  • Primitives for A2D_Begin()
    */
    typedef enum
    {
    A2D_POINTS,
    A2D_LINES,
    A2D_LINE_LOOP,
    A2D_LINE_STRIP,
    A2D_TRIANGLES,
    A2D_TRIANGLE_STRIP,
    A2D_TRIANGLE_FAN,
    A2D_QUADS,
    A2D_QUAD_STRIP,
    A2D_POLYGON
    } A2D_Primitives;

/*

  • Modes for A2D_FilterMode()
    */
    typedef enum
    {
    A2D_NEAREST,
    A2D_NEAREST_MIPMAP,
    A2D_LINEAR,
    A2D_LINEAR_MIPMAP,
    A2D_CUBIC,
    A2D_CUBIC_MIPMAP
    } A2D_FilterModes;

/*

  • Modes for A2D_BlendMode()
    /
    typedef enum
    {
    A2D_OPAQUE, /     Opaque rendering /
    A2D_MASK, /     Copy if src alpha > 0 /
    A2D_SRCALPHA, /     Source alpha blending /
    A2D_DSTALPHA, /     Destination alpha blending /
    A2D_ADD, /     Additive blending /
    A2D_SUBTRACT, /     Subtractive blending /
    A2D_MODULATE /     Modulation (multiplication) */
    } A2D_BlendModes;

/*

  • Select target surface for subsequent rendering.
    */
    void A2D_Target(SDL_Surface *target);

/*

  • Select texture for subsequent rendering.
  • Pass 0 for ‘texid’ to disable texturing, for
  • same results as using an opaque white texture.
    */
    void A2D_Texture(SDL_TextureID texid);

/*

  • Set texture filtering mode.
    */
    void A2D_FilterMode(A2D_FilterModes fm);

/*

  • Set rendering blend function.
    */
    void A2D_BlendMode(A2D_BlendModes mode);

/*

  • Rendering functions
    */
    void A2D_Begin(A2D_Primitives prim);
    void A2D_Vertex(float x, float y);
    void A2D_TexCoord(float x, float y);
    void A2D_ColorRGB(float r, float g, float b);
    void A2D_ColorRGBA(float r, float g, float b, float a);
    void A2D_End(void);

/*

  • Ensure that changes to the current target surface are
  • made visible.
    */
    void A2D_Update(void);

/*

  • Quickly fill the current target surface with the
  • specified color.
    */
    void A2D_Clear(float r, float g, float b, float a);

–
//David Olofson - Programmer, Composer, Open Source Advocate

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --’

9

Not suggesting, just asking, how would people like a simple 2D API
that is compatible with SDL but uses OpenGL for all operations. What
would you want in it? And, most importantly, what would be in it
that isn’t already in SDL?

I still want to see render targets in SDL 1.3. Heck, Direct3D and OpenGL already have native support for them. For other backends, they could just be made a special type of streaming texture if no better solution is available.>----- Original Message ----

From: Bob Pendleton
Subject: Re: [SDL] IMHO OpenGL is the best 2D API for Linux, was Re: SDL1.3 - surface for created windows?

10

I still want to see render targets in SDL 1.3. ?Heck, Direct3D and OpenGL already have native support for them. ?For other backends, they could just be made a special type of streaming texture if no better solution is available.

The worst case for this would probably be blitting a static texture to
a render target where the backend doesn’t support it. You’d need to
read back the source texture into main memory to perform that blit in
software. With luck, the pixel format and pitch match and you can copy
right into the destination, but otherwise, you end up with two copies,
with one of them probably being a really slow AGP read-back


I guess you could use SDL_Surface for the things that need compositing
like that, while you’d miss out on acceleration if the hardware/API
supports it, the best/worst case variance would be much tighter, which
is a good feature too.On Mon, May 11, 2009 at 12:50 PM, Mason Wheeler wrote:

–
http://pphaneuf.livejournal.com/

11

I still want to see render targets in SDL 1.3. Heck, Direct3D and OpenGL
already have native support for them. For other backends, they could just
be made a special type of streaming texture if no better solution is available.

The worst case for this would probably be blitting a static texture to
a render target where the backend doesn’t support it. You’d need to
read back the source texture into main memory to perform that blit in
software. With luck, the pixel format and pitch match and you can copy
right into the destination, but otherwise, you end up with two copies,
with one of them probably being a really slow AGP read-back


I guess you could use SDL_Surface for the things that need compositing
like that, while you’d miss out on acceleration if the hardware/API
supports it, the best/worst case variance would be much tighter, which
is a good feature too.

True enough, but IMO that’s no reason to not include render target
functionality. The coder knows what backend he’s using, and ought to
be able to customize his drawing system accordingly. Forcing everyone
who wants to do compositing work to use software surfaces even when
they’re on a backend that supports hardware acceleration makes the
accelerated system useless.>----- Original Message ----

From: Pierre Phaneuf
Subject: Re: [SDL] IMHO OpenGL is the best 2D API for Linux, was Re: SDL1.3 - surface for created windows?

12

True enough, but IMO that’s no reason to not include render target
functionality. ?The coder knows what backend he’s using, and ought to
be able to customize his drawing system accordingly. ?Forcing everyone
who wants to do compositing work to use software surfaces even when
they’re on a backend that supports hardware acceleration makes the
accelerated system useless.

Hmm, SDL “extensions”? You could test for the feature, and use a
different code path if you want to
 On one hand, I really find it
annoying when an API is littered with extensions, which makes it hard
to code a trivial program (“oops, extension XYZ not present, alternate
code path here”), on the other hand, I find it really annoying how in
OpenGL’s core, everything always work, with no way to find out if
you’ve got a software fallback or not.

Maybe the best of both world would be to have it in the API, with the
software fallback, but have a way to check for it being supported.
Gotta be careful how this is implemented, you might want a generic
software fallback or a specialized fallback (that is software, but
specific to the backend), so whether we tell the application that it’s
accelerated should be separate from the backend telling SDL that it
can’t do it.On Mon, May 11, 2009 at 1:30 PM, Mason Wheeler wrote:

–
http://pphaneuf.livejournal.com/

13

True enough, but IMO that’s no reason to not include render target
functionality. The coder knows what backend he’s using, and ought to
be able to customize his drawing system accordingly. Forcing everyone
who wants to do compositing work to use software surfaces even when
they’re on a backend that supports hardware acceleration makes the
accelerated system useless.

Hmm, SDL “extensions”? You could test for the feature, and use a
different code path if you want to
 On one hand, I really find it
annoying when an API is littered with extensions, which makes it hard
to code a trivial program

Oh, you mean like requiring a separate DLL in order to load images
saved in any format that people actually use? Yeah, I hate when
things like that get in the way
 :-p>----- Original Message ----

From: Pierre Phaneuf
Subject: Re: [SDL] IMHO OpenGL is the best 2D API for Linux, was Re: SDL1.3 - surface for created windows?
On Mon, May 11, 2009 at 1:30 PM, Mason Wheeler <@Mason_Wheeler> wrote:

14

Den Mon, 11 May 2009 13:24:06 -0400
skrev Pierre Phaneuf :> On Mon, May 11, 2009 at 12:50 PM, Mason Wheeler wrote:

I still want to see render targets in SDL 1.3. ?Heck, Direct3D and
OpenGL already have native support for them. ?For other backends,
they could just be made a special type of streaming texture if no
better solution is available.

The worst case for this would probably be blitting a static texture to
a render target where the backend doesn’t support it. You’d need to
read back the source texture into main memory to perform that blit in
software. With luck, the pixel format and pitch match and you can copy
right into the destination, but otherwise, you end up with two copies,
with one of them probably being a really slow AGP read-back


What if there was an additional texture type? Static rendertarget
textures? If render targets are available in hardware, they’d be like
normal static textures, but if not, they’d be kept in RAM so that the
expensive download wouldn’t be necessary.

  • Gerry
15

The worst case for this would probably be blitting a static texture to
a render target where the backend doesn’t support it. You’d need to
read back the source texture into main memory to perform that blit in
software. With luck, the pixel format and pitch match and you can copy
right into the destination, but otherwise, you end up with two copies,
with one of them probably being a really slow AGP read-back


What if there was an additional texture type? Static rendertarget
textures? If render targets are available in hardware, they’d be like
normal static textures, but if not, they’d be kept in RAM so that the
expensive download wouldn’t be necessary.

I like it! That would alleviate the problem a bit.>----- Original Message ----

From: Gerry JJ
Subject: Re: [SDL] IMHO OpenGL is the best 2D API for Linux, was Re: SDL1.3 - surface for created windows?

16

Great minds and all that
 I have a tiny 2D GL like API buried in one
of my font libraries. Its layered on top of software and OpenGL, no
DirectX.

Bob PendletonOn Mon, May 11, 2009 at 11:21 AM, David Olofson wrote:

On Sunday 10 May 2009, Bob Pendleton wrote:
[
]

Not suggesting, just asking, how would people like a simple 2D API
that is compatible with SDL but uses OpenGL for all operations. What
would you want in it? And, most importantly, what would be in it
that isn’t already in SDL?

Some people have been using modified versions of glSDL, which is the
SDL 2D API, with a few (OpenGL mode only) extensions:

/*
?* Set alpha multiplier. This is multiplied with any full
?* surface alpha or alpha channels of surfaces.
?*
?* The default value is 255, which makes glSDL render like
?* the standard SDL 2D backends, ie based only on the
?* surface settings.
?*
?* This function affects the global state of glSDL.
?*
?* NOTE: NOT available without OpenGL acceleration!
?*/
void glSDL_SetBlendAlpha(Uint8 alpha);

/*
?* Set color multipliers. These are multiplied with the
?* respective color channers of rendered surfaces,
?* modulating the brightness of the resulting output.
?*
?* The default values are 255, which makes glSDL render
?* like the standard SDL 2D backends.
?*
?* This function affects the global state of glSDL.
?*
?* NOTE: NOT available without OpenGL acceleration!
?*/
void glSDL_SetBlendColor(Uint8 r, Uint8 g, Uint8 b);

/*
?* Set center offset in pixels for scaling and rotation.
?*
?* The default is (0, 0), which makes surfaces rotate and
?* scale around their centers.
?*
?* This function affects the global state of glSDL.
?*
?* NOTE: NOT available without OpenGL acceleration!
?*/
void glSDL_SetCenter(float x, float y);

/*
?* Set rotation angle in degrees. Rotation is done around
?* the center point, which is defined as
?* ? ? ?(w/2 + cx, h/2 + cy)
?* where w and h are the width and height of the source
?* surface, and cx and cy are the center offsets set by
?* glSDL_SetCenter().
?*
?* The default value is 0.0f, which makes glSDL render
?* like a normal SDL 2D backend.
?*
?* This function affects the global state of glSDL.
?*
?* NOTE: NOT available without OpenGL acceleration!
?*/
void glSDL_SetRotation(float angle);

/*
?* Set scale factor. Scaling is centered around around
?* the point
?* ? ? ?(w/2 + cx, h/2 + cy)
?* where w and h are the width and height of the source
?* surface, and cx and cy are the center offsets set by
?* glSDL_SetCenter().
?*
?* The default value is 1.0f, which makes glSDL render
?* like a normal SDL 2D backend.
?*
?* This function affects the global state of glSDL.
?*
?* NOTE: NOT available without OpenGL acceleration!
?*/
void glSDL_SetScale(float x, float y);

/*
?* Reset glSDL global state to defaults.
?*/
void glSDL_ResetState(void);

Personally, I’d prefer something slightly more flexible than the SDL
API for rendering, more like the OpenGL style API below. (Started
hacking this in 2006, but never got around to finish it. The idea was
to implement it over OpenGL, Direct3D and software.)

/*
?* Primitives for A2D_Begin()
?*/
typedef enum
{
? ? ? ?A2D_POINTS,
? ? ? ?A2D_LINES,
? ? ? ?A2D_LINE_LOOP,
? ? ? ?A2D_LINE_STRIP,
? ? ? ?A2D_TRIANGLES,
? ? ? ?A2D_TRIANGLE_STRIP,
? ? ? ?A2D_TRIANGLE_FAN,
? ? ? ?A2D_QUADS,
? ? ? ?A2D_QUAD_STRIP,
? ? ? ?A2D_POLYGON
} A2D_Primitives;

/*
?* Modes for A2D_FilterMode()
?*/
typedef enum
{
? ? ? ?A2D_NEAREST,
? ? ? ?A2D_NEAREST_MIPMAP,
? ? ? ?A2D_LINEAR,
? ? ? ?A2D_LINEAR_MIPMAP,
? ? ? ?A2D_CUBIC,
? ? ? ?A2D_CUBIC_MIPMAP
} A2D_FilterModes;

/*
?* Modes for A2D_BlendMode()
?/
typedef enum
{
? ? ? ?A2D_OPAQUE, ? ? / Opaque rendering /
? ? ? ?A2D_MASK, ? ? ? / Copy if src alpha > 0 /
? ? ? ?A2D_SRCALPHA, ? / Source alpha blending /
? ? ? ?A2D_DSTALPHA, ? / Destination alpha blending /
? ? ? ?A2D_ADD, ? ? ? ?/ Additive blending /
? ? ? ?A2D_SUBTRACT, ? / Subtractive blending /
? ? ? ?A2D_MODULATE ? ?/ Modulation (multiplication) */
} A2D_BlendModes;

/*
?* Select target surface for subsequent rendering.
?*/
void A2D_Target(SDL_Surface *target);

/*
?* Select texture for subsequent rendering.
?* Pass 0 for ‘texid’ to disable texturing, for
?* same results as using an opaque white texture.
?*/
void A2D_Texture(SDL_TextureID texid);

/*
?* Set texture filtering mode.
?*/
void A2D_FilterMode(A2D_FilterModes fm);

/*
?* Set rendering blend function.
?*/
void A2D_BlendMode(A2D_BlendModes mode);

/*
?* Rendering functions
?*/
void A2D_Begin(A2D_Primitives prim);
void A2D_Vertex(float x, float y);
void A2D_TexCoord(float x, float y);
void A2D_ColorRGB(float r, float g, float b);
void A2D_ColorRGBA(float r, float g, float b, float a);
void A2D_End(void);

/*
?* Ensure that changes to the current target surface are
?* made visible.
?*/
void A2D_Update(void);

/*
?* Quickly fill the current target surface with the
?* specified color.
?*/
void A2D_Clear(float r, float g, float b, float a);

–
//David Olofson - Programmer, Composer, Open Source Advocate

.------- ?http://olofson.net - Games, SDL examples ?-------.
| ? ? ? ?http://zeespace.net - 2.5D rendering engine ? ? ? |
| ? ? ? http://audiality.org - Music/audio engine ? ? ? ? ?|
| ? ? http://eel.olofson.net - Real time scripting ? ? ? ? |
’-- ?http://www.reologica.se - Rheology instrumentation ?–’

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

–
±----------------------------------------------------------

17

IIRC, that’s where I got the idea to use an OpenGL style API. :wink:

I generally prefer small sets of flexible tools to large sets of
specialized tools - so no specific calls for special cases like
rectangles, circles and whatnot.

There was a time when the cost of checking for special cases motivated
hardwiring those choices into application code, but that was probably
a long time ago
 :slight_smile:

[
glSDL and Advanced2D API
]On Monday 11 May 2009, Bob Pendleton wrote:

Great minds and all that
 I have a tiny 2D GL like API buried in
one of my font libraries. Its layered on top of software and OpenGL,
no DirectX.

–
//David Olofson - Programmer, Composer, Open Source Advocate

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --’

18

Hmm, SDL “extensions”? You could test for the feature, and use a
different code path if you want to
 On one hand, I really find it
annoying when an API is littered with extensions, which makes it hard
to code a trivial program

Oh, you mean like requiring a separate DLL in order to load images
saved in any format that people actually use? ?Yeah, I hate when
things like that get in the way
 :-p

No, I mean like having to call (something like)
SDL_GL_ExtensionSupported to know whether you can use it.

The suggestion I was making was that there might be an
SDL_AreRenderTargetAccelerated(), but they would work in either case
(software fallback if they’re not accelerated). It would let you avoid
them if you have another way of achieving an equivalent result, but if
you can’t do (much) better than the software fallback, you’d just not
care, and use it without checking.On Mon, May 11, 2009 at 1:44 PM, Mason Wheeler wrote:

–
http://pphaneuf.livejournal.com/

19

The worst case for this would probably be blitting a static texture to
a render target where the backend doesn’t support it. You’d need to
read back the source texture into main memory to perform that blit in
software. With luck, the pixel format and pitch match and you can copy
right into the destination, but otherwise, you end up with two copies,
with one of them probably being a really slow AGP read-back


What if there was an additional texture type? ?Static rendertarget
textures? ?If render targets are available in hardware, they’d be like
normal static textures, but if not, they’d be kept in RAM so that the
expensive download wouldn’t be necessary.

The problem is with the source texture, not really the render target
ones (although those might have to be special too, of course).On Mon, May 11, 2009 at 2:23 PM, Gerry JJ wrote:

–
http://pphaneuf.livejournal.com/

20

Den Mon, 11 May 2009 15:24:20 -0400
skrev Pierre Phaneuf :

What if there was an additional texture type? ?Static rendertarget
textures? ?If render targets are available in hardware, they’d be
like normal static textures, but if not, they’d be kept in RAM so
that the expensive download wouldn’t be necessary.

The problem is with the source texture, not really the render target
ones (although those might have to be special too, of course).

Yes. What I meant was that, as the developer of any game that would use
this, you’d know which textures will only be blitted to the screen, and
which ones may be used for blitting to different render targets. The
new texture type would be for these source textures, not for the
targets. Maybe calling them offscreen static textures or something
would be better.

  • Gerry