The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.


SDL Forum Index
SDL
Simple Directmedia Layer Forums
SDL 1.3 Roadmap
Sam Lantinga


Joined: 10 Sep 2009
Posts: 1765
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!

See ya!
--
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Sockerdrickan


Joined: 24 Jan 2010
Posts: 7
"Sam: Reimplement mouse grab support"

Would this make mouse warping work?
SDL 1.3 Roadmap
Vittorio G.
Guest

hi Sam,
good job for setting up the roadmap.
One addition i would make is to expand the iphone and iphone-like devices support

There could be a section which includes
- support for landscape mode
- support for opengl es 2.0 contex - support for ipad
- important aspects missing (like audio in)

ipad support *should* be trivial as it's the same os with a bigger resolution...
the rest, expecially landscape mode (implemented in a proper way, with autorotation and or user setup) seem more complex

Cheers
Vittorio

Samuel Goldwyn  - "I don't think anyone should write their autobiography until after they're dead."

On Mon, Feb 1, 2010 at 8:21 AM, Sam Lantinga wrote:
Quote:
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!

See ya!
--
       -Sam Lantinga, Founder and President, Galaxy Gameworks LLC
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
DrChill


Joined: 02 Feb 2010
Posts: 3
I look forward to multiple windows Smile

I wish I could help, but I am still inexperienced(I can't even get SDL in windows).

Also could you make a feature on this forum to report peoples post, or give me moderator status Smile merely for instances of advertising, like this: http://forums.libsdl.org/viewtopic.php?t=5867
(especially in the announcements section)
ArrogantProgrammer


Joined: 03 Feb 2010
Posts: 8
Sockerdrickan wrote:
"Sam: Reimplement mouse grab support"

Would this make mouse warping work?


See my thread created today, I implemented mouse grab support in SDL 1.3 . It's a bit hacky though in that it only supports relative movement.

It really needs someone who works on SDL to rework how input is done. We need a cursor event for cursor movements sent by the OS, *AND* a way to read the raw mouse input for whatever other functions we can use the mouse for (mouse look in a FPS for instance). If I had my way I would have done it already.
SDL 1.3 Roadmap
Mason Wheeler
Guest

I just looked it over, and I was very disappointed not to see anything
about render targets. This is critical functionality that's absolutely
needed for SDL 1.3.



Quote:
----- Original Message ----
From: Sam Lantinga
Subject: [SDL] SDL 1.3 Roadmap

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!
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Re: SDL 1.3 Roadmap
nfries88


Joined: 24 Oct 2009
Posts: 100
Mason Wheeler wrote:
I just looked it over, and I was very disappointed not to see anything
about render targets. This is critical functionality that's absolutely
needed for SDL 1.3.


I cannot agree enough.
ArrogantProgrammer


Joined: 03 Feb 2010
Posts: 8
If you want a 3D engine use irrlicht or ogre3d. I can't see how SDL will ever be able to compete in that realm and there is no point in doing so. Where it can compete is in offering a basic setup that is cross platform.

INPUT, video setup, windowing, things like this. The other 3D engines have been working exclusively on 3D for years, to come into the game now would take years to hit feature parity.
nfries88


Joined: 24 Oct 2009
Posts: 100
ArrogantProgrammer wrote:
If you want a 3D engine use irrlicht or ogre3d. I can't see how SDL will ever be able to compete in that realm and there is no point in doing so. Where it can compete is in offering a basic setup that is cross platform.

INPUT, video setup, windowing, things like this. The other 3D engines have been working exclusively on 3D for years, to come into the game now would take years to hit feature parity.


I have a 2d project that would benefit from this. Blitting to texture is easily accomplished in directdraw and opengl, and I'm sure it's simple enough in direct3d as well.
It's a tile-based game with a resizable game area (based on dimensions of the window its in), so rather than scale each individual sprite's texture it'd be way better to blit to a single texture at normal size and scale the finished product.

This will also make it easier to implement light mapping, which is on our roadmap, since we won't need to worry about scaling that.
ArrogantProgrammer


Joined: 03 Feb 2010
Posts: 8
nfries88 wrote:
ArrogantProgrammer wrote:
If you want a 3D engine use irrlicht or ogre3d. I can't see how SDL will ever be able to compete in that realm and there is no point in doing so. Where it can compete is in offering a basic setup that is cross platform.

INPUT, video setup, windowing, things like this. The other 3D engines have been working exclusively on 3D for years, to come into the game now would take years to hit feature parity.


I have a 2d project that would benefit from this. Blitting to texture is easily accomplished in directdraw and opengl, and I'm sure it's simple enough in direct3d as well.
It's a tile-based game with a resizable game area (based on dimensions of the window its in), so rather than scale each individual sprite's texture it'd be way better to blit to a single texture at normal size and scale the finished product.

This will also make it easier to implement light mapping, which is on our roadmap, since we won't need to worry about scaling that.


Ok I see, you basically just want a simple way to specify the target of a blit/other operation, ie screen or another surface? This wouldn't take very long to add at all and I guess it should be in there. Though there are some restrictions in 3D world, like size of textures that make it rather tricky.

Usually in 3D world when you want render targets it usually means you want to do some advanced shading, and it sounds like that is what you are going to do eventually. Are you doing dynamic light mapping (similar to shadow mapping but reverse)?
SDL 1.3 Roadmap
Sam Lantinga


Joined: 10 Sep 2009
Posts: 1765
Sure. If people are interested in contributing in this area, I'm more
than happy to coordinate it!

On Tue, Feb 2, 2010 at 3:39 PM, Vittorio G. wrote:
Quote:
hi Sam,
good job for setting up the roadmap.
One addition i would make is to expand the iphone and iphone-like devices
support

There could be a section which includes
- support for landscape mode
- support for opengl es 2.0 contex
- support for ipad
- important aspects missing (like audio in)

ipad support *should* be trivial as it's the same os with a bigger
resolution...
the rest, expecially landscape mode (implemented in a proper way, with
autorotation and or user setup) seem more complex

Cheers
Vittorio

Samuel Goldwyn  - "I don't think anyone should write their autobiography
until after they're dead."

On Mon, Feb 1, 2010 at 8:21 AM, Sam Lantinga wrote:
Quote:

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!

See ya!
--
       -Sam Lantinga, Founder and President, Galaxy Gameworks LLC
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org





--
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL 1.3 Roadmap
Sam Lantinga


Joined: 10 Sep 2009
Posts: 1765
I looked back over the discussion about this, and I agree. I did have
render to texture implemented at one point, but I removed it due to
the complexity and changing FBO standards, and I can't find it now.

I hereby reopen the discussion! Smile

On Tue, Feb 2, 2010 at 5:35 PM, Mason Wheeler wrote:
Quote:
I just looked it over, and I was very disappointed not to see anything
about render targets.  This is critical functionality that's absolutely
needed for SDL 1.3.



Quote:
----- Original Message ----
From: Sam Lantinga
Subject: [SDL] SDL 1.3 Roadmap

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!
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org




--
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL 1.3 Roadmap
Forest Hale
Guest

FBO is lots of fun when it works, just difficult to get it to cooperate on all drivers Smile

I currently it use it for optional features in my darkplaces engine, but the idea of relying upon it scares me until someone makes a thorough map of what formats work with what cards and how fast...
That said, it would be GREAT if someone did make such a table of compatibility Smile

On 02/02/2010 07:51 PM, Sam Lantinga wrote:
Quote:
I looked back over the discussion about this, and I agree. I did have
render to texture implemented at one point, but I removed it due to
the complexity and changing FBO standards, and I can't find it now.

I hereby reopen the discussion! Smile

On Tue, Feb 2, 2010 at 5:35 PM, Mason Wheeler wrote:
Quote:
I just looked it over, and I was very disappointed not to see anything
about render targets. This is critical functionality that's absolutely
needed for SDL 1.3.



Quote:
----- Original Message ----
From: Sam Lantinga
Subject: [SDL] SDL 1.3 Roadmap

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!
_______________________________________________
SDL mailing list

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

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL 1.3 Roadmap
René Dudfield
Guest

On Wed, Feb 3, 2010 at 11:55 AM, Forest Hale wrote:
Quote:
FBO is lots of fun when it works, just difficult to get it to cooperate on all drivers Smile

I currently it use it for optional features in my darkplaces engine, but the idea of relying upon it scares me until someone makes a thorough map of what formats work with what cards and how fast...
That said, it would be GREAT if someone did make such a table of compatibility Smile



AWESOME!

I was just going to email about the render targets and read that
people had already asked for them... Definitely +1 for being able to
blit from texture to texture... or I guess render target is the better
term. Basically being more like current surfaces. So it doesn't
matter too much if it's a texture or a memory surface. I think it
should be possible to get fairly cross platform fast behaviour, but
maybe not for all platforms. Would probably take a number of
extensions, and work arounds to work reliably of course.


cu,
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
nfries88


Joined: 24 Oct 2009
Posts: 100
ArrogantProgrammer wrote:
nfries88 wrote:
ArrogantProgrammer wrote:
If you want a 3D engine use irrlicht or ogre3d. I can't see how SDL will ever be able to compete in that realm and there is no point in doing so. Where it can compete is in offering a basic setup that is cross platform.

INPUT, video setup, windowing, things like this. The other 3D engines have been working exclusively on 3D for years, to come into the game now would take years to hit feature parity.


I have a 2d project that would benefit from this. Blitting to texture is easily accomplished in directdraw and opengl, and I'm sure it's simple enough in direct3d as well.
It's a tile-based game with a resizable game area (based on dimensions of the window its in), so rather than scale each individual sprite's texture it'd be way better to blit to a single texture at normal size and scale the finished product.

This will also make it easier to implement light mapping, which is on our roadmap, since we won't need to worry about scaling that.


Ok I see, you basically just want a simple way to specify the target of a blit/other operation, ie screen or another surface? This wouldn't take very long to add at all and I guess it should be in there. Though there are some restrictions in 3D world, like size of textures that make it rather tricky.

Usually in 3D world when you want render targets it usually means you want to do some advanced shading, and it sounds like that is what you are going to do eventually. Are you doing dynamic light mapping (similar to shadow mapping but reverse)?

It'll be nothing too advanced, as it's a 2d tile-based game (we don't even use a heightmap, but we do have objects that are supposed to create light and our caves and stuff are supposed to be dark and the player shouldn't be able to see anything outside his light radius). It's just easier to scale everything at once than everything individually (it'll probably make for a smoother overall appearance too) and the light/shadow mapping code will be simplified by not accounting for scaling. This is why I want rendering targets.

