API for non-rectangulars

So now that we’re with SDL 2 (as opposed to 1.2), we have better
integration with the awesome hardware accelerated APIs (OpenGL, D3D).
However, why are we still restricted to rectangles (with color-keyed
textures)?

We should be able to construct vertex buffer arrays / objects through SDL
by now. I’m not aware of any significant difference between OGL and D3D on
that front.

As a side effect, this will be a step towards adding 3D functionality to
SDL.
Also, this will allow optimization engineers to replace normal SDL code
with VBA/VBO based rendering to improve performance (you know, caching the
vertices on the GPU. etc).

Let’s discuss this.

Alternatively, is there an SDL extension that already does that?
If there is, then what is the rationale behind leaving it as extension and
not adding it to the SDL core?

SDL?s Render API is only designed for very simple 2D rendering. For anything more complicated, you should probably use SDL?s OpenGL context creation functionality to use OpenGL or OpenGL ES directly - or use a separate rendering library which is based on OpenGL (you may be able to combine it with SDL?s windowing / input / etc. functionality.)On Mar 14, 2014, at 2:33 PM, Ivan Rubinson wrote:

So now that we’re with SDL 2 (as opposed to 1.2), we have better integration with the awesome hardware accelerated APIs (OpenGL, D3D). However, why are we still restricted to rectangles (with color-keyed textures)?

We should be able to construct vertex buffer arrays / objects through SDL by now. I’m not aware of any significant difference between OGL and D3D on that front.

As a side effect, this will be a step towards adding 3D functionality to SDL.
Also, this will allow optimization engineers to replace normal SDL code with VBA/VBO based rendering to improve performance (you know, caching the vertices on the GPU. etc).

Let’s discuss this.

Alternatively, is there an SDL extension that already does that?
If there is, then what is the rationale behind leaving it as extension and not adding it to the SDL core?


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

2014-03-14 18:33 GMT+01:00 Ivan Rubinson :

So now that we’re with SDL 2 (as opposed to 1.2), we have better
integration with the awesome hardware accelerated APIs (OpenGL, D3D).
However, why are we still restricted to rectangles (with color-keyed
textures)?

We should be able to construct vertex buffer arrays / objects through SDL
by now. I’m not aware of any significant difference between OGL and D3D on
that front.

As a side effect, this will be a step towards adding 3D functionality to
SDL.
Also, this will allow optimization engineers to replace normal SDL code
with VBA/VBO based rendering to improve performance (you know, caching the
vertices on the GPU. etc).

Let’s discuss this.

Alternatively, is there an SDL extension that already does that?
If there is, then what is the rationale behind leaving it as extension and
not adding it to the SDL core?

AFAIK the SDL2 render API is a toy API, meant to provide easy means of
upgrading
older, SDL1.2 style games with hardware acceleration. It’s not meant for
anything
"serious" aside from maybe prototypes and very simple 2D games.

OpenGL provides you with the full power of your hardware in a
cross-platform way,
and as long as you don’t do anything crazy, the path to GLES isn’t that
hard either.
I don’t see the point in replicating such functionality in SDL.

SDL_gpu does this kind of stuff (with only an OpenGL backend for now). I
made it because I don’t think rendering details belong in core SDL. SDL
certainly doesn’t need any 3D-specific features to fulfill its goals.

SDL_gpu lets you send in a vertex array and an index array with
GPU_TriangleBatch(). It also uses its own VBOs and it buffers blitting and
shape rendering calls automatically.

Jonny D

Sounds awesome!
VBOs are not 3D-specific though.

So let me get this straight: SDL rendering is crap and should be replaced
with OpenGL ASAP if possible?
Why does it have so much customization/power already then?On Fri, Mar 14, 2014 at 7:47 PM, Jonathan Dearborn wrote:

SDL_gpu does this kind of stuff (with only an OpenGL backend for now). I
made it because I don’t think rendering details belong in core SDL. SDL
certainly doesn’t need any 3D-specific features to fulfill its goals.

SDL_gpu lets you send in a vertex array and an index array with
GPU_TriangleBatch(). It also uses its own VBOs and it buffers blitting and
shape rendering calls automatically.

Jonny D


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

