SDL2 Graphics API, was Re: compiling with SDL_NO_COMPAT

Stephen_Anthony · January 21, 2012, 7:53pm

As far as Graphics go, Graphics context creation, and that’s it please.
If someone wants to write a cross platform game, they’ll use OpenGL.
If they want to appease Microsoft, they’ll use Direct3D.

And if they want performant code on all such systems, they need to write
both OpenGL and Direct3D code that basically do the same thing, but are
more optimized to their specific platforms. So one of the main reasons for
using SDL is lost.

I don’t want or care to know how SDL does its thing behind the scenes.
I just want it to be fast in both Windows and Linux/OSX. And that means
Direct3D for Windows, and OpenGL for the others.

Having everyone write both Direct3D and OpenGL code for their projects is
a complete waste of developer time. Sure, doing it in SDL is difficult, but
it’s a one-time job. Better to do it in one place, and have it optimized
and looked over by many people than to have every separate project do it.

whatever new API comes along. I want a simple layer (aka, SDL) over these
APIs that gives fast access to a framebuffer, allowing it to be stretched
and rendered in 2D. I agree that if you’re going full-on 3D mode then you
probably need to write API-specific code. But don’t force the average 2D
game developer that just wants speed to code multiple rendering backends.

Thanks,
Steve A.
Stella maintainerOn January 21, 2012 2:52:58 PM PoV wrote:

From my POV, I don’t want to write Direct3D code, or OpenGL code, or

David_Olofson · January 21, 2012, 8:07pm

[…]

But don’t force the average 2D game developer that just wants speed to code
multiple rendering backends.

There’s just this small issue of who that average 2D game developer is.

Some claim 2D is just non-scaled rectangular blits and some basic transparency
and blending, whereas others (like me, I’m afraid) would basically require all
of the OpenGL 1.4+ functionality (blend modes, triangles, polygons, separate
vertex/texture coordinates etc) minus the actual 3D stuff.

(I’m relying entirely on OpenGL at this point. May or may not bother with
Direct3D later.)On Saturday 21 January 2012, at 20.53.30, Stephen Anthony wrote:

–
//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
’---------------------------------------------------------------------’

Brian_Barnes · January 21, 2012, 8:19pm

Steve wrote:> On January 21, 2012 2:52:58 PM PoV wrote:

As far as Graphics go, Graphics context creation, and that’s it please.
If someone wants to write a cross platform game, they’ll use OpenGL.
If they want to appease Microsoft, they’ll use Direct3D.

And if they want performant code on all such systems, they need to write
both OpenGL and Direct3D code that basically do the same thing, but are
more optimized to their specific platforms. So one of the main reasons for
using SDL is lost.

I don’t want or care to know how SDL does its thing behind the scenes.
I just want it to be fast in both Windows and Linux/OSX. And that means
Direct3D for Windows, and OpenGL for the others.

Having everyone write both Direct3D and OpenGL code for their projects is
a complete waste of developer time. Sure, doing it in SDL is difficult, but
it’s a one-time job. Better to do it in one place, and have it optimized
and looked over by many people than to have every separate project do it.

From my POV, I don’t want to write Direct3D code, or OpenGL code, or
whatever new API comes along. I want a simple layer (aka, SDL) over these
APIs that gives fast access to a framebuffer, allowing it to be stretched
and rendered in 2D. I agree that if you’re going full-on 3D mode then you
probably need to write API-specific code. But don’t force the average 2D
game developer that just wants speed to code multiple rendering backends.

I use OpenGL for my game engine on Windows, and it works great. In full screen, I can push just as many polygons as I could with direct3D, and if you are writing the proper code, there is no way you’re going to have problem going with OpenGL for windows.

Remember, if you make sure to use all the fast paths, you are spending almost all you time on the card. There is nothing to be gained by using either OpenGL or Direct3D, they will both be using the same card resources in the end. Note, this means using OpenGL right, though. VBOs, etc.

