SDL 1.3 Roadmap

If you trust the wiki:
http://www.opengl.org/wiki/GL_EXT_framebuffer_object
"GL_ARB_framebuffer_object brings together GL_EXT_framebuffer_object,
GL_EXT_framebuffer_blit, GL_EXT_framebuffer_multisample,
GL_EXT_packed_depth_stencil which are all folded into the core of GL 3.0."

Jonny DOn Wed, Feb 3, 2010 at 8:30 PM, nfries88 wrote:

Bob wrote:

On Tue, Feb 2, 2010 at 9:51 PM, Sam Lantinga <> wrote:
Are we talking about adding it to the SDL 2D graphics API or are we
talking about making sure that the version of the OpenGL API that SDL
provides includes at least the full OpenGL 3.1 API so we have access
to texture, render, and frame buffer objects? Seems like you have to

have a video card and graphics drivers that can support OGL 3.1 before
you can safely add anything to the 2D API.

We are talking about adding it to the 2D API, of course.
Worst-case scenario, if SDL is unable to retrieve an OpenGL context for the
appropriate version, it can be done in software by the method discussed by
hardcoder:

[quote=hardcoder]Render target is a way powerful thing than just a “blit
target”. Blitting one texture to another can be easily achieved using
software blending/adding/whatever with pixels read back from video driver.
This doesn’t have much sense thou since textures are not meant to be
modified often in runtime and if it is only about blending few images
together it can be done using surface blits and using resulting surface as
texture source.[/quote]
Is this optimal? No. Will it produce the same quality of results that the
proper method would do? Likely not. Will it, for all intensive purposes, do
the job? Sure will.

I know support is trivial in DirectDraw, and I’d bet it’s not much more
difficult in Direct3D. It’s trivial in software, too. OpenGL is the only
real issue here, and only in versions earlier than 3.0 (or, from what you’re
saying, 3.1? You’re probably right, but I could swear FBOs were mentioned in
3.0 specification too when I read it).


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

I agree with my 2 cents as well
i’m not really sure a released product would attract more manpower, but more
documentation would certainly do!

vittorio

Samuel Goldwynhttp://www.brainyquote.com/quotes/authors/s/samuel_goldwyn.html

  • "I’m willing to admit that I may not always be right, but I am never
    wrong."On Wed, Feb 3, 2010 at 4:00 PM, Gaetan de Menten wrote:

On Mon, Feb 1, 2010 at 08:21, Sam Lantinga wrote:

I put together a roadmap of the work left to do on SDL 1.3, which I’ll
keep up to date as things are done:
http://wiki.libsdl.org/moin.cgi/Roadmap

I’d love your feedback on this list.

If you’d like to help out with any of the items, even if they’re
already assigned, please let me know and I’ll be happy to coordinate
with you!

Thanks for sharing, I have been wondering about the “big picture” of
1.3 development for a while…

But… Is it just me or does this list (only counting the "required"
stuff of course) sounds a bit too ambitious and will take ages to
finish? Wouldn’t it be better to polish the strict minimum features,
document them and make a first release, and only then develop the
remaining functionality? That way you would probably have more
manpower to develop those remaining functionalities (a released
product is more interesting than a developing one)… As far as I am
concerned, all features which are not done yet and will not need to
change the API of any existing subsystem should be postponed, no
matter how exciting and cool they seem (unless it is developed by
someone who wouldn’t develop anything else anyway)… Just my 0.02$,
for whatever it’s worth.


Ga?tan de Menten


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

It really needs someone who works on SDL to rework how input is done.

It’s on my TODO list. The current API was a bit too ambitious about
making everything unified. I’d like to split it into mouse (cursor)
events, which work in relation to the desktop/window like you’d expect
in a GUI environment, and lowlevel device event that don’t map to the
window at all (if there’s no mouse cursor with a given mouse, what
screen coordinates do you report?).

Also: a proper multi-touch API has yet to be seriously considered.

–ryan.

Ryan C. Gordon wrote:

Also: a proper multi-touch API has yet to be seriously considered.

I wish I knew enough about how any systems handle touch input themselves to put in anything worth a damn on this.
Would it be possible for SDL to report “un-touches” (when the input is no longer applied) and “touch movements” consistently on different platforms? If so, the event modeling would be very similar to that of multiple mice. If not, that complicates things, especially when considering the API’s applications for games using touchscreens.