@Sam: I also suggest an "int (*CanRenderToTexture)(SDL_Renderer * renderer)" function for renderers that wouldn't be able to support the action (IE, OpenGL drivers without FBO extension).
Also, the FBO appears to be a core feature in OpenGL 3.0. See section 2.1 of the 3.0 specification.
SDL 1.3 Roadmap
Bob


Joined: 19 Sep 2009
Posts: 185
On Tue, Feb 2, 2010 at 9:51 PM, Sam Lantinga wrote:
Quote:
I looked back over the discussion about this, and I agree.  I did have
render to texture implemented at one point, but I removed it due to
the complexity and changing FBO standards, and I can't find it now.

I hereby reopen the discussion! Smile

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.

The good news is that cards and drivers with that level of support are
available and pretty cheap. The bad news is that there are still a lot
of older cards and machines out there. Even more bad news I just
bought a nvidia 240 card on my Ubuntu 9.10 machine and I had to get
the 195.30 drivers from ppa to get full support for it. The current
Ubuntu 9.10 drivers are still sitting at 185.18. BTW, they worked with
the new card, but misidentified it and did not give really great
performance. Going back to good news, that tells me that we are at a
just the right point in time to be adding support for these features
in SDL.

Bob Pendleton

Quote:

On Tue, Feb 2, 2010 at 5:35 PM, Mason Wheeler wrote:
Quote:
I just looked it over, and I was very disappointed not to see anything
about render targets.  This is critical functionality that's absolutely
needed for SDL 1.3.