If you are just making a 2D game, it’s relatively easy to create a couple sub routines to encapsulate all that (it’s probably been done somewhere in open source.) I’d really recommend learning OpenGL, especially as with the places you’ll make sales – iOS or Andriod – are all OpenGL devices.

Compile in SDL + GLEW with your windows build and you’ll have everything updated and ready to go with modern OpenGL.

[>] Brian

Forest_Hale · January 21, 2012, 8:33pm

Use cases in my engine:

A simple way to get a window and OpenGL 1/2/3/4/ES1/ES2 context.
A simple way to get a window and Direct3D 9/10/11 context.
A simple way to get a window and software surface to render into manually.

Other use cases common in indie game development and application development:
4. A simple way to get a 2D rendering API that transparently uses a software surface or OpenGL 1/2/ES1/ES2 or Direct3D 9.
5. A simple way to get a window and software surface to render into manually.
6. A simple way to get a window and YCrCb video overlay to render into manually.

All of these goals are compatible and deserve attention.

I do not believe that #4 bloats SDL because it is a very common use case, and the code involved is small.

For my game engine development, #1 is essential, #2 would be nice (I just want it to set up the context for me using the same nice SDL attributes and all), and #3 is something I currently handle using
#4 which may or may not be efficient depending on platform.On 01/21/2012 11:53 AM, Stephen Anthony wrote:

On January 21, 2012 2:52:58 PM PoV wrote:

As far as Graphics go, Graphics context creation, and that’s it please.
If someone wants to write a cross platform game, they’ll use OpenGL.
If they want to appease Microsoft, they’ll use Direct3D.

And if they want performant code on all such systems, they need to write
both OpenGL and Direct3D code that basically do the same thing, but are
more optimized to their specific platforms. So one of the main reasons for
using SDL is lost.

I don’t want or care to know how SDL does its thing behind the scenes.
I just want it to be fast in both Windows and Linux/OSX. And that means
Direct3D for Windows, and OpenGL for the others.

Having everyone write both Direct3D and OpenGL code for their projects is
a complete waste of developer time. Sure, doing it in SDL is difficult, but
it’s a one-time job. Better to do it in one place, and have it optimized
and looked over by many people than to have every separate project do it.

From my POV, I don’t want to write Direct3D code, or OpenGL code, or
whatever new API comes along. I want a simple layer (aka, SDL) over these
APIs that gives fast access to a framebuffer, allowing it to be stretched
and rendered in 2D. I agree that if you’re going full-on 3D mode then you
probably need to write API-specific code. But don’t force the average 2D
game developer that just wants speed to code multiple rendering backends.

Thanks,
Steve A.
Stella maintainer

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

–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

PoV · January 21, 2012, 8:34pm

Stephen Anthony wrote:

And if they want performant code on all such systems, they need to write both OpenGL and Direct3D code that basically do the same thing, but are more optimized to their specific platforms. So one of the main reasons for using SDL is lost.