looks nice, maybe add “1.2 to 1.3 migration guide” to the General
section. i guess many people would want such a thing
before switching to 1.3On 02/01/2010 08:21 AM, Sam Lantinga wrote:

I put together a roadmap of the work left to do on SDL 1.3, which I’ll
keep up to date as things are done:
http://wiki.libsdl.org/moin.cgi/Roadmap

I am going to throw my two cents in, I would support GL 3.2 RC as a
baseline now and not worry about GL 3.0. The same hardware need for 3.0
is the same for 3.2…On 2/5/2010 9:40 PM, Marcel Wysocki wrote:

On 02/01/2010 08:21 AM, Sam Lantinga wrote:

I put together a roadmap of the work left to do on SDL 1.3, which I’ll
keep up to date as things are done:
http://wiki.libsdl.org/moin.cgi/Roadmap
looks nice, maybe add “1.2 to 1.3 migration guide” to the General
section. i guess many people would want such a thing
before switching to 1.3


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

Does anyone even remotely consider sdl a viable platform for the iphone.

With all its limitations on windowing and the gui seems more like something the KGB would design, DO IT MY WAY OR NO WAY.

I am totally disappointed with SDL 1.3.

SDL is more like DIY. It does what needs to be done in order for your apps
to be portable to many different platforms. Other features exist in add-on
libraries. If there is not an add-on library that fits your needs for a
particular platform, then you should write it :slight_smile:
SDL’s license lets you take it and modify it to your heart’s content, though
it’d be nice to submit patches if you fix something or make something good.

Jonny DOn Mon, Feb 8, 2010 at 9:07 AM, michelleC wrote:

Does anyone even remotely consider sdl a viable platform for the iphone.

With all its limitations on windowing and the gui seems more like something
the KGB would design, DO IT MY WAY OR NO WAY.

I am totally disappointed with SDL 1.3.


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

Jonny D wrote:> SDL is more like DIY. ?It does what needs to be done in order for your apps to be portable to many different platforms. ?Other features exist in add-on libraries. ?If there is not an add-on library that fits your needs for a particular platform, then you should write it :slight_smile: SDL’s license lets you take it and modify it to your heart’s content, though it’d be nice to submit patches if you?fix something or?make something good.

There should always be a way to get at the native hardware and sdk of a platform, regardless if your designing for cross platform or not.

Why should I have to write a addone library for tableviews if there is a common sdk that does that.

Sdl for the iphone is a straight port of the linux code and takes no considerabtion of the iphone environment.

I can’t even see for instance where the core_audio_iphone.c class is even used.

Here’s my take

If you are an sdl developer on another platform than maybe sdl makes sense if you want to port your game without learning any objective-c.
(if you have enough c experience that you can follow the sdl code than learning objective-c is going to be easier)

OR

The unlikely chance that you just want to create a game without any common phone features.

But if you are a resonable objective-c iphone developers what are the pros and cons of SDL over just building in openGL, the iphone sdk or another less restrictive library like openframeworks.

pros

  1. Lot of available code that can be reversed engineered and is optimized from years of development on other platforms.
  2. platform independence.

Cons

  1. No known trackrecord for approval for the app store approval
  2. have to find an add on library or write code for something available in the sdk with just a few lines of code.
    tableviews, imagepickers , address pickers…
  3. No easy way to get at iphone hardware , gps for instance
  4. The simplest task are very hard, getting a url passed to the app for instance.

If you disagree I be interested to hear your thoughts. But remember I am addressing sdl for use on the iphone only, its nice that you can take the code and only with some changes move it to another platform but that doesn’t outway the cons.

I think that sdl will fit the same little niche market as mundo , when it comes to iphone development.

Jonny D

On Mon, Feb 8, 2010 at 9:07 AM, michelleC <@michelleC (@michelleC)> wrote:

  Does anyone even remotely consider sdl a viable platform for the iphone.

With all its limitations on windowing and the gui seems more like something the KGB would design, DO IT MY WAY OR NO WAY.

I am totally disappointed with SDL 1.3.


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

Again just addressing the iphone.

Here is a simple task, someone just starting in iphone development can do it in maybe a day, I probably could do it in about 10 or 15 minutes.
Tell how you can do it in sdl without resorting to some third party library.

  1. open a url page and retrieve a list of game users
  2. display a pick list in any convienent ui component, tableview, dropdown or uiwebview. Doesn’t matter any.
  3. allow the user to pick a user from the list
  4. Display this info on the game screen