Quote:
----- Original Message ----
From: Sam Lantinga
Subject: [SDL] SDL 1.3 Roadmap

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!
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org




--
       -Sam Lantinga, Founder and President, Galaxy Gameworks LLC
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org




--
+-----------------------------------------------------------
+ Bob Pendleton: writer and programmer
+ email:
+ web: www.TheGrumpyProgrammer.com
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL 1.3 Roadmap
Gaetan de Menten
Guest

On Mon, Feb 1, 2010 at 08:21, Sam Lantinga wrote:
Quote:
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

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL 1.3 Roadmap
Mason Wheeler
Guest

Quote:
----- Original Message ----

Quote:
From: Bob Pendleton
Subject: Re: [SDL] SDL 1.3 Roadmap

On Tue, Feb 2, 2010 at 9:51 PM, Sam Lantinga wrote:
Quote:
I looked back over the discussion about this, and I agree. I did have
render to texture implemented at one point, but I removed it due to
the complexity and changing FBO standards, and I can't find it now.

I hereby reopen the discussion! Smile

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?

Not sure what "we" are talking about, but I'm talking about adding it to
the SDL 2D graphics API.

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

OK, you lost me. I'm no OGL expert, not by a long shot, but I know I
read stuff about FBOs and APIs to use them before OGL 3 was
released, much less 3.1.