That’s what projects like Angle are for. Write once to the OpenGL ES 2 spec, and it uses Direct3D behind the scenes. It’s redundant at the SDL level, and its consideration just further delays the release of SDL 2.0.------------------------
| Mike Kasprzak | Sykhronics Entertainment (http://www.sykhronics.com) | Blog (http://www.toonormal.com) | Twitter (http://www.twitter.com/mikekasprzak) | Ludum Dare (http://ludumdare.com) |

Stephen_Anthony · January 21, 2012, 9:10pm

If you are just making a 2D game, it’s relatively easy to create a couple sub routines to encapsulate all that (it’s probably been done somewhere in open source.) I’d really recommend learning OpenGL, especially as with the places you’ll make sales – iOS or Andriod – are all OpenGL devices.

I already know OpenGL. In fact, the project I’m working on already has
an OpenGL component (which I wrote), in addition to a software
component. I’m simply arguing that having to do that for every project
you write is a waste when it could be done once in SDL (and probably
done better because of the many-eyes approach).

Also, if OpenGL is sufficient, then why is the default backend in
Windows based on Direct3D? The projects I work on are extremely
cross-platform (we’re talking about a dozen different OS/architecture
combinations). Believe me when I say that based on feedback over the
years, Direct3D is better supported in Windows. And OpenGL is great for
Linux/OSX.

To be honest, at this point I don’t really have a horse in this race.
If the current functionality in SDL 1.3 stays as-is, it will satisfy my
needs. I just don’t want that functionality to disappear. That’s
mostly what I’m arguing for.

Thanks,
Steve A.
Stella maintainerOn 12-01-21 4:49 PM, Brian Barnes wrote:

slouken · January 22, 2012, 6:47am

Tell ya what… if somebody provides a fully working patch for all
renderers including software, and all the filtering and scaling issues are
resolved to the satisfaction of everyone on the list, I will either
officially incorporate it into SDL_render or make it available as a
recommended extension (crediting everyone involved, of course).

Remember, keep it simple, and it needs to be fast enough to be a viable API
using the software renderer.

Here are some good places to start:
http://bugzilla.libsdl.org/show_bug.cgi?id=1308
http://bugzilla.libsdl.org/show_bug.cgi?id=1181

Cheers!On Wed, Jan 18, 2012 at 5:21 AM, Pallav Nawani wrote:

SDL2 = SDL1.3 + Code for Rotation & stretch blit simultaneously
Or
SDL provides a way for the user to get hold of the underlying graphics API
(DirectX/OpenGL) to allow me to implement the above code in my game without
touching SDL itself.

On 18-01-2012 10:42, Bob Pendleton wrote:

On Sun, Jan 8, 2012 at 2:00 AM, Sam Lantinga<@slouken> wrote:

Bob, I don’t think we’re quite ready to talk about this, unless you’re
talking about something you’d like to write and maintain separately from
SDL.

I waited a long time to reply because I wanted to “stir the pot” and
see what people had to say. I really do want to start a long term
project based on SDL2. But, mostly I wanted to see what people really
want.

Bob Pendleton

On Sun, Jan 8, 2012 at 1:28 AM, Bob Pendleton wrote:

If we are going to start talking about what features should be in the
graphics API for SDL2 I think we should start a new thread.

Since this is a 3D API based running on top of modern hardware I’m
going to suggest that it should include layers. We have a Z-Buffer,
even though we are just doing 2D doesn’t mean we shouldn’t use it. It
makes doing so many things so much easier.

Also, I’ve heard a lot of people talking about render to texture as a
requirement, and I’m very much in favor of that, so the minimum
version of OpenGL/DirectX that can be supported is the first version
that supports that functionality.

While is is possible to build up all the graphic primitives, such as
lines, circles, and so on, from a simple scan line fill operation, it
is also pretty trivial to provide a set of solid fill and textured
primitives based on the underlying libraries. They do not have to
complex. It is possible to do textured primitives without ever
specifying a texture coordinate.

And, lets not forget fonts. People need fonts.

A critical problem is the coordinate system to be used. Using Pixels
is rather natural. But, then the library needs to be able to scale
everything for when the window changes size.

Bob Pendleton

To make a modern 2D system anyone want to talk about doing it based
on SVG instead of pixels?

Bob Pendleton

On Fri, Jan 6, 2012 at 9:53 PM, bala_48225<bala_48225 at yahoo.**com<bala_48225 at yahoo.com>> wrote:

So far I haven’t used SDL 1.3, but as far as the proposed
split-from-base 2D
rendering API
is concerned, perhaps its features could be limited, basic and modern:

Allow the user to flip, rotate and scale images; 2) Provide multiple
alpha blend modes for
images, including multiply alpha, and 3) Provide something akin to SDL
1.2’s
SDL_FillRect,
perhaps with blending modes as well.

The last feature could put the burden for simpler functions such as
lines
and circles on the user,
and the possibility of having a bloated fixed-function pipeline could
thus
be evaded. The only
other thing I can think is, maybe the rendering API could support less
platforms than the rest of SDL
does, thus decreasing its development overhead. For my part I don’t see
why
any DirectX prior to 8 or
later than 9 would be necessary to support for a 2D API, and OpenGL
should
be supported from 1.0.
Those three features I suggested should update SDL to the 2010s while
keeping it low-level from the
user’s perspective.

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