Its taken me a few days just to figure out how to do number 1, I haven’t even come up with a way to do 2,3 or 4.

To me that is a limitation.

Also should a static library added to your app have that much control over the ui??? I think no

If you really want to get some exposure on the iphone and acceptance by developers, which considering the iphone popularity than I think you need to do a few things.

  1. Its fine that sdl takes over the environment BUT

You should also have the ability to just use individual library function.

For instance there is no reason that sdl-surfaces can’t be blitted (I think thats the correct term) to opengl textures.

There is no reason that the audio subsystem can’t have standalone methods that can be called 0utside the event loop. (I am working on a poc of that concept)

There is no reason that the app delegate method can’t be exposed in such a way thats is available.

michelleC wrote:

Again just addressing the iphone.

Here is a simple task, someone just starting in iphone development can do it in maybe a day, I probably could do it in about 10 or 15 minutes.
Tell how you can do it in sdl without resorting to some third party library.

  1. open a url page and retrieve a list of game users
  2. display a pick list in any convienent ui component, tableview, dropdown or uiwebview. Doesn’t matter any.
  3. allow the user to pick a user from the list
  4. Display this info on the game screen

1-3 is outside of the scope of SDL. It is beyond “simple”. DIY.
4 is easy enough, but still requires you to DIY, just without touching messy system stuff (especially messy on a Mac OS X based platform, Objective-C makes my head hurt)

Concurring with Nate’s comments, I think you’re misinterpreting the scope of
SDL. It was not designed just for the iPhone (hence C, not obj-C) and I
would say it isn’t meant to make iPhone apps easily portable. It is meant
to make apps for other systems easily portable, even to the iPhone.
Certainly there are better libraries to use than SDL when developing for
the iPhone, but the benefit is that most of your code will work on other
systems. You’ll only have to rewrite the iPhone-specific parts that you are
mentioning in your comments.

Don’t let me hamper you from suggesting features for the iPhone port,
though. Those are definitely welcome. I just kindly take offense at
criticizing SDL without understanding it or its community.

Jonny DOn Thu, Feb 11, 2010 at 12:33 PM, michelleC wrote:

Again just addressing the iphone.

Here is a simple task, someone just starting in iphone development can do
it in maybe a day, I probably could do it in about 10 or 15 minutes.
Tell how you can do it in sdl without resorting to some third party
library.

  1. open a url page and retrieve a list of game users
  2. display a pick list in any convienent ui component, tableview, dropdown
    or uiwebview. Doesn’t matter any.
  3. allow the user to pick a user from the list
  4. Display this info on the game screen

Its taken me a few days just to figure out how to do number 1, I haven’t
even come up with a way to do 2,3 or 4.

To me that is a limitation.

Also should a static library added to your app have that much control over
the ui??? I think no

If you really want to get some exposure on the iphone and acceptance by
developers, which considering the iphone popularity than I think you need to
do a few things.

  1. Its fine that sdl takes over the environment BUT

You should also have the ability to just use individual library function.

For instance there is no reason that sdl-surfaces can’t be blitted (I think
thats the correct term) to opengl textures.

There is no reason that the audio subsystem can’t have standalone methods
that can be called 0utside the event loop. (I am working on a poc of that
concept)

There is no reason that the app delegate method can’t be exposed in such a
way thats is available.


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

Ok, but constructive criticism is good and important.

And that stuff about rewritting only the iphone code is a big chunk which shouldn;t be necessary.

We have a little thing called a code review were we tear apart each others code, sure we don’t like it, but it makes for cleaner more maintainable code.

I am just stating my opinion on what would be acceptable to an iphone developer. I’ve been an iphone developer for sometimes, and helped to write several apps. And no matter how good your library is if you circumvent the native functions of the phone the way this does then your just not going to get our attention.

However, I did not mean to belittle your work, actually I respect it and think it has tons of potential. And I know you have higher priorities than the iphone, telling by your roadmap I would say you have a lot on your plate.

That said , if I end up being the one adding the features my segment requires than so be it. I’m just frustrated when I can’t find a good starting point. handling open passing parms to the app from a calling app (which may make the app unacceptable to reviewers, I’m not sure) took quite a bit of research in itself. getting hold of the appdelegate and finding a place to add some shared keychain support took quite a bit of research. When thats POC is finished I will provide it to this community.