(by “OpenGL backend”, of course I meant renderers for OpenGL 3, 2, 1, and
OpenGL ES 2 and 1 :wink: )

SDL is a multimedia library, not a replacement for OpenGL. It makes a
window and lets you put stuff in it. If you need to do more, then SDL
makes it easy for you to set up an OpenGL context. We don’t want SDL to
just be another game engine.

VBOs can be used for 2D stuff (I use them!), but they’re actually not that
useful when geometry is being updated every frame, which is typical of
immediate-mode 2D APIs.

Jonny D

Some things aren’t updated every frame though. Or at least not really.
(Scaling doesn’t update the geometry, it updates a (different) matrix).
That’s why an engineer needs to figure out what can be VBObified and what
needs to stay lamely glBeginish.On Fri, Mar 14, 2014 at 7:55 PM, Jonathan Dearborn wrote:

(by “OpenGL backend”, of course I meant renderers for OpenGL 3, 2, 1, and
OpenGL ES 2 and 1 :wink: )

SDL is a multimedia library, not a replacement for OpenGL. It makes a
window and lets you put stuff in it. If you need to do more, then SDL
makes it easy for you to set up an OpenGL context. We don’t want SDL to
just be another game engine.

VBOs can be used for 2D stuff (I use them!), but they’re actually not that
useful when geometry is being updated every frame, which is typical of
immediate-mode 2D APIs.

Jonny D


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

Does SDL2 upload matrices for geometry scaling? I dunno.

SDL_gpu does generate new geometry each time you call GPU_Blit() and stores
up all the blits so they can be uploaded to the GPU all at once. I would
think that updating matrices for each sprite’s scaling would be a lot more
data to transfer and wouldn’t improve performance. I just use VBOs to
store the position, tex coord, and color data for each vertex.

Also, another argument to put rendering into an extension is that SDL_gpu
works just great for either SDL 1.2 or SDL 2.0. I didn’t need any of
SDL2’s new features for SDL_gpu’s rendering (though of course the
multi-window support is nice).

Jonny D

2014-03-14 18:58 GMT+01:00 Ivan Rubinson :

Some things aren’t updated every frame though. Or at least not really.
(Scaling doesn’t update the geometry, it updates a (different) matrix).
That’s why an engineer needs to figure out what can be VBObified and what
needs to stay lamely glBeginish.

Yep, while the traditional “sprites” are mostly singular quad draws, things
like
eg. tilemaps really shine with batched up geometry calls. You should still
consider
not using deprecated OpenGL though =) (ie. use VBOs for everything).

As for SDL, I think it has always tried to be the cross-platform solution
to DirectX
sans Direct3D, which OpenGL already replaces.> On Fri, Mar 14, 2014 at 7:55 PM, Jonathan Dearborn wrote:

(by “OpenGL backend”, of course I meant renderers for OpenGL 3, 2, 1, and
OpenGL ES 2 and 1 :wink: )

SDL is a multimedia library, not a replacement for OpenGL. It makes a
window and lets you put stuff in it. If you need to do more, then SDL
makes it easy for you to set up an OpenGL context. We don’t want SDL to
just be another game engine.

VBOs can be used for 2D stuff (I use them!), but they’re actually not
that useful when geometry is being updated every frame, which is typical of
immediate-mode 2D APIs.

Jonny D


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

Hi,
I’m trying to build an app with SDL under Eclipse.
It’s not possible to do this with the android-project shipped by SDL and
Android API10.
He allways wants an API >= 12. When I take the API10 (2.3.3) Eclipse
reports a lot of errors in the joystick implementation of SDLActivity.java.

Is SDL not compatible to 2.3.3? Or did I something wrong?

Best regards

You build it with API >= 12, but it should still work (without joystick
support) on devices that have a lower API level.

Jonny D

Ok, I thought that if I build it with API12, the .apk is not
backwards-compatible with 2.3.3.Am 15.03.2014 01:06, schrieb Jonathan Dearborn:

You build it with API >= 12, but it should still work (without
joystick support) on devices that have a lower API level.

Jonny D


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

Yeah, I think the trick is that your AndroidManifest (what the device will
check) should specify API level 10, but you keep “target=android-12” in
your build files.

Jonny D

So let me get this straight: SDL rendering is crap and should be
replaced with OpenGL ASAP if possible?
Why does it have so much customization/power already then?

Because we keep losing the fight against adding more functionality to it.

The Render API was more or less meant to get all the 1.2-style surface
blitting onto the GPU, and make things like scaling up a legacy game
easy. You would need to migrate to it, but it would be familiar enough,
offer roughly equivalent functionality, and offer enough added benefits
to make it worth your while. I’ve migrated a few games to it, and I’m
extremely happy with how it turned out.

I’ve been joking that the Render API is for making the most advanced
Super Nintendo games ever. Outside of migrating older games, it’s for
rendering sprites, scaling and rotation, more or less, and I’m happy
with how it turned out for those uses, too.

That being said, there is a patch pending to add something like
SDL_RenderGeometry() to the API, and we’re considering it.

Here’s why:

If you have a game that uses the Render API, it probably Just Works, and
renders quickly, on a whole bunch of platforms. The test case I used
before was Dungeons of Dredmor. Once I moved it to SDL2 and the Render
API, it worked in all sorts of places without any changes to the game
code (notably: Linux, Mac OS X, Windows, iOS, Raspberry Pi, and probably
Android. Once I get time to screw with the new WinRT stuff, it’ll
probably work on Windows 8 tablets and Windows Phones, too). If I had
just replaced all the SDL_Surface blitting with OpenGL textures
directly, then I’d have had to do some work for GLES, and then Direct3D
9, and then Direct3D 11. Instead, the hard part was figuring out how to
run the compiler for all these different platforms.

But maybe there’s a definite win here for game developers by being able
to upload vertex buffers and draw 3D geometry, if it lets them get that
same benefit for 3D stuff that the Render API got me for Dredmor.

But here’s the problem:

  • This is about as far as the software renderer could go. More features
    on top of this get really hard, and things like pixel shaders get
    impossible. Already we’d have to decide if optimizing a software
    renderer is worth the time it would take just for getting polygons to
    the screen. I’m already sort of the opinion that we should expose 3D
    rendering as a flag, like we do for render targets, and just say you
    can’t do it without some sort of GL or D3D.

  • The next email thread will be about “if SDL has 3D rendering built in,
    why can’t it also have X, Y, and Z?” the same way that the existence of
    the Render API at all makes people ask why it can’t also have 3D
    rendering. It’d still be a “toy API,” and serious apps would want more
    power, and the struggle continues.

Should the line we draw be “if you need texture-mapped polygons, we can
help, but if you need shaders, use OpenGL and/or Direct3D?” I don’t know
the answer yet. It might be a line too far already.

–ryan.

This is not true. (I have very strong opinions about how to do this
because I’ve been bitten hard by this.)

In the Android Manifest, there are two settings:
targetSdkVersion
minSDKVersion

Set the targetSdkVersion to the latest. Set the minSDKVersion to the
lowest version you want to support. It looks like SDL already does the
runtime safety check to avoid calling non-existent APIs on 2.3.

And when I say “latest”, I really do mean latest. I strongly advocate
this because Android has runtime detection behavior that checks how it
is compiled and runs differently depending. While this is supposed to
avoid bugs, I found it actually causes different bugs. And it also
punishes people with newer OS versions with legacy behavior. (For
example when Project Butter brough hardware accelerated UI to 4.0, if
you were compiled with a lower targetSdkVersion, the code path was
disabled so you got both slower performance and I also found nasty
bugs they weren’t testing for.)

-EricOn 3/14/14, Daniel Knobe wrote:

Ok, I thought that if I build it with API12, the .apk is not
backwards-compatible with 2.3.3.


Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

In the Android Manifest, there are two settings:
targetSdkVersion
minSDKVersion

For correctness, the capitalization is:
targetSdkVersion
minSdkVersion

-Eric–
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

Message-ID:

Content-Type: text/plain; charset=“iso-8859-1”

So now that we’re with SDL 2 (as opposed to 1.2), we have better
integration with the awesome hardware accelerated APIs (OpenGL, D3D).
However, why are we still restricted to rectangles (with color-keyed
textures)?

Someone was working at adding triangles, but I don’t know if it’s
still being worked on, and there was a question as to whether it would
actually be added to SDL, or just an extension library.

We should be able to construct vertex buffer arrays / objects through SDL
by now. I’m not aware of any significant difference between OGL and D3D on
that front.

VBOs sound like extension territory to me.

As a side effect, this will be a step towards adding 3D functionality to
SDL.

3D is definitely extension territory. One of the nice things about SDL
is that it’s reasonably small, so you CAN reinvent most of the wheels
without breaking things if you see fit. And yes, I for one do consider
the ability to boldly cover the same ground that everyone else has
covered before to be a genuine benefit: it reduces the need for
"translations", chances of collisions, etc.

Alternatively, is there an SDL extension that already does that?
If there is, then what is the rationale behind leaving it as extension and
not adding it to the SDL core?

As far as the lack of triangles, I don’t know that there’s any
particularly compelling rationale, the only thing that I genuinely
know to be stopping it is the lack of a software triangle renderer. As
for the rest, SDL is APPROXIMATELY intended to be an abstraction
layer, so if it goes MEANINGFULLY beyond bare-bones then it generally
isn’t appropriate for the core library (though if you need “A” for the
sake of implementing “B” in an extension library, then either “A” or
something that will allow an extension library to implement "A"
certainly becomes much more reasonable).> Date: Fri, 14 Mar 2014 19:33:08 +0200

From: Ivan Rubinson
To: SDL Development List
Subject: [SDL] API for non-rectangulars

Date: Fri, 14 Mar 2014 19:50:14 +0200
From: Ivan Rubinson
To: SDL Development List
Subject: Re: [SDL] API for non-rectangulars
Message-ID:
<CAHR5Zr-s8ANUHNw3A4WB24M3YXURS5_VEmGKmo5ozvCYM5W3sQ at mail.gmail.com>
Content-Type: text/plain; charset=“iso-8859-1”

Sounds awesome!
VBOs are not 3D-specific though.

So let me get this straight: SDL rendering is crap and should be replaced
with OpenGL ASAP if possible?
Why does it have so much customization/power already then?

“Customer” request? The SDL2 renderer API isn’t intended for only toy
& learning use, but it IS only intended for lower-spec use. Basically,
utility programs & games with simple graphics demands are the intended
use case: stuff that wants cross-platform graphics, but doesn’t care
about power enough to justify an additional library dependency
(imagine an installer that should be interactive, graphical, and
capable of displaying it’s GUI even if the game won’t work, for the
sake of trouble-shooting).

Date: Fri, 14 Mar 2014 13:55:34 -0400
From: Jonathan Dearborn
To: SDL Development List
Subject: Re: [SDL] API for non-rectangulars
Message-ID:
<CA+DSiHZJPjH8_tMPfXedif5deE3==voqC+L=nk+roJNPHJFVHg at mail.gmail.com>
Content-Type: text/plain; charset=“iso-8859-1”

(by “OpenGL backend”, of course I meant renderers for OpenGL 3, 2, 1, and
OpenGL ES 2 and 1 :wink: )

SDL is a multimedia library, not a replacement for OpenGL. It makes a
window and lets you put stuff in it. If you need to do more, then SDL
makes it easy for you to set up an OpenGL context. We don’t want SDL to
just be another game engine.

Amen, leave that stuff to other projects: SDL should be the type of
thing that those other projects use to get their engines running in
more places.

The thing about VBOs is that they’re the primary method for talking
vertices with OpenGL ES. Modern OpenGL ES simply doesn’t have
glBegin()-glEnd() style rendering (immediate mode).
This means that SDL pretty much needs to guess it when it comes to
geometry. This might have performance implications.
By letting the programmer explicitly handle the VBOs, one could improve
performance and make life easier for SDL implementers/maintainers.
Maybe my game has is tile based. This means that I need only a single VBO
in VRAM and all I need is to texture it differently. I have intimate
knowledge of my game, so I’m the one who can do this kind of work best, not
SDL.
3D support is simply a side effect.On Sat, Mar 15, 2014 at 9:05 AM, Jared Maddox wrote:

Date: Fri, 14 Mar 2014 19:33:08 +0200
From: Ivan Rubinson <@Ivan_Rubinson>
To: SDL Development List
Subject: [SDL] API for non-rectangulars
Message-ID:
<
CAHR5Zr8hRxUqH7MBPhoVXHL-bAhxkccEoOzy5b9NH3MFkcfvJQ at mail.gmail.com>
Content-Type: text/plain; charset=“iso-8859-1”