–
±----------------------------**------------------------------

Bob Pendleton: writer and programmer

email: Bob at Pendleton.com

web: www.TheGrumpyProgrammer.com
_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-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 http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
Pallav Nawani
Game Designer/Writer/CEO
http://www.ironcode.com
Twitter: http://twitter.com/Ironcode_**Gaming http://twitter.com/Ironcode_Gaming
Facebook: http://www.facebook.com/**Ironcode.Gaming http://www.facebook.com/Ironcode.Gaming
Mobile: 9997478768

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

Gabriel_Jacobo · January 22, 2012, 3:41pm

2012/1/22 Sam Lantinga

Tell ya what… if somebody provides a fully working patch for all
renderers including software, and all the filtering and scaling issues are
resolved to the satisfaction of everyone on the list, I will either
officially incorporate it into SDL_render or make it available as a
recommended extension (crediting everyone involved, of course).

Given the vast array of opinions I saw in this discussion, I think there’s
a better chance of SDL gaining conciousness and killing all of us in the
process than resolving the issues to everyone’s satisfaction, but anyway,
I’ll start by updating my patch so it applies cleanly and we can work from
that with anyone who’s interested.

Gabriel.

Gabriel_Jacobo · February 1, 2012, 1:06pm

2012/1/22 Sam Lantinga

Tell ya what… if somebody provides a fully working patch for all
renderers including software, and all the filtering and scaling issues are
resolved to the satisfaction of everyone on the list, I will either
officially incorporate it into SDL_render or make it available as a
recommended extension (crediting everyone involved, of course).

Remember, keep it simple, and it needs to be fast enough to be a viable
API using the software renderer.

Here are some good places to start:
http://bugzilla.libsdl.org/show_bug.cgi?id=1308
http://bugzilla.libsdl.org/show_bug.cgi?id=1181

Cheers!