Trying to isolate parts of the audio subsystem may take longer.

And forcing sdl-surfaces into opengl textures is going to take a lot more reverse engineering. But those are the three items i think would move SDL more quickly into the iphone developer space.

Porting sdl to Android and having similar hooks would open up even more of a market.

Jonny D wrote:> Concurring with Nate’s comments, I think you’re misinterpreting the scope of SDL. ?It was not designed just for the iPhone (hence C, not obj-C) and I would say it isn’t meant to make iPhone apps easily portable. ?It is meant to make apps for other systems easily portable, even to the iPhone. ?Certainly there are better libraries to use than SDL when developing for the iPhone, but the benefit is that most of your code will work on other systems. ?You’ll only have to rewrite the iPhone-specific parts that you are mentioning in your comments.

Don’t let me hamper you from suggesting features for the iPhone port, though. ?Those are definitely welcome. ?I just kindly take offense at criticizing SDL without understanding it or its community.

Jonny D

On Thu, Feb 11, 2010 at 12:33 PM, michelleC <@michelleC (@michelleC)> wrote:

  Again just addressing the iphone.

Here is a simple task, someone just starting in iphone development can do it in maybe a day, I probably could do it in about 10 or 15 minutes.
Tell how you can do it in sdl without resorting to some third party library.

  1. open a url page and retrieve a list of game users
  2. display a pick list in any convienent ui component, tableview, dropdown or uiwebview. Doesn’t matter any.
  3. allow the user to pick a user from the list
  4. Display this info on the game screen

Its taken me a few days just to figure out how to do number 1, I haven’t even come up with a way to do 2,3 or 4.

To me that is a limitation.

Also should a static library added to your app have that much control over the ui??? I think no

If you really want to get some exposure on the iphone and acceptance by developers, which considering the iphone popularity than I think you need to do a few things.

  1. Its fine that sdl takes over the environment BUT

You should also have the ability to just use individual library function.

For instance there is no reason that sdl-surfaces can’t be blitted (I think thats the correct term) to opengl textures.

There is no reason that the audio subsystem can’t have standalone methods that can be called 0utside the event loop. (I am working on a poc of that concept)

There is no reason that the app delegate method can’t be exposed in such a way thats is available.


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

michelleC wrote:

I am just stating my opinion on what would be acceptable to an iphone developer. I’ve been an iphone developer for sometimes, and helped to write several apps. And no matter how good your library is if you circumvent the native functions of the phone the way this does then your just not going to get our attention.

However, I did not mean to belittle your work, actually I respect it and think it has tons of potential. And I know you have higher priorities than the iphone, telling by your roadmap I would say you have a lot on your plate.

Then make your suggestions in a way that SDL can; without overstepping its bounds as a thin layer over system code, and still working the same whether it be on a PC, a phone, or on a gaming device, do what you want it to do.

To me it sounded like you wanted SDL to be a HTTP client and HTML parser. This is not its goal. It sounded like you wanted it to be a layer over the system’s widget toolkit. This, again, is not it’s goal. These are things for which third-party libraries must be made, and many already exist (although iPhone ports may not exist).

As for some other things you’re mentioning:

michelleC wrote:

Trying to isolate parts of the audio subsystem may take longer.

I’ve never tried SDL for the iPhone. It doesn’t do this?

michelleC wrote:

And forcing sdl-surfaces into opengl textures is going to take a lot more reverse engineering. But those are the three items i think would move SDL more quickly into the iphone developer space.

Are you suggesting conversion from an SDL_Surface (from SDL 1.2) to a GLuint (an opengl texture id), or the render-to-texture/“render target” feature we’ve been talking about in this thread in the first place?

michelleC wrote:

Porting sdl to Android and having similar hooks would open up even more of a market.

I can only agree that an SDL port for Android would be a great thing, and make the Android system available to many more pieces of open source software.

