# SDL 1.3 Roadmap

**URL:** <https://discourse.libsdl.org/t/sdl-1-3-roadmap/17091>\
**Category:** SDL Development\
**Created:** [February 1, 2010, 7:21am UTC](https://discourse.libsdl.org/t/sdl-1-3-roadmap/17091 "2010-02-01T07:21:20Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![JonnyD](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/jonnyd/32/1604_2.png) [@JonnyD](https://discourse.libsdl.org/u/JonnyD)\
**Post date:** [February 4, 2010, 2:38am UTC](https://discourse.libsdl.org/t/sdl-1-3-roadmap/17091/21 "2010-02-04T02:38:57Z")

</div>

If you trust the wiki:  
[http://www.opengl.org/wiki/GL\_EXT\_framebuffer\_object](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)  
> [http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org](http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org)

---

<div class="post-metadata">

**Author:** ![Vittorio\_Giovara](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/v/57b2e6/32.png) [@Vittorio\_Giovara](https://discourse.libsdl.org/u/Vittorio_Giovara)\
**Post date:** [February 4, 2010, 9:16pm UTC](https://discourse.libsdl.org/t/sdl-1-3-roadmap/17091/22 "2010-02-04T21:16:39Z")

</div>

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 Goldwyn[http://www.brainyquote.com/quotes/authors/s/samuel\_goldwyn.html](http://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](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)  
> [http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org](http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org)

---

<div class="post-metadata">

**Author:** ![icculus](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/icculus/32/81_2.png) [@icculus](https://discourse.libsdl.org/u/icculus)\
**Post date:** [February 5, 2010, 12:34am UTC](https://discourse.libsdl.org/t/sdl-1-3-roadmap/17091/23 "2010-02-05T00:34:56Z")

</div>

> 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.

---

<div class="post-metadata">

**Author:** ![Nathaniel\_J\_Fries](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/n/ccd318/32.png) [@Nathaniel\_J\_Fries](https://discourse.libsdl.org/u/Nathaniel_J_Fries)\
**Post date:** [February 5, 2010, 2:08am UTC](https://discourse.libsdl.org/t/sdl-1-3-roadmap/17091/24 "2010-02-05T02:08:28Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Marcel\_Wysocki](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/m/f14d63/32.png) [@Marcel\_Wysocki](https://discourse.libsdl.org/u/Marcel_Wysocki)\
**Post date:** [February 6, 2010, 3:40am UTC](https://discourse.libsdl.org/t/sdl-1-3-roadmap/17091/25 "2010-02-06T03:40:39Z")

</div>

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](http://wiki.libsdl.org/moin.cgi/Roadmap)

---

<div class="post-metadata">

**Author:** ![Mars\_999](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/mars_999/32/142_2.png) [@Mars\_999](https://discourse.libsdl.org/u/Mars_999)\
**Post date:** [February 6, 2010, 5:36am UTC](https://discourse.libsdl.org/t/sdl-1-3-roadmap/17091/26 "2010-02-06T05:36:30Z")

</div>

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](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)  
> [http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org](http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org)

---

<div class="post-metadata">

**Author:** ![michelleC](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/m/dec6dc/32.png) [@michelleC](https://discourse.libsdl.org/u/michelleC)\
**Post date:** [February 8, 2010, 2:07pm UTC](https://discourse.libsdl.org/t/sdl-1-3-roadmap/17091/27 "2010-02-08T14:07:50Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![JonnyD](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/jonnyd/32/1604_2.png) [@JonnyD](https://discourse.libsdl.org/u/JonnyD)\
**Post date:** [February 11, 2010, 3:49pm UTC](https://discourse.libsdl.org/t/sdl-1-3-roadmap/17091/28 "2010-02-11T15:49:21Z")

</div>

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 🙂  
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)  
> [http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org](http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org)

---

<div class="post-metadata">

**Author:** ![michelleC](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/m/dec6dc/32.png) [@michelleC](https://discourse.libsdl.org/u/michelleC)\
**Post date:** [February 11, 2010, 5:19pm UTC](https://discourse.libsdl.org/t/sdl-1-3-roadmap/17091/29 "2010-02-11T17:19:52Z")

</div>

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 🙂 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](http://lists.libsdl.org) (SDL at [lists.libsdl.org](http://lists.libsdl.org))  
> > [http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org](http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org) ([http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org](http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org))

---

<div class="post-metadata">

**Author:** ![michelleC](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/m/dec6dc/32.png) [@michelleC](https://discourse.libsdl.org/u/michelleC)\
**Post date:** [February 11, 2010, 5:33pm UTC](https://discourse.libsdl.org/t/sdl-1-3-roadmap/17091/30 "2010-02-11T17:33:15Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Nathaniel\_J\_Fries](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/n/ccd318/32.png) [@Nathaniel\_J\_Fries](https://discourse.libsdl.org/u/Nathaniel_J_Fries)\
**Post date:** [February 11, 2010, 10:16pm UTC](https://discourse.libsdl.org/t/sdl-1-3-roadmap/17091/31 "2010-02-11T22:16:35Z")

</div>

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)

---

<div class="post-metadata">

**Author:** ![JonnyD](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/jonnyd/32/1604_2.png) [@JonnyD](https://discourse.libsdl.org/u/JonnyD)\
**Post date:** [February 11, 2010, 10:34pm UTC](https://discourse.libsdl.org/t/sdl-1-3-roadmap/17091/32 "2010-02-11T22:34:03Z")

</div>

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)  
> [http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org](http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org)

---

<div class="post-metadata">

**Author:** ![michelleC](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/m/dec6dc/32.png) [@michelleC](https://discourse.libsdl.org/u/michelleC)\
**Post date:** [February 12, 2010, 1:08am UTC](https://discourse.libsdl.org/t/sdl-1-3-roadmap/17091/33 "2010-02-12T01:08:02Z")

</div>

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](http://lists.libsdl.org) (SDL at [lists.libsdl.org](http://lists.libsdl.org))  
> > [http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org](http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org) ([http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org](http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org))

---

<div class="post-metadata">

**Author:** ![Nathaniel\_J\_Fries](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/n/ccd318/32.png) [@Nathaniel\_J\_Fries](https://discourse.libsdl.org/u/Nathaniel_J_Fries)\
**Post date:** [February 12, 2010, 1:26am UTC](https://discourse.libsdl.org/t/sdl-1-3-roadmap/17091/34 "2010-02-12T01:26:50Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![michelleC](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/m/dec6dc/32.png) [@michelleC](https://discourse.libsdl.org/u/michelleC)\
**Post date:** [February 12, 2010, 4:15am UTC](https://discourse.libsdl.org/t/sdl-1-3-roadmap/17091/35 "2010-02-12T04:15:15Z")

</div>

[

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

---

<div class="post-metadata">

**Author:** ![michelleC](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/m/dec6dc/32.png) [@michelleC](https://discourse.libsdl.org/u/michelleC)\
**Post date:** [February 12, 2010, 4:17am UTC](https://discourse.libsdl.org/t/sdl-1-3-roadmap/17091/36 "2010-02-12T04:17:40Z")

</div>

[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.

---

<div class="post-metadata">

**Author:** ![Nathaniel\_J\_Fries](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/n/ccd318/32.png) [@Nathaniel\_J\_Fries](https://discourse.libsdl.org/u/Nathaniel_J_Fries)\
**Post date:** [February 12, 2010, 11:48am UTC](https://discourse.libsdl.org/t/sdl-1-3-roadmap/17091/37 "2010-02-12T11:48:27Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![michelleC](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/m/dec6dc/32.png) [@michelleC](https://discourse.libsdl.org/u/michelleC)\
**Post date:** [February 12, 2010, 12:43pm UTC](https://discourse.libsdl.org/t/sdl-1-3-roadmap/17091/38 "2010-02-12T12:43:50Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![slouken](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/s/ec9cab/32.png) [@slouken](https://discourse.libsdl.org/u/slouken)\
**Post date:** [February 14, 2010, 3:26pm UTC](https://discourse.libsdl.org/t/sdl-1-3-roadmap/17091/39 "2010-02-14T15:26:05Z")

</div>

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)  
> [http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org](http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org)

–  
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

---

<div class="post-metadata">

**Author:** ![Nathaniel\_J\_Fries](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/n/ccd318/32.png) [@Nathaniel\_J\_Fries](https://discourse.libsdl.org/u/Nathaniel_J_Fries)\
**Post date:** [February 14, 2010, 5:15pm UTC](https://discourse.libsdl.org/t/sdl-1-3-roadmap/17091/40 "2010-02-14T17:15:40Z")

</div>

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:

[Previous page](https://discourse.libsdl.org/t/sdl-1-3-roadmap/17091.md?page=1)

[Next page](https://discourse.libsdl.org/t/sdl-1-3-roadmap/17091.md?page=3)