I’ve updated the RenderCopyEx patch at
http://bugzilla.libsdl.org/show_bug.cgi?id=1308 , it now supports all
renderers (including software). The software renderer functionality is
implemented with lightly modified code taken from the SDL_gfx library (Zlib
license acording to http://www.ferzkopp.net/joomla/content/view/19/14/ ).
The total bloat coming from this incorporation is fairly small in my
opinion (two functions to rotate 24 and 8 bit surfaces, one to precalculate
a few values), and it is all kept in a separate file. The RenderCopyEx
provides rotation around the center or arbitrary point, and flipping in
both directions. The 24 bit software backend does nearest and bilinear
interpolation as well.
Sam told me to submit the new patch to the list to see the repercusion it
gets, after which he’ll consider it for adoption…so, let us know what you
think!

Thanks!–
Gabriel.

Rainer_Deyke · February 1, 2012, 6:00pm

Wouldn’t it make more sense to have a function to render arbitrary
textured quads? It’s easy to implement rotation on top of arbitrary
quads, but it’s impossible to implement arbitrary quads on top of rotation.On 2012-02-01 14:06, Gabriel Jacobo wrote:

I’ve updated the RenderCopyEx patch at
http://bugzilla.libsdl.org/show_bug.cgi?id=1308 , it now supports all
renderers (including software). The software renderer functionality is
implemented with lightly modified code taken from the SDL_gfx library (Zlib
license acording to http://www.ferzkopp.net/joomla/content/view/19/14/ ).
The total bloat coming from this incorporation is fairly small in my
opinion (two functions to rotate 24 and 8 bit surfaces, one to precalculate
a few values), and it is all kept in a separate file. The RenderCopyEx
provides rotation around the center or arbitrary point, and flipping in
both directions. The 24 bit software backend does nearest and bilinear
interpolation as well.

–
Rainer Deyke (rainerd at eldwood.com)

Pallav_Nawani · February 2, 2012, 5:49am

Awesome, this looks like just what was needed!
(Well, it is just what I needed anyway).

+1 for the patch to be incorporated into SDL.On 01-02-2012 18:36, Gabriel Jacobo wrote:

2012/1/22 Sam Lantinga <slouken at libsdl.org <mailto:slouken at libsdl.org>>
Tell ya what... if somebody provides a fully working patch for all
renderers including software, and all the filtering and scaling
issues are resolved to the satisfaction of everyone on the list, I
will either officially incorporate it into SDL_render or make it
available as a recommended extension (crediting everyone involved,
of course).

Remember, keep it simple, and it needs to be fast enough to be a
viable API using the software renderer.

Here are some good places to start:
http://bugzilla.libsdl.org/show_bug.cgi?id=1308
http://bugzilla.libsdl.org/show_bug.cgi?id=1181

Cheers!
I’ve updated the RenderCopyEx patch at
http://bugzilla.libsdl.org/show_bug.cgi?id=1308 , it now supports all
renderers (including software). The software renderer functionality is
implemented with lightly modified code taken from the SDL_gfx library
(Zlib license acording to
http://www.ferzkopp.net/joomla/content/view/19/14/ ). The total bloat
coming from this incorporation is fairly small in my opinion (two
functions to rotate 24 and 8 bit surfaces, one to precalculate a few
values), and it is all kept in a separate file. The RenderCopyEx
provides rotation around the center or arbitrary point, and flipping
in both directions. The 24 bit software backend does nearest and
bilinear interpolation as well.
Sam told me to submit the new patch to the list to see the repercusion
it gets, after which he’ll consider it for adoption…so, let us know
what you think!

Thanks!

Gabriel.

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

–
Pallav Nawani
Game Designer/Writer/CEO
http://www.ironcode.com
Twitter: http://twitter.com/Ironcode_Gaming
Facebook: http://www.facebook.com/Ironcode.Gaming
Mobile: 9997478768

Pallav_Nawani · February 6, 2012, 10:19am

So does everyone agree that this patch is a good idea?
If so, this patch can be included into SDL_render.On 01-02-2012 18:36, Gabriel Jacobo wrote:

2012/1/22 Sam Lantinga <slouken at libsdl.org <mailto:slouken at libsdl.org>>
Tell ya what... if somebody provides a fully working patch for all
renderers including software, and all the filtering and scaling
issues are resolved to the satisfaction of everyone on the list, I
will either officially incorporate it into SDL_render or make it
available as a recommended extension (crediting everyone involved,
of course).

Remember, keep it simple, and it needs to be fast enough to be a
viable API using the software renderer.

Here are some good places to start:
http://bugzilla.libsdl.org/show_bug.cgi?id=1308
http://bugzilla.libsdl.org/show_bug.cgi?id=1181

Cheers!
I’ve updated the RenderCopyEx patch at
http://bugzilla.libsdl.org/show_bug.cgi?id=1308 , it now supports all
renderers (including software). The software renderer functionality is
implemented with lightly modified code taken from the SDL_gfx library
(Zlib license acording to
http://www.ferzkopp.net/joomla/content/view/19/14/ ). The total bloat
coming from this incorporation is fairly small in my opinion (two
functions to rotate 24 and 8 bit surfaces, one to precalculate a few
values), and it is all kept in a separate file. The RenderCopyEx
provides rotation around the center or arbitrary point, and flipping
in both directions. The 24 bit software backend does nearest and
bilinear interpolation as well.
Sam told me to submit the new patch to the list to see the repercusion
it gets, after which he’ll consider it for adoption…so, let us know
what you think!

Thanks!

Gabriel.

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

–
Pallav Nawani

bala_48225 · February 17, 2012, 4:25am

Well starting from the other end this time, if SDL 2.0 could create a DX9 rendering context, that would be awesome,
because then SDL users who are learning/using DirectX could avoid having to use WinApi WinMain() and its attendant
global functions! Thus they could use SDL for input, delays and windowing! Btw, is this planned? I’ve looked around
a bit but I can’t tell.

josebagar · March 9, 2012, 4:54pm

Sorry to bother but, has any decision been taken on this regard? I’d really benefit from this and wouldn’t like to resort to unofficial code…