Hi libsdl
I’ve set up opengl using sdl [not sure if that made much sense, what I
mean is I passed SDL_OPENGL to SDL_Init () as detailed in the man
pages). I’m also using double buffering, but I can live without that
really.
Now, I know i can Load a BMP [and save it] without actually creating a
window [without calling SDL_VideoMode () ), and I know that I can call
my opengl drawing functions as well without receiving any errors…
But where exactly are they drawn? Can I draw straight to a surface? I
don’t want to draw to the display surface, and I don’t want to
actually create a display surface [yet], but I do want to manipulate
the pixels I’d get after calling the opengl drawing functions… Is
there a surface used as the back buffer or something that I can access
directly? I mentioned the bmp loading because I couldn’t successfully
initialize a surface [without set_video_mode () ] unless I somehow
Created it from another surface [the bmp], so I was wondering if it
was possible to get the opengl code to draw to said surface [assuming
I’m not just using glDrawPixels () ofcourse] ?
Thanks for your help
elie
Elie Choueiri wrote:
Hi libsdl
I’ve set up opengl using sdl [not sure if that made much sense, what I
mean is I passed SDL_OPENGL to SDL_Init () as detailed in the man
pages). I’m also using double buffering, but I can live without that
really.
Now, I know i can Load a BMP [and save it] without actually creating a
window [without calling SDL_VideoMode () ), and I know that I can call
my opengl drawing functions as well without receiving any errors…
But where exactly are they drawn?
If you have no windows created, they aren’t drawn, the OpenGL calls just
return.
Can I draw straight to a surface?
No.
I
don’t want to draw to the display surface, and I don’t want to
actually create a display surface [yet], but I do want to manipulate
the pixels I’d get after calling the opengl drawing functions… Is
there a surface used as the back buffer or something that I can access
directly?
You need a pbuffer, which SDL doesn’t support. I’m a big user of
pbuffers, and I must say SDL is missing a feature here.
However, in the 1.3 branch SDL emulates a render-to-texture like
extension that will render into a texture directly (using pbuffers), but
that’s only useful if you want render to texture functionality.
I mentioned the bmp loading because I couldn’t successfully
initialize a surface [without set_video_mode () ] unless I somehow
Created it from another surface [the bmp], so I was wondering if it
was possible to get the opengl code to draw to said surface [assuming
I’m not just using glDrawPixels () ofcourse] ?
Basically :
- allocate a pbuffer using the suitable platform-dependent (glX, WGL or
whatever) extension
- draw your stuff
- glReadPixels() of the frame buffer (I recommend a driver accelerating
this call here - notably not any old ati driver)
Stephane
Thanks Stephane.
I will look into pbuffers today. Hope there’s an easy tutorial lying
around someplace :-)On Tue, 14 Dec 2004 00:59:33 +0100, Stephane Marchesin <stephane.marchesin at wanadoo.fr> wrote:
Elie Choueiri wrote:
Hi libsdl
I’ve set up opengl using sdl [not sure if that made much sense, what I
mean is I passed SDL_OPENGL to SDL_Init () as detailed in the man
pages). I’m also using double buffering, but I can live without that
really.
Now, I know i can Load a BMP [and save it] without actually creating a
window [without calling SDL_VideoMode () ), and I know that I can call
my opengl drawing functions as well without receiving any errors…
But where exactly are they drawn?
If you have no windows created, they aren’t drawn, the OpenGL calls just
return.
Can I draw straight to a surface?
No.
I
don’t want to draw to the display surface, and I don’t want to
actually create a display surface [yet], but I do want to manipulate
the pixels I’d get after calling the opengl drawing functions… Is
there a surface used as the back buffer or something that I can access
directly?
You need a pbuffer, which SDL doesn’t support. I’m a big user of
pbuffers, and I must say SDL is missing a feature here.
However, in the 1.3 branch SDL emulates a render-to-texture like
extension that will render into a texture directly (using pbuffers), but
that’s only useful if you want render to texture functionality.
I mentioned the bmp loading because I couldn’t successfully
initialize a surface [without set_video_mode () ] unless I somehow
Created it from another surface [the bmp], so I was wondering if it
was possible to get the opengl code to draw to said surface [assuming
I’m not just using glDrawPixels () ofcourse] ?
Basically :
- allocate a pbuffer using the suitable platform-dependent (glX, WGL or
whatever) extension
- draw your stuff
- glReadPixels() of the frame buffer (I recommend a driver accelerating
this call here - notably not any old ati driver)
Stephane
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Hi Stephane
Sorry to trouble you, but I’m finding it difficult to get into
pbuffers as I’m not too familiar with the idea of rendering contexts
and whatnot, having used glut for most of the work… have you got any
links to get me started with glx/pbuffers/offscreen rendering?
Thanks,
elieOn Tue, 14 Dec 2004 12:10:34 +0200, Elie Choueiri <@Elie_Choueiri> wrote:
Thanks Stephane.
I will look into pbuffers today. Hope there’s an easy tutorial lying
around someplace 
On Tue, 14 Dec 2004 00:59:33 +0100, Stephane Marchesin <stephane.marchesin at wanadoo.fr> wrote:
Elie Choueiri wrote:
Hi libsdl
I’ve set up opengl using sdl [not sure if that made much sense, what I
mean is I passed SDL_OPENGL to SDL_Init () as detailed in the man
pages). I’m also using double buffering, but I can live without that
really.
Now, I know i can Load a BMP [and save it] without actually creating a
window [without calling SDL_VideoMode () ), and I know that I can call
my opengl drawing functions as well without receiving any errors…
But where exactly are they drawn?
If you have no windows created, they aren’t drawn, the OpenGL calls just
return.
Can I draw straight to a surface?
No.
I
don’t want to draw to the display surface, and I don’t want to
actually create a display surface [yet], but I do want to manipulate
the pixels I’d get after calling the opengl drawing functions… Is
there a surface used as the back buffer or something that I can access
directly?
You need a pbuffer, which SDL doesn’t support. I’m a big user of
pbuffers, and I must say SDL is missing a feature here.
However, in the 1.3 branch SDL emulates a render-to-texture like
extension that will render into a texture directly (using pbuffers), but
that’s only useful if you want render to texture functionality.
I mentioned the bmp loading because I couldn’t successfully
initialize a surface [without set_video_mode () ] unless I somehow
Created it from another surface [the bmp], so I was wondering if it
was possible to get the opengl code to draw to said surface [assuming
I’m not just using glDrawPixels () ofcourse] ?
Basically :
- allocate a pbuffer using the suitable platform-dependent (glX, WGL or
whatever) extension
- draw your stuff
- glReadPixels() of the frame buffer (I recommend a driver accelerating
this call here - notably not any old ati driver)
Stephane
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Le Wed, 15 Dec 2004 00:17:47 +0200
Elie Choueiri <elie.choueiri at gmail.com> a ?crit:
Sorry to trouble you, but I’m finding it difficult to get into
pbuffers as I’m not too familiar with the idea of rendering contexts
and whatnot, having used glut for most of the work… have you got any
links to get me started with glx/pbuffers/offscreen rendering?
For offscreen rendering, have a look to OSMesa (Mesa’s offscreen rendering
driver, purely software rendering). It is very simple to support (I did it
for the Atari port).
However, if I can create multiple OSMesa contexts in an SDL application
(by directly calling OSMesa functions), I can’t create multiple hardware
accelerated contexts, because there is no function to so do in SDL (glx
pbuffers as Stephane said).
It would be useful for emulators (like qemu maybe ?), because it would be
easy to support OpenGL hardware rendering this way. Here is a screenshot
of an Atari emulator (that uses SDL), where there is several OpenGL
software contexts created (rendering done by host CPU directly, without
code emulation). I would like to be able to do the same using hardware
accelerated rendering. For the moment, only one fullscreen OpenGL would be
possible (using the OpenGL context created by host’s SDL).
Screenshot page:
http://aranym.sourceforge.net/screenshots.html--
Patrice Mandin
WWW: http://membres.lycos.fr/pmandin/
Programmeur Linux, Atari
Sp?cialit?: D?veloppement, jeux