Plus, render target support would probably have to include at least
Direct3D as well, and probably the other renderers.

One thing I wonder about. If I understand correctly, SDL 1.3 Textures
are supposed to be about the same thing as SDL 1.2 Hardware
Surfaces. In 1.2, you could blit from one hardware surface to another.
How was that done, and why can't we do the same thing now?

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
hardcoder


Joined: 06 Jan 2010
Posts: 84
Location: Poznan, Poland
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.

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 1.3 Roadmap
Mason Wheeler
Guest

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?
Re: SDL 1.3 Roadmap
nfries88


Joined: 24 Oct 2009
Posts: 100
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:
hardcoder wrote:
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.

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 1.3 Roadmap
Jonny D


Joined: 12 Sep 2009
Posts: 932
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 D



On Wed, Feb 3, 2010 at 8:30 PM, nfries88 wrote:
Quote:



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.

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

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[/quote]
SDL 1.3 Roadmap
Vittorio G.
Guest

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  - "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:
Quote:
On Mon, Feb 1, 2010 at 08:21, Sam Lantinga wrote:
Quote:
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

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL 1.3 Roadmap
Ryan C. Gordon
Guest

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

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Re: SDL 1.3 Roadmap
nfries88


Joined: 24 Oct 2009
Posts: 100
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.
Re: SDL 1.3 Roadmap
ArrogantProgrammer


Joined: 03 Feb 2010
Posts: 8
Ryan C. Gordon wrote:
Quote:
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.


Well I don't want to tell you guys what to do, but to me it would seem if mouse input is broken then fewer people will want to use SDL 1.3 . In fact it seems with the bugs I uncovered (see other thread) that no one has really used it in anything resembling a complicated program. The thing is I only use input/windowing from SDL and it's broken badly, I don't want to think about the other sections. Like how did that bug creep into SDL_Memset() that made it not clear all memory? Why are the cursors so badly done? I don't think anyone wants SDL to manage cursors for them so I'm not sure where this is coming from, it is easy to add your own cursors if you need them already and SDL will never be able to match the needs of everyone. Basically SDL should just let the OS cursor in the application unless user disables that and from there it's up to them to have their own cursor. It seems there are many such "improvements" pending to SDL 1.3 that I think very few will use, so why is time wasted on it? SDL I thought was about being a nice layer from the OS to be cross platform compatible. The more features added on top of that just seem silly, SDL 1.3 needs a bit more direction from the spirit of the original.

It's a 1 hour job at most to separate the cursor/raw mouse input into separate events. In regards to mouse cursor just let the OS pass that on, if a mouse isn't attached to the cursor movement then that is an issue for the application programmer/OS not SDL. There should be no "mouse" attached to cursor events in other words. A cursor event is just that, the cursor moving, which may not be tied to any one device. Windows allows multiple mouse/devices to move the cursor so it isn't an issue on windows, surely linux/whatever has something similar.

Basically you only *WANT* raw mouse input when using it for high definition movement (3D movement) or you want to do your own cursor routines for separate input devices. It is absolutely the biggest killer in a game when the ingame mouse cursor does not match the system speed and it really shouldn't be in SDL when it is an easy fix. It also means you cannot have your own cursor in a windowed program without mouse grabbing as the OS speed won't match SDL speed, basically you'll move your cursor across your app and the OS cursor will leave your window before the in program one does. This is I assume why the existing "hack" is in there which reverts back to SDL 1.2 mouse grabbing and the comment "why are we even using rawinput".

Can anyone commit to the SVN? Because all this wasted time talking about the issue I would have already fixed it.
SDL 1.3 Roadmap
Marcel Wysocki
Guest

On 02/01/2010 08:21 AM, Sam Lantinga wrote:
Quote:
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

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL 1.3 Roadmap
Mars_999
Guest

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:
Quote:
On 02/01/2010 08:21 AM, Sam Lantinga wrote:
Quote:
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

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
michelleC


Joined: 08 Feb 2010
Posts: 108
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 1.3 Roadmap
Jonny D


Joined: 12 Sep 2009
Posts: 932
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 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 D


On Mon, Feb 8, 2010 at 9:07 AM, michelleC wrote:
Quote:
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

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Re: SDL 1.3 Roadmap
michelleC