[

As for some other things you’re mentioning:

I’ll assume you never programmed using the iphone sdk.

Parsing html and post http requests is something the iphone does out of the box, sdl as a total environment for the iphone IS NEVER going to fly.

SDL as a subsystem which cooperates with other software on the iphone may have a chance.

I

[quote=“nfries88”]
michelleC wrote:

michelleC wrote:

Trying to isolate parts of the audio subsystem may take longer.

I’ve never tried SDL for the iPhone. It doesn’t do this?

[

No once you use SDL you might as well assume there is no uikit. period.

michelleC wrote:

nfries88 wrote:

michelleC wrote:

Trying to isolate parts of the audio subsystem may take longer.

I’ve never tried SDL for the iPhone. It doesn’t do this?

No once you use SDL you might as well assume there is no uikit. period.[/quote]

Then “enable SDL applications to use native UI (such as UIKit on iPhone)” would be an excellent suggestion.

nfries88 wrote:

michelleC wrote:

nfries88 wrote:

michelleC wrote:

Trying to isolate parts of the audio subsystem may take longer.

I’ve never tried SDL for the iPhone. It doesn’t do this?

No once you use SDL you might as well assume there is no uikit. period.

Then “enable SDL applications to use native UI (such as UIKit on iPhone)” would be an excellent suggestion.

From what I’ve been reading it sounds like earlier versions of sdl 1.2 on mac osx had the ability to use the xib file and allow access to the uikit but this was removed because of incompatablilites with leopard or snow leporad.

I am going to start a new thread on, this is moving away from a discussion of roadmaps (sorry) and into a development path.

In fact intention was never to criticize because sdl looks like it was a huge undertaking. AND I have no intention to make a request and wait for it to be considered.

Rather I am going to pull as much info together as I can, create the functionality I need and IF the sdl providers want to include that in the base thats fine with me. If not than the code is just unique to my app.

So does anyone have a concrete proposal for an API and implementation
that would work well here?On Wed, Feb 3, 2010 at 11:35 AM, Mason Wheeler wrote:

Fair enough.? And I bet different people will have different ideas and
different needs.? What I need is an intermediate texture object.

Currently we have SDL_Window, an object that you can render to, either
directly (SDL_RenderLine, for example) or by copying from a texture.
SDL_Window also has another intrinsic characteristic: whatever you render
gets displayed on screen.? We also have SDL_Texture, an object that you can
render from onto a SDL_Window.

We have three intrinsic characteristics here: 1) Object you can render to,
2) object you can render from, and 3) object that displays its contents
on-screen.? SDL_Window has #1 and #3, SDL_Texture has #2.? I need an object
that has #1 and #2, and not #3.? I’ve been referring to that as a render
target, for the sake of convenience.? If this isn’t the correct term, what
is?


From: hardcoder
Subject: Re: [SDL] SDL 1.3 Roadmap

Render target is a way powerful thing than just a “blit target”. Blitting
one texture to another can be easily achieved using software
blending/adding/whatever with pixels read back from video driver. This
doesn’t have much sense thou since textures are not mean to be modified
often in runtime and if it is only about blending few images together it can
be done using surface blits and using resulting surface as texture source.
Render target as the name implies a a target for a renderer pipeline. It has
associated buffers like depth, stencil etc. Do we really need that for 2D
applications?


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


-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

Sam Lantinga wrote:

So does anyone have a concrete proposal for an API and implementation
that would work well here?

We have three intrinsic characteristics here: 1) Object you can render to,
2) object you can render from, and 3) object that displays its contents
on-screen.? SDL_Window has #1 and #3, SDL_Texture has #2.? I need an object
that has #1 and #2, and not #3.? I’ve been referring to that as a render
target, for the sake of convenience.? If this isn’t the correct term, what
is?

Well, I agree with the characteristics described by Mason Wheeler here. So here’s my suggested API. Also taking into consideration what was said about the difference between our suggestion and “Render targets”, we maybe should call them “Render Buffers”?

Code:

// Tells whether or not the renderer supports render buffer - since GL support will require 3.0+ context
bool SDL_RendererSupportsRenderBuffer(SDL_Renderer*);
// Make a render buffer
SDL_RenderBuffer* SDL_CreateRenderBuffer(Uint32 format, int w, int h);
// Get a render buffer from a window (important for the next function)
SDL_RenderBuffer* SDL_GetWindowRenderBuffer(SDL_Window*);
// Set the target to a render buffer, by default it should be the window’s render buffer
SDL_RenderSetTarget(SDL_RenderBuffer*);

This should be enough to work with, right?> On Wed, Feb 3, 2010 at 11:35 AM, Mason Wheeler wrote: