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
“Sam: Reimplement mouse grab support”
Would this make mouse warping work?------------------------
www.amyto.com
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
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 Goldwynhttp://www.brainyquote.com/quotes/authors/s/samuel_goldwyn.html
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/RoadmapI’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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
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.>----- Original Message ----
From: Sam Lantinga
Subject: [SDL] SDL 1.3 RoadmapI 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/RoadmapI’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!
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 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.
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. <vitto.giova at yahoo.it> wrote:
hi Sam,
good job for setting up the roadmap.
One addition i would make is to expand the iphone and iphone-like devices
supportThere 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 complexCheers
VittorioSamuel 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 <@slouken> 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/RoadmapI’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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
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! :)On Tue, Feb 2, 2010 at 5:35 PM, 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.----- Original Message ----
From: Sam Lantinga <@slouken>
Subject: [SDL] SDL 1.3 RoadmapI 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/RoadmapI’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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
FBO is lots of fun when it works, just difficult to get it to cooperate on all drivers 
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 :)On 02/02/2010 07:51 PM, Sam Lantinga wrote:
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!
On Tue, Feb 2, 2010 at 5:35 PM, 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.----- Original Message ----
From: Sam Lantinga
Subject: [SDL] SDL 1.3 RoadmapI 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/RoadmapI’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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier
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,On Wed, Feb 3, 2010 at 11:55 AM, Forest Hale wrote:
FBO is lots of fun when it works, just difficult to get it to cooperate on all drivers
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
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.
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!
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 PendletonOn Tue, Feb 2, 2010 at 9:51 PM, Sam Lantinga wrote:
On Tue, Feb 2, 2010 at 5:35 PM, 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.----- Original Message ----
From: Sam Lantinga
Subject: [SDL] SDL 1.3 RoadmapI 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/RoadmapI’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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org–
? ? ? ?-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
±----------------------------------------------------------
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.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/RoadmapI’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!
–
Ga?tan de Menten
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!
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.
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?>----- Original Message ----
From: Bob Pendleton
Subject: Re: [SDL] SDL 1.3 Roadmap
On Tue, Feb 2, 2010 at 9:51 PM, Sam Lantinga 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 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?
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: simono@o2.pl (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?
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.
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.
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)?
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:
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).