So now we have textures, which, correct me if I’m wrong, will load into software ram space if hardware space is unavailable (this is certainly the case in a non-hwaccel renderer), and the functions under SDL_image 2 which load directly into textures,
under what circumstances will we want to use surfaces.
Also while we’re at it, to the best of anybody’s knowledge, which renderers (opengl, directx etc) allow for SDL_RENDERER_TARGETTEXTURE?
According to a quick grep search in the latest source tree:
Software, OpenGL ES 2, OpenGL, Direct3D, and the PSP port.
In other words, only OpenGL ES 1 seems to not support it.On 13 ??? 2013, at 1:24 ?.?., “mattbentley” wrote:
Also while we’re at it, to the best of anybody’s knowledge, which renderers (opengl, directx etc) allow for SDL_RENDERER_TARGETTEXTURE?
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
2013/10/13
According to a quick grep search in the latest source tree:
Software, OpenGL ES 2, OpenGL, Direct3D, and the PSP port.In other words, only OpenGL ES 1 seems to not support it.
Makes sense, considering ES 1 probably didn’t have support for FBOs yet.
2013/10/13 Jonas Kulla
2013/10/13
According to a quick grep search in the latest source tree:
Software, OpenGL ES 2, OpenGL, Direct3D, and the PSP port.In other words, only OpenGL ES 1 seems to not support it.
Makes sense, considering ES 1 probably didn’t have support for FBOs yet.
All backends, including ES 1, support Render Targets depending on hardware
support. In practice the only system where I’ve seen this fail is with
Desktop Linux + nVidia binaries, as it seems they winged it with the ES1
support (ES2 works like a charm though).–
Gabriel.
“under what circumstances will we want to use surfaces.”
Was this meant to be the question under consideration?
Jonny DOn Sun, Oct 13, 2013 at 10:07 AM, Gabriel Jacobo wrote:
2013/10/13 Jonas Kulla
2013/10/13
According to a quick grep search in the latest source tree:
Software, OpenGL ES 2, OpenGL, Direct3D, and the PSP port.In other words, only OpenGL ES 1 seems to not support it.
Makes sense, considering ES 1 probably didn’t have support for FBOs yet.
All backends, including ES 1, support Render Targets depending on hardware
support. In practice the only system where I’ve seen this fail is with
Desktop Linux + nVidia binaries, as it seems they winged it with the ES1
support (ES2 works like a charm though).–
Gabriel.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
2013/10/13 Gabriel Jacobo
2013/10/13 Jonas Kulla <@Jonas_Kulla>
2013/10/13
According to a quick grep search in the latest source tree:
Software, OpenGL ES 2, OpenGL, Direct3D, and the PSP port.In other words, only OpenGL ES 1 seems to not support it.
Makes sense, considering ES 1 probably didn’t have support for FBOs yet.
All backends, including ES 1, support Render Targets depending on hardware
support. In practice the only system where I’ve seen this fail is with
Desktop Linux + nVidia binaries, as it seems they winged it with the ES1
support (ES2 works like a charm though).
Interesting. How are Render Targets implemented in ES 1 when no FBO
extensions are available? Using PBuffers?
2013/10/13 Jonas Kulla
2013/10/13 Gabriel Jacobo <@Gabriel_Jacobo>
2013/10/13 Jonas Kulla
2013/10/13
According to a quick grep search in the latest source tree:
Software, OpenGL ES 2, OpenGL, Direct3D, and the PSP port.In other words, only OpenGL ES 1 seems to not support it.
Makes sense, considering ES 1 probably didn’t have support for FBOs yet.
All backends, including ES 1, support Render Targets depending on
hardware support. In practice the only system where I’ve seen this fail is
with Desktop Linux + nVidia binaries, as it seems they winged it with the
ES1 support (ES2 works like a charm though).Interesting. How are Render Targets implemented in ES 1 when no FBO
extensions are available? Using PBuffers?
It’s done more or less like this:
http://hg.libsdl.org/SDL/file/627f256b0e56/src/render/opengles/SDL_render_gles.c#l613:)–
Gabriel.
2013/10/13 Gabriel Jacobo
2013/10/13 Jonas Kulla <@Jonas_Kulla>
2013/10/13 Gabriel Jacobo
2013/10/13 Jonas Kulla <@Jonas_Kulla>
2013/10/13
According to a quick grep search in the latest source tree:
Software, OpenGL ES 2, OpenGL, Direct3D, and the PSP port.In other words, only OpenGL ES 1 seems to not support it.
Makes sense, considering ES 1 probably didn’t have support for FBOs yet.
All backends, including ES 1, support Render Targets depending on
hardware support. In practice the only system where I’ve seen this fail is
with Desktop Linux + nVidia binaries, as it seems they winged it with the
ES1 support (ES2 works like a charm though).Interesting. How are Render Targets implemented in ES 1 when no FBO
extensions are available? Using PBuffers?It’s done more or less like this:
http://hg.libsdl.org/SDL/file/627f256b0e56/src/render/opengles/SDL_render_gles.c#l613:)
621 if (!data->GL_OES_framebuffer_object_supported) {
622 return SDL_SetError(“Can’t enable render target support in
this renderer”);
623 }
So, basically it’s simply not supported when no FBO extension is present. I see.
under what circumstances will we want to use surfaces.
If you need to process the pixel data on the CPU.
To get it to the screen, using SDL’s 2D render API, you want an
SDL_Texture. It’s the only time you’d want an SDL_Texture, but it’s an
important time. 
–ryan.
This is actually a fairly important distinction which is almost always
glossed over in SDL.
There are two ways of writing an app using SDL:
-
write your own 3D by hand (eg. opengl)
-
use the built in graphics api.
…
You probably do not want to do 2.
You might be fooled into thinking (2) is a good idea because:
-
It’s already nice and cross platform
-
SDL_RenderCopyEx provides a way to rotate textures, which is tricky to do
by hand (old SDL problem) -
Otherwise you have to write your own shaders and your own
opengl/opengl-es code. -
Already has a font rendering api using SDL_Freetype
However, the in build graphics api was and is designed for rendering blocks
(flat, unrotated blocks) of pixels, onto other flat blocks unrotated of
pixels, and then pushing those pixels to the screen.
That’s all.
It’s very good at that, but if you want to:
-
Shade, tint, fog, flare, sparkle, etc. (requires shaders mostly although
arguably you can do some of this slowly in cpu pixel processing) -
Have rotated objects (any type of physics)
-
Have any type of 3D overlay (or any 3d)
-
Have large geometry sets (eg. bullet hell games)
Then the built in rendering api isn’t a good choice.
You can easily use SDL_FreeType to create font atlases and render them
using opengl too; in fact, if you do use the sdl native apis you can
often pull the raw pixel data and manually stream them to a texture to get
the best of all worlds, so long as you only work with SDL_Surface’s.
Well… that’s been my experience with SDL thus far.
Seriously; use opengl not the SDL_* functions if you’re working on a game.
What might seem like a boon in less-work-now will turn into a disappointing
rewrite when you come to the polish step.~
Doug.
On Mon, Oct 14, 2013 at 8:14 AM, Ryan C. Gordon wrote:
under what circumstances will we want to use surfaces.
If you need to process the pixel data on the CPU.
To get it to the screen, using SDL’s 2D render API, you want an
SDL_Texture. It’s the only time you’d want an SDL_Texture, but it’s an
important time.–ryan.
_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
What might seem like a boon in less-work-now will turn into a
disappointing rewrite when you come to the polish step.
It depends on what you’re doing. The intention for the Render API was
two goals:
-
Provide a reasonable path for modernizing 2D games (specifically: SDL
1.2 games). If one moves to the Render API, out of the box you get
faster rendering, scaling, Steam Overlay support, Direct3D on Windows,
GLES on iOS, etc. -
Make simple games simple to write. If all you want to do is write a
Super Mario clone–which itself is a stretch goal when you’re starting
out–then you’re going to drown if you work with OpenGL directly. I like
that you can knock out a simple game really quickly with the Render API.
But you are right: you are absolutely going to hit limits quickly if you
have larger rendering ambitions. That’s sort of by design: the API meets
its design goals without added complications, and we didn’t want to
build a full API that abstracts every other 3D API…for those cases, we
made it easy to use the existing APIs themselves.
–ryan.
Yep; it’s a perfectly valid prototyping tool, and there are plenty of
applications where simple 2D composting is more than sufficient; just not
games.
I think its largely becoming irrelevant to be honest; despite the very
awesome improvements in performance in the 2.x SDL codebase, I personally
think the 2D api is quickly becoming like the tk bindings in python; lowest
common denominator rather than powerful low level hardware bindings.
‘Here are all these classes and functions that manipulate pixel streams.
You’ll never want to use these for any serious purpose, but feel free to
play around with them’
It’s a little lackluster.
The bits are all there to make something much better using SDL_WindowFlags
and adding support for 2d geometry rendering, but the relcance to add
features that can’t be supported in the software renderer is really holding
everything back…
Anyway, getting all OT now~ :)~
Doug.
On Mon, Oct 14, 2013 at 11:39 PM, Ryan C. Gordon wrote:
What might seem like a boon in less-work-now will turn into a
disappointing rewrite when you come to the polish step.
It depends on what you’re doing. The intention for the Render API was two
goals:
Provide a reasonable path for modernizing 2D games (specifically: SDL
1.2 games). If one moves to the Render API, out of the box you get faster
rendering, scaling, Steam Overlay support, Direct3D on Windows, GLES on
iOS, etc.Make simple games simple to write. If all you want to do is write a
Super Mario clone–which itself is a stretch goal when you’re starting
out–then you’re going to drown if you work with OpenGL directly. I like
that you can knock out a simple game really quickly with the Render API.But you are right: you are absolutely going to hit limits quickly if you
have larger rendering ambitions. That’s sort of by design: the API meets
its design goals without added complications, and we didn’t want to build a
full API that abstracts every other 3D API…for those cases, we made it
easy to use the existing APIs themselves.–ryan.
_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Just to be clear, yes, you almost always want to use OpenGL to make your
own engine, or use one of the good ones that are already out there, like
Unity.
The render API is specifically designed for simple prototyping and porting
older games.
SDL has excellent support for OpenGL across the major platforms and is a
really great learning tool for low level game development and a porting
tool for existing titles.
Ryan and I use SDL extensively for a variety of tasks, and you’ll find
features being added as we need them, and as people convince us they’re
good ideas. We’re likely going to see SDL_RenderGeometry() added soon, for
example, and I added some hooks that allow me to do hardware accelerated
H264 decoding for some reason. 
It is an open API, and you’re always welcome to take it and customize it
any way you need. If you make great improvements, I heartily encourage you
to post them and make them available to people who want them.
Cheers!On Mon, Oct 14, 2013 at 7:24 AM, Doug <douglas.linder at gmail.com> wrote:
This is actually a fairly important distinction which is almost always
glossed over in SDL.There are two ways of writing an app using SDL:
write your own 3D by hand (eg. opengl)
use the built in graphics api.
…
You probably do not want to do 2.
You might be fooled into thinking (2) is a good idea because:
It’s already nice and cross platform
SDL_RenderCopyEx provides a way to rotate textures, which is tricky to
do by hand (old SDL problem)Otherwise you have to write your own shaders and your own
opengl/opengl-es code.Already has a font rendering api using SDL_Freetype
However, the in build graphics api was and is designed for rendering
blocks (flat, unrotated blocks) of pixels, onto other flat blocks unrotated
of pixels, and then pushing those pixels to the screen.That’s all.
It’s very good at that, but if you want to:
Shade, tint, fog, flare, sparkle, etc. (requires shaders mostly although
arguably you can do some of this slowly in cpu pixel processing)Have rotated objects (any type of physics)
Have any type of 3D overlay (or any 3d)
Have large geometry sets (eg. bullet hell games)
Then the built in rendering api isn’t a good choice.
You can easily use SDL_FreeType to create font atlases and render them
using opengl too; in fact, if you do use the sdl native apis you can
often pull the raw pixel data and manually stream them to a texture to get
the best of all worlds, so long as you only work with SDL_Surface’s.Well… that’s been my experience with SDL thus far.
Seriously; use opengl not the SDL_* functions if you’re working on a game.What might seem like a boon in less-work-now will turn into a
disappointing rewrite when you come to the polish step.~
Doug.On Mon, Oct 14, 2013 at 8:14 AM, Ryan C. Gordon wrote:
under what circumstances will we want to use surfaces.
If you need to process the pixel data on the CPU.
To get it to the screen, using SDL’s 2D render API, you want an
SDL_Texture. It’s the only time you’d want an SDL_Texture, but it’s an
important time.–ryan.
_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://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
I really like that SDL’s render API can provide a stepping stone to
OpenGL for 2D game developers. It also makes a lot of old 2D SDL
extension libraries available for use in OpenGL-using programs.
There’s some gotchas there, however. The notable one I have found is
that if you’re using the fixed function pipeline, you need to push
the modelview matrix (and consequently the matrix mode) before you
start drawing in 3D and pop it when you’re done. There may be other
things that need preserving, but that’s the one that stuck out at me.
If you even have a fixed function pipeline available to use, it’s a
good bet SDL’s using it in its renderer. Obviously it has to on
GLESv1, but it also does so on the desktop (which means you’re
running in compatibility mode on the newest OpenGL versions?possibly
a less optimized path going forward).
Preserving the modelview matrix is no biggie, but if there are more
such major issues out there, it could quickly raise the learning
curve.
(And I’m still not convinced 3 OpenGL render backends are actually
necessary. I get two?one for fixed function and one programmable,
but it seems like the OpenGL ES versions ought to run fine using
SDL’s OpenGL abstraction. Nothing in the render API needs anything
GLES doesn’t provide?)
JosephOn Mon, Oct 14, 2013 at 11:39:52AM -0400, Ryan C. Gordon wrote:
What might seem like a boon in less-work-now will turn into a
disappointing rewrite when you come to the polish step.It depends on what you’re doing. The intention for the Render API was
two goals:
Provide a reasonable path for modernizing 2D games (specifically:
SDL 1.2 games). If one moves to the Render API, out of the box you
get faster rendering, scaling, Steam Overlay support, Direct3D on
Windows, GLES on iOS, etc.Make simple games simple to write. If all you want to do is write a
Super Mario clone–which itself is a stretch goal when you’re
starting out–then you’re going to drown if you work with OpenGL
directly. I like that you can knock out a simple game really quickly
with the Render API.But you are right: you are absolutely going to hit limits quickly if
you have larger rendering ambitions. That’s sort of by design: the
API meets its design goals without added complications, and we didn’t
want to build a full API that abstracts every other 3D API…for
those cases, we made it easy to use the existing APIs themselves.–ryan.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
2013/10/15, Doug <douglas.linder at gmail.com>:
The bits are all there to make something much better using SDL_WindowFlags
and adding support for 2d geometry rendering, but the relcance to add
features that can’t be supported in the software renderer is really holding
everything back…
That isn’t an excuse, classic Allegro was pure software rendering
(didn’t support GPUs at all) and it still had many more features than
the current SDL renderer API. It even had some minimal support for 3D
rendering!
The real problem is that a new feature would need to be implemented in
all renderers, but practically everybody who submits a patch only does
it for OpenGL or Direct3D (and yes, always only one of them). This
is what is holding things back.
Maybe we could work around that by having an “unstable” renderer API
or something like that, where unfinished functions (e.g. those not
working in all renderers) go. Then people can start making use of them
early (at their own risk) and this could encourage others to add the
missing parts, so it can then finally become part of the stable API.
There are three OpenGL backends because of the three major OpenGL ‘versions’: desktop OpenGL, OpenGL ES and OpenGL ES 2.
Currently, I strongly believe that none of those should be removed.
- Desktop OpenGL is required for desktop systems.
- OpenGL ES 2 is the standard backend for Android and iOS.
- OpenGL ES exists to support older hardware, which do not support OpenGL ES 2. And yes, the transition from GL ES1 to GL ES2 is impossible for older hardware. If you search the internet, you will see that both are used actively (okay, OpenGL ES 2 is getting more and more popular, but you get the point).
For the next two or three years, keeping OpenGL ES 1 is required to be compatible with an audience as wide as possible. If it were removed, then, amongst other things, the minimum supported iOS version would become 5.0, completely dropping support for pre-Lion systems.On 15 ??? 2013, at 8:27 ?.?., “T. Joseph Carter” wrote:
I really like that SDL’s render API can provide a stepping stone to OpenGL for 2D game developers. It also makes a lot of old 2D SDL extension libraries available for use in OpenGL-using programs.
There’s some gotchas there, however. The notable one I have found is that if you’re using the fixed function pipeline, you need to push the modelview matrix (and consequently the matrix mode) before you start drawing in 3D and pop it when you’re done. There may be other things that need preserving, but that’s the one that stuck out at me.
If you even have a fixed function pipeline available to use, it’s a good bet SDL’s using it in its renderer. Obviously it has to on GLESv1, but it also does so on the desktop (which means you’re running in compatibility mode on the newest OpenGL versions?possibly a less optimized path going forward).
Preserving the modelview matrix is no biggie, but if there are more such major issues out there, it could quickly raise the learning curve.
(And I’m still not convinced 3 OpenGL render backends are actually necessary. I get two?one for fixed function and one programmable, but it seems like the OpenGL ES versions ought to run fine using SDL’s OpenGL abstraction. Nothing in the render API needs anything GLES doesn’t provide?)
Joseph
On Mon, Oct 14, 2013 at 11:39:52AM -0400, Ryan C. Gordon wrote:
What might seem like a boon in less-work-now will turn into a
disappointing rewrite when you come to the polish step.It depends on what you’re doing. The intention for the Render API was two goals:
Provide a reasonable path for modernizing 2D games (specifically: SDL 1.2 games). If one moves to the Render API, out of the box you get faster rendering, scaling, Steam Overlay support, Direct3D on Windows, GLES on iOS, etc.
Make simple games simple to write. If all you want to do is write a Super Mario clone–which itself is a stretch goal when you’re starting out–then you’re going to drown if you work with OpenGL directly. I like that you can knock out a simple game really quickly with the Render API.
But you are right: you are absolutely going to hit limits quickly if you have larger rendering ambitions. That’s sort of by design: the API meets its design goals without added complications, and we didn’t want to build a full API that abstracts every other 3D API…for those cases, we made it easy to use the existing APIs themselves.
–ryan.
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
Apparently I was wrong. I’d considered that OpenGL ES was a proper
subset of the desktop OpenGL. Apparently that’s not true without a
few #ifdef’s. And thought OpenGL ES v2 is closer to OpenGL 2.1, you
wind up needing OpenGL 3.x for shader compatibility.
Suddenly why there are three variants makes sense. Luckily on my
end I can test all three under Linux because VMWare accelerates Mesa
well enough. If you’re on Linux and using a binary video driver
you probably can’t. 
JosephOn Tue, Oct 15, 2013 at 04:40:50PM +0300, neoaggelos at gmail.com wrote:
There are three OpenGL backends because of the three major OpenGL ‘versions’: desktop OpenGL, OpenGL ES and OpenGL ES 2.
Currently, I strongly believe that none of those should be removed.
- Desktop OpenGL is required for desktop systems.
- OpenGL ES 2 is the standard backend for Android and iOS.
- OpenGL ES exists to support older hardware, which do not support OpenGL ES 2. And yes, the transition from GL ES1 to GL ES2 is impossible for older hardware. If you search the internet, you will see that both are used actively (okay, OpenGL ES 2 is getting more and more popular, but you get the point).
For the next two or three years, keeping OpenGL ES 1 is required to be compatible with an audience as wide as possible. If it were removed, then, amongst other things, the minimum supported iOS version would become 5.0, completely dropping support for pre-Lion systems.
2013/10/15 T. Joseph Carter
Apparently I was wrong. I’d considered that OpenGL ES was a proper subset
of the desktop OpenGL. Apparently that’s not true without a few #ifdef’s.
And thought OpenGL ES v2 is closer to OpenGL 2.1, you wind up needing
OpenGL 3.x for shader compatibility.Suddenly why there are three variants makes sense.
I can test all three under Linux because VMWare accelerates Mesa well
enough.
probably can’t.Joseph
nVidia binaries for Linux (and SDL!) support all three variants of OpenGL
via GLX, though ES1 just barely. They’ve also incorporated EGL support
recently, restricted to X11 for now. I don’t know if this is thanks to
Valve or not, but it’s definitely a big improvement.–
Gabriel.
Hey, I’ve got no problem limiting GLES to X on the desktop. I do
imagine some would prefer it not be so, but on a desktop system
you’re probably going to be using X anyway. GLES in that case is
really a means to develop and test your apps for embedded devices
more easily.
AMD doesn’t do this? I think any video chipset produced by Intel
already uses Mesa, so that’s not a big deal. What else is there but
embedded stuff like PowerVR?
JosephOn Tue, Oct 15, 2013 at 12:44:21PM -0300, Gabriel Jacobo wrote:
2013/10/15 T. Joseph Carter <@T_Joseph_Carter>
Apparently I was wrong. I’d considered that OpenGL ES was a proper subset
of the desktop OpenGL. Apparently that’s not true without a few #ifdef’s.
And thought OpenGL ES v2 is closer to OpenGL 2.1, you wind up needing
OpenGL 3.x for shader compatibility.Suddenly why there are three variants makes sense.
I can test all three under Linux because VMWare accelerates Mesa well
enough.
probably can’t.Joseph
nVidia binaries for Linux (and SDL!) support all three variants of OpenGL
via GLX, though ES1 just barely. They’ve also incorporated EGL support
recently, restricted to X11 for now. I don’t know if this is thanks to
Valve or not, but it’s definitely a big improvement.–
Gabriel.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org