Joined: 08 Feb 2010
Posts: 108
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 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 wrote:
Quote:
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

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

michelleC


Joined: 08 Feb 2010
Posts: 108
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.
nfries88


Joined: 24 Oct 2009
Posts: 100
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)
SDL 1.3 Roadmap
Jonny D


Joined: 12 Sep 2009
Posts: 932
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 wrote:
Quote:
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

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Re: SDL 1.3 Roadmap
michelleC


Joined: 08 Feb 2010
Posts: 108
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 wrote:
Quote:
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

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Re: SDL 1.3 Roadmap
nfries88


Joined: 24 Oct 2009
Posts: 100
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.
Re: SDL 1.3 Roadmap
michelleC


Joined: 08 Feb 2010
Posts: 108
[

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
Re: SDL 1.3 Roadmap
michelleC


Joined: 08 Feb 2010
Posts: 108
[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.
Re: SDL 1.3 Roadmap
nfries88


Joined: 24 Oct 2009
Posts: 100
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.
Re: SDL 1.3 Roadmap
michelleC


Joined: 08 Feb 2010
Posts: 108
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.
SDL 1.3 Roadmap
Sam Lantinga


Joined: 10 Sep 2009
Posts: 1765
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:
Quote:
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

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org





--
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Re: SDL 1.3 Roadmap
nfries88


Joined: 24 Oct 2009
Posts: 100
Sam Lantinga wrote:
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:
Quote:
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?
SDL 1.3 Roadmap
Mason Wheeler
Guest

I like it! It might be a little bit tricky to implement, but that's a very convenient API.


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

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?
nfries88


Joined: 24 Oct 2009
Posts: 100
Ah! I forgot the one for buffer->buffer/window.
int SDL_RenderCopyBuffer(SDL_RenderBuffer* buffer, const SDL_Rect* srcrect, const SDL_Rect* destrect);
perhaps scaling and blendmodes on RenderBuffers, too?
int SDL_SetRenderBufferScaleMode(SDL_RenderBuffer* buffer, int scalemode);
int SDL_GetRenderBufferScaleMode(SDL_RenderBuffer* buffer, int* scalemode);
int SDL_SetRenderBufferBlendMode(SDL_RenderBuffer* buffer, int blendmode);
int SDL_GetRenderBufferBlendMode(SDL_RenderBuffer* buffer, int* blendmode);

Really, though, anything else we could do for renderbuffers would just be the same as for a texture.
michelleC


Joined: 08 Feb 2010
Posts: 108
nfries88 wrote:
Ah! I forgot the one for buffer->buffer/window.
int SDL_RenderCopyBuffer(SDL_RenderBuffer* buffer, const SDL_Rect* srcrect, const SDL_Rect* destrect);
perhaps scaling and blendmodes on RenderBuffers, too?
int SDL_SetRenderBufferScaleMode(SDL_RenderBuffer* buffer, int scalemode);
int SDL_GetRenderBufferScaleMode(SDL_RenderBuffer* buffer, int* scalemode);
int SDL_SetRenderBufferBlendMode(SDL_RenderBuffer* buffer, int blendmode);
int SDL_GetRenderBufferBlendMode(SDL_RenderBuffer* buffer, int* blendmode);

Really, though, anything else we could do for renderbuffers would just be the same as for a texture.



Good idea,

Took me some time to understand what you are doing but for a cross platform solution I bet it will work.

BUT

I came up with an iphone specfic solution, Not sure if there is a way to make it generic.

The iphone actually DOES let you create multiple windows, there are a few apps I know of in the app store that take advantage of this fact but not sdl, there are one or two apps that would like to get appstore approval that use this fact to display tv out, ie. display an image on the screen with overlays and everything but another to the tv out cable. Alas, they use undocumented api's so the authors just have to sit an wait.

But the the fact that the iphone can have several uiwindows but can only have one window as keywindow is an advantage.

You can create the sdl window and the coaca window, complete with tabbars , navigation anything you want . You have to do some notifications and set some keys to try to make it generic but basically each window just takes turns becoming the key window.

There is a game api that uses a similar method,UNITY what it does it when it launches it shows the users a menu system, after the user does the initial setup and is ready to play the game the menu relinquishes control to Unity . When the player is within the unity system and decides to return to the menu system clicking a button sends a notification and sets a key . The notification is handled and the menu frontend once again becomes the key window.

My solution is quite similar to this, but SDL is not quite the black box Unity is, so I have more control over when to swap windows.