So now that we’re with SDL 2 (as opposed to 1.2), we have better
integration with the awesome hardware accelerated APIs (OpenGL, D3D).
However, why are we still restricted to rectangles (with color-keyed
textures)?

Someone was working at adding triangles, but I don’t know if it’s
still being worked on, and there was a question as to whether it would
actually be added to SDL, or just an extension library.

We should be able to construct vertex buffer arrays / objects through SDL
by now. I’m not aware of any significant difference between OGL and D3D
on
that front.

VBOs sound like extension territory to me.

As a side effect, this will be a step towards adding 3D functionality to
SDL.

3D is definitely extension territory. One of the nice things about SDL
is that it’s reasonably small, so you CAN reinvent most of the wheels
without breaking things if you see fit. And yes, I for one do consider
the ability to boldly cover the same ground that everyone else has
covered before to be a genuine benefit: it reduces the need for
"translations", chances of collisions, etc.

Alternatively, is there an SDL extension that already does that?
If there is, then what is the rationale behind leaving it as extension
and
not adding it to the SDL core?

As far as the lack of triangles, I don’t know that there’s any
particularly compelling rationale, the only thing that I genuinely
know to be stopping it is the lack of a software triangle renderer. As
for the rest, SDL is APPROXIMATELY intended to be an abstraction
layer, so if it goes MEANINGFULLY beyond bare-bones then it generally
isn’t appropriate for the core library (though if you need “A” for the
sake of implementing “B” in an extension library, then either “A” or
something that will allow an extension library to implement "A"
certainly becomes much more reasonable).

Date: Fri, 14 Mar 2014 19:50:14 +0200
From: Ivan Rubinson <@Ivan_Rubinson>
To: SDL Development List
Subject: Re: [SDL] API for non-rectangulars
Message-ID:
<
CAHR5Zr-s8ANUHNw3A4WB24M3YXURS5_VEmGKmo5ozvCYM5W3sQ at mail.gmail.com>
Content-Type: text/plain; charset=“iso-8859-1”

Sounds awesome!
VBOs are not 3D-specific though.

So let me get this straight: SDL rendering is crap and should be replaced
with OpenGL ASAP if possible?
Why does it have so much customization/power already then?

“Customer” request? The SDL2 renderer API isn’t intended for only toy
& learning use, but it IS only intended for lower-spec use. Basically,
utility programs & games with simple graphics demands are the intended
use case: stuff that wants cross-platform graphics, but doesn’t care
about power enough to justify an additional library dependency
(imagine an installer that should be interactive, graphical, and
capable of displaying it’s GUI even if the game won’t work, for the
sake of trouble-shooting).

Date: Fri, 14 Mar 2014 13:55:34 -0400
From: Jonathan Dearborn
To: SDL Development List
Subject: Re: [SDL] API for non-rectangulars
Message-ID:
<CA+DSiHZJPjH8_tMPfXedif5deE3==voqC+L=
nk+roJNPHJFVHg at mail.gmail.com>
Content-Type: text/plain; charset=“iso-8859-1”

(by “OpenGL backend”, of course I meant renderers for OpenGL 3, 2, 1, and
OpenGL ES 2 and 1 :wink: )

SDL is a multimedia library, not a replacement for OpenGL. It makes a
window and lets you put stuff in it. If you need to do more, then SDL
makes it easy for you to set up an OpenGL context. We don’t want SDL to
just be another game engine.

Amen, leave that stuff to other projects: SDL should be the type of
thing that those other projects use to get their engines running in
more places.


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

Maybe you should change that joke to NES. The Super Nintendo has
capabilities that are not present in the SDL render API, e.g. mode 7.On 15.03.2014 01:36, Ryan C. Gordon wrote:

I’ve been joking that the Render API is for making the most advanced
Super Nintendo games ever.


Rainer Deyke (rainerd at eldwood.com)

Thanks for that great answer :)!Am 15.03.2014 02:14, schrieb Eric Wing:

In the Android Manifest, there are two settings:
targetSdkVersion
minSDKVersion
For correctness, the capitalization is:
targetSdkVersion
minSdkVersion

-Eric