In 1.3, you can use SDL_BlitSurface to blit from one surface to another, SDL_RenderCopy to blit from a texture to the selected window, or SDL_CreateTextureFromSurface to copy (not quite a blit apparently) from a surface to a texture. But how do you blit from one texture to another?
Unless something has changed recently, such functionality doesn’t exist
in SDL 1.3.
It would certainly require SDL to use framebuffer or pbuffers in the
OpenGL renderers. This would probably be a nice feature (think blitting
on an order of magnitude faster) though not all GPUs that support OpenGL
could support this feature.
- Holmes
Mason Wheeler wrote:> In 1.3, you can use SDL_BlitSurface to blit from one surface to another, SDL_RenderCopy to blit from a texture to the selected window, or SDL_CreateTextureFromSurface to copy (not quite a blit apparently) from a surface to a texture. But how do you blit from one texture to another?
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Hi Holmes-
It could certainly be emulated in software where framebuffer or
pbuffer functionality is unavailable. Given that it’s possible to
check OpenGL extensions at runtime, there’s nothing stopping this
going in 
AlastairOn 5 Apr 2009, at 20:32, Holmes Futrell wrote:
Unless something has changed recently, such functionality doesn’t
exist in SDL 1.3.
It would certainly require SDL to use framebuffer or pbuffers in the
OpenGL renderers. This would probably be a nice feature (think
blitting on an order of magnitude faster) though not all GPUs that
support OpenGL could support this feature.
- Holmes
Mason Wheeler wrote:
In 1.3, you can use SDL_BlitSurface to blit from one surface to
another, SDL_RenderCopy to blit from a texture to the selected
window, or SDL_CreateTextureFromSurface to copy (not quite a blit
apparently) from a surface to a texture. But how do you blit from
one texture to another?
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
-------------- next part --------------
A non-text attachment was scrubbed…
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3912 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20090405/bc3e34d7/attachment.bin
In the absence of PBO and FBO functionality, you fall back to
glCopyTexImage2D(). It’s usually not very fast, but it’s better than
nothing.On Sun, Apr 5, 2009 at 3:32 PM, Holmes Futrell wrote:
It would certainly require SDL to use framebuffer or pbuffers in the OpenGL
renderers. ?This would probably be a nice feature (think blitting on an
order of magnitude faster) though not all GPUs that support OpenGL could
support this feature.
Oh yeah, that’s true, you could.
It could indeed be horribly slow though, especially in bandwidth limited
systems.
- Holmes
Donny Viszneki wrote:> On Sun, Apr 5, 2009 at 3:32 PM, Holmes Futrell <@Holmes_Futrell> wrote:
It would certainly require SDL to use framebuffer or pbuffers in the OpenGL
renderers. This would probably be a nice feature (think blitting on an
order of magnitude faster) though not all GPUs that support OpenGL could
support this feature.In the absence of PBO and FBO functionality, you fall back to
glCopyTexImage2D(). It’s usually not very fast, but it’s better than
nothing.
Hiyya all, I guess I got lost somewhere along the way. If sdl uses openGL how is it easier unless we leave out the ability to use all of openGL? I mean openGL is as easy as it can be and still be so powerfull. Is the sdl use of it intended to be less powerfull because it has less control? Where do users draw the line and decide to just translate all of the sdl functions back into the original openGL and simply use sdl to open the window and stuff like that? That’s what I do now as the books have that use sdl and openGL.
I’m at a loss because the questions I am seeing about the sdl use of openGL are already answered if you were to simply use the openGL as it is. The functions are all tried and true with the help of many more people than the sdl following.
Doing sdl with openGL is a choice that a bunch of public books do and other people have made more publicly available libs online too like this sdl and openGL lib.
…so confused…_______________________
---- Holmes Futrell wrote:
=============
Unless something has changed recently, such functionality doesn’t exist
in SDL 1.3.
It would certainly require SDL to use framebuffer or pbuffers in the
OpenGL renderers. This would probably be a nice feature (think blitting
on an order of magnitude faster) though not all GPUs that support OpenGL
could support this feature.
- Holmes
Mason Wheeler wrote:
In 1.3, you can use SDL_BlitSurface to blit from one surface to another, SDL_RenderCopy to blit from a texture to the selected window, or SDL_CreateTextureFromSurface to copy (not quite a blit apparently) from a surface to a texture. But how do you blit from one texture to another?
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
OpenGL is just one of several available methods available for rendering
with SDL, depending on what platform you’re using. SDL is not a wrapper
around OpenGL, it just happens to use OpenGL for rendering on many
platforms because that’s the quickest, most cross-platform rendering
method available.
I actually do think SDL succeeds in being more simple than OpenGL when
doing basic tasks. Whereas most people would think of doing 2D graphics
as loading images and drawing them in various positions, OpenGL adds
complications … setting up proper projection matrices, creating
textures, setting proper state, and defining what you want to draw in
terms of primitives and vertices.
Where to draw the line? If you need 3D or 2D with rotation and scaling,
you should probably go with pure OpenGL instead of using any SDL drawing
(just use SDL to set up the window). But even if you’re doing 3D or
advanced 2D, you may still find SDL (along with SDL_Image) very useful
for loading your OpenGL textures.
- Holmes
necronology at cox.net wrote:> Hiyya all, I guess I got lost somewhere along the way. If sdl uses openGL how is it easier unless we leave out the ability to use all of openGL? I mean openGL is as easy as it can be and still be so powerfull. Is the sdl use of it intended to be less powerfull because it has less control? Where do users draw the line and decide to just translate all of the sdl functions back into the original openGL and simply use sdl to open the window and stuff like that? That’s what I do now as the books have that use sdl and openGL.
I’m at a loss because the questions I am seeing about the sdl use of openGL are already answered if you were to simply use the openGL as it is. The functions are all tried and true with the help of many more people than the sdl following.
Doing sdl with openGL is a choice that a bunch of public books do and other people have made more publicly available libs online too like this sdl and openGL lib.
http://g3d-cpp.sourceforge.net/index.html
…so confused…
---- Holmes Futrell <@Holmes_Futrell> wrote:
=============
Unless something has changed recently, such functionality doesn’t exist
in SDL 1.3.It would certainly require SDL to use framebuffer or pbuffers in the
OpenGL renderers. This would probably be a nice feature (think blitting
on an order of magnitude faster) though not all GPUs that support OpenGL
could support this feature.
- Holmes
Mason Wheeler wrote:
In 1.3, you can use SDL_BlitSurface to blit from one surface to another, SDL_RenderCopy to blit from a texture to the selected window, or SDL_CreateTextureFromSurface to copy (not quite a blit apparently) from a surface to a texture. But how do you blit from one texture to another?
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
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
REspectfuly no.
---- Holmes Futrell wrote:=============
OpenGL is just one of several available methods available for rendering
with SDL, depending on what platform you’re using.
–>platform dependant? openGL is not platform dependant for example.
SDL is not a wrapper around OpenGL, it just happens to use OpenGL for rendering on many platforms because that’s the quickest, most cross-platform rendering method available. I actually do think SDL succeeds in being more simple than OpenGL when doing basic tasks.
–>So it has functions that call on the more complicated openGL functions…sounds like a wrap.
Whereas most people would think of doing 2D graphics as loading images and drawing them in various positions, OpenGL adds
complications … setting up proper projection matrices, creating textures, setting proper state, and defining what you want to draw in terms of primitives and vertices.
–> That sir is what openGL does in such a simple way that people new to code can pick up and there are tons of tutorials and lots of people in an honest to god chat board with lots of posts on tons of openGL topics.
Where to draw the line? If you need 3D or 2D with rotation and scaling,
you should probably go with pure OpenGL instead of using any SDL drawing (just use SDL to set up the window). But even if you’re doing 3D or advanced 2D, you may still find SDL (along with SDL_Image) very useful for loading your OpenGL textures.
–> So sdl plans no functions for rotation or scale? Rotate and scale are silly being that openGL does that in real time in 2 or 3d as simple as to move the poximity of vertices or rotate them on an axis…this I learned in openGL books …but I digress…
I respect your perspective but from where I sit this new version makes sdl just another “openGL toolkit” with nothing to offer. Sam used to say we needed things like OpenGL seperate. I still believe sdl needs it’s own graphics that are simply an additional lib like sdl_image. I like directX sometimes and G3D like use others. This all seems so wrong. I guess I have promoted sdl long enough to have feelings for it and I’m old enough to have seen this kind of thing play out too many times. I can see a multitude of the innocent and a few violently faithful to anything Sam says. I Q nearly twice average tells me I need to let sdl go. You won’t hear from me again. Goodbye
- Holmes
@necron wrote:
Hiyya all, I guess I got lost somewhere along the way. If sdl uses openGL how is it easier unless we leave out the ability to use all of openGL? I mean openGL is as easy as it can be and still be so powerfull. Is the sdl use of it intended to be less powerfull because it has less control? Where do users draw the line and decide to just translate all of the sdl functions back into the original openGL and simply use sdl to open the window and stuff like that? That’s what I do now as the books have that use sdl and openGL.
I’m at a loss because the questions I am seeing about the sdl use of openGL are already answered if you were to simply use the openGL as it is. The functions are all tried and true with the help of many more people than the sdl following.
Doing sdl with openGL is a choice that a bunch of public books do and other people have made more publicly available libs online too like this sdl and openGL lib.
http://g3d-cpp.sourceforge.net/index.html
…so confused…
---- Holmes Futrell wrote:
=============
Unless something has changed recently, such functionality doesn’t exist
in SDL 1.3.It would certainly require SDL to use framebuffer or pbuffers in the
OpenGL renderers. This would probably be a nice feature (think blitting
on an order of magnitude faster) though not all GPUs that support OpenGL
could support this feature.
- Holmes
Mason Wheeler wrote:
In 1.3, you can use SDL_BlitSurface to blit from one surface to another, SDL_RenderCopy to blit from a texture to the selected window, or SDL_CreateTextureFromSurface to copy (not quite a blit apparently) from a surface to a texture. But how do you blit from one texture to another?
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
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
Holmes Futrell wrote:
OpenGL is just one of several available methods available for rendering
with SDL, depending on what platform you’re using.platform dependant? openGL is not platform dependant for example.
The set of available SDL back-end subsystems is dependent on your platform.
SDL is not a wrapper around OpenGL, it just happens to use OpenGL for
rendering on many platforms because that’s the quickest, most
cross-platform rendering method available. I actually do think SDL
succeeds in being more simple than OpenGL when doing basic tasks.
I don’t actually believe it’s accurate to say that OpenGL is the
default back-end on most systems, maybe someone else who knows could
chime in.
So it has functions that call on the more complicated openGL
functions…sounds like a wrap.
SDL provides its own programming abstractions which are geared toward
quite different tasks than the OpenGL API is. A “wrapper” in hacker
jargon is “thinner” than this, and would not constitute any kind of
change in the programming abstraction.
http://www.swig.org/
http://sdlmm.sourceforge.net/
So sdl plans no functions for rotation or scale? Rotate and scale are
silly being that openGL does that in real time in 2 or 3d as simple as
to move the poximity of vertices or rotate them on an axis…this I
learned in openGL books …but I digress…I respect your perspective but from where I sit this new version makes
sdl just another “openGL toolkit” with nothing to offer.
What you fail to understand is that OpenGL is not nor has it ever been
centric to SDL. SDL is platform-independent, and that means offering a
variety of back-end implementations for all the functionality it
offers. As you are probably aware, the primary advantage of this is
that you can write your programs to the same abstractions and APIs and
your program will run under a wide variety of situations.
Like many programming abstractions designed to keep you away from
writing platform-specific code, SDL does not merely offer “MSWindows,”
“Linux,” “Mac OS,” “Mac OS X,” etc. etc. back-ends. Because many of
those systems do not adequately describe what resources are available
– or preferable – for your application (is the DirectDraw driver
buggy? is OpenGL slower than traditional 2D APIs with your video
drivers? if my SDL app asks the system for an OpenGL context for
doing my 2D graphics, am I going to get an expensive all-software
implementation like MESA which would be slower than using a different
2D rendering approach? which video APIs are compatible with
DirectInput instead of WM_MOUSE? do we run in X or in kernel
framebuffer? etc.) SDL offers a variety of back-ends for many
different sub-components of SDL’s functionality which are not
specifically paired up one-for-one with each gross platform.
OpenGL is one back-end implementation for one subsystem (video.)
Just another “OpenGL toolkit” wouldn’t know what to do with itself if
you wanted to run it without OpenGL.
Additionally it’s worth noting that many "just another OpenGL toolkit"
can be used in tandem with SDL if you are using SDL as your OpenGL
context manager. In this case, you have probably chosen SDL because it
provides a cross-platform API for handling many things, OpenGL context
management one of them.
Sam used to say we needed things like OpenGL seperate.
OpenGL is separate. You cannot (probably – you’re certainly not
intended to) use the OpenGL API with SDL when you are using the OpenGL
back-end for the non-OpenGL SDL video subsystem. That is to say: if
you ask SDL for a 2D video window, you aren’t meant to combine that
with the OpenGL API.
I still believe sdl needs it’s own graphics that are simply an
additional lib like sdl_image.
I think that perhaps you don’t really understand the idea of a
programming abstraction.
FWIW there is SDL_gfx. Perhaps, however, SDL_gfx should be updated for
the more modern SDL 1.3 API. Perhaps also, SDL 1.3 should take care to
expose the right APIs for libs like SDL_gfx so that it can make sure
it, too, is fully accelerated under the OpenGL video back-end. (This
agrees with your earlier comment about rotation and scaling.)On Sun, Apr 5, 2009 at 11:59 PM, wrote:
I’m going to miss you… Maybe you’re already gone, but I think you
misunderstood what these guys are talking about.
Many people use SDL’s graphics API instead of OpenGL. It IS easier to
learn! If we make certain SDL functions to use OpenGL instead of slow
software implementations, those people benefit greatly and can be more
creative. Those people are the ones who drive the future of graphics
and gaming (especially indie).
I don’t know why it seems that you’ve taken this personally, but the
SDL 1.3 API only affects you (OpenGL API user) as far as neat features
like multiple displays, a slightly nicer interface, and such.
–>platform dependant? openGL is not platform dependant for example.
He did not say that.
–>So it has functions that call on the more complicated openGL functions…sounds like a wrap.
Can you not use another library without being ‘just a wrap’? “Call
on” does not mean “wrap”.
–> That sir is what openGL does in such a simple way that people new to code can pick up and there are tons of tutorials and lots of people in an honest to god chat board with lots of posts on tons of openGL topics.
Ask someone who is in an intro programming class which is easier and
quicker to learn: OpenGL or SDL
In fact, many people take no classes at all and still want to learn!
Why do some people fake OpenGL with a 3d game library/creator? It’s
about abstraction.
–> So sdl plans no functions for rotation or scale? Rotate and scale are silly being that openGL does that in real time in 2 or 3d as simple as to move the poximity of vertices or rotate them on an axis…this I learned in openGL books …but I digress…
I would expect SDL to have this functionality (though the software
fallback would be up to interpretation), but it doesn’t need to if
there are up-to-date libs like Sprig and SDL_gfx.
Jonny D