Elysian Shadows

Is there any way to take an openGL texture and convert it into an SDL_Surface?

Why would you ever need to do that? Usually one would use SDL's LoadImage() function to create an SDL_Surface then convert it to an OpenGL texture from there if needed. Where is the OpenGL texture coming from?

Instead of converting it why not just make a texture class, convert a SDL_Surface to a OpenGL texture and Keep them both stored until the destructor is called? then you can have a both.

N64vSNES wrote:Instead of converting it why not just make a texture class, convert a SDL_Surface to a OpenGL texture and Keep them both stored until the destructor is called? then you can have a both.

Again I ask, why would you ever need to do that? Unless your application allows you to switch between 2D and 3D mid-execution.. (in which case you probably have more important design flaws to consider).

Sounds more like a waste of memory to me.

@ dandymcgee For pixel Maniplation. It's coming from an already loaded image file.
@ N64vSNES Because that would use more memory because not all of the textures I am going to use will need to have an SDL_Surface. It's okay if you have a little room for overhead but I want my new engine to be perfect.
@ dandymcgee Well in the future it might.

I hope that clears things up a bit.
P.S. What I'm actually after is a pointer to the texture in SDL_Surface format so I don't have to regenerate the texture in OpenGL.

P.P.S. N64 wins because All-stars is crap.

I think having a class which holds the GL texture and the SDL surface is one of your only options, you could have a pointer to the SDL surface in the class so that your not using much extra memory when your not using it. I don't see that you have too many options...

@ MrDeathNote So your saying there is no way to convert it?

RandomDever wrote:@ MrDeathNote So your saying there is no way to convert it?

Not that I know of... but maybe someone else has an idea. Why don't you just do the pixel manipulations before you convert it to a GL texture? Do you need to manipulate the texture many times during execution?

@ MrDeathNote Yeah I was hoping for runtime pixel manipulation but I guess I'll have to do without it at least for a while.
At least you tried.

RandomDever wrote:@ dandymcgee Well in the future it might.

In which case you'd be using OpenGL for both 2D and 3D rendering (it's not possible or desirable to use SDL's software rendering and OpenGL in the same window)

MrDeathNote wrote:I think having a class which holds the GL texture and the SDL surface is one of your only options, you could have a pointer to the SDL surface in the class so that your not using much extra memory when your not using it. I don't see that you have too many options...

Well the pointer isn't the memory issue, it's having all of of those SDL_Surfaces loaded in memory.

RandomDever wrote:@ MrDeathNote Yeah I was hoping for runtime pixel manipulation but I guess I'll have to do without it at least for a while.
At least you tried.

Try this: Project 3: Pixel Manipulation
However, keep in mind that pixel manipulation is an expensive operation.

dandymcgee wrote:

RandomDever wrote:@ dandymcgee Well in the future it might.

In which case you'd be using OpenGL for both 2D and 3D rendering (it's not possible or desirable to use SDL's software rendering and OpenGL in the same window)

Yes it is possible, you can pass SDL_OPENGLBLIT when you initialize the video mode which allows you to use SDL blitting aswell as OpenGL's texture mapping, polygons etc. I admit the flag only exists for backwards compatability and is no longer supported but it is possible.

dandymcgee wrote:

N64vSNES wrote:Instead of converting it why not just make a texture class, convert a SDL_Surface to a OpenGL texture and Keep them both stored until the destructor is called? then you can have a both.

Again I ask, why would you ever need to do that? Unless your application allows you to switch between 2D and 3D mid-execution.. (in which case you probably have more important design flaws to consider).

Sounds more like a waste of memory to me.

Hardly a waste of memory, you cannot do any pixel manipulation on a OpenGL texture where if you do it with a SDL surface then you can re-generate the texture. Ontop of all that the is usefull information in the surface such as dimensions, color depth etc

N64vSNES wrote: Yes it is possible, you can pass SDL_OPENGLBLIT when you initialize the video mode which allows you to use SDL blitting aswell as OpenGL's texture mapping, polygons etc. I admit the flag only exists for backwards compatability and is no longer supported but it is possible.

Never do that.

N64vSNES wrote: Hardly a waste of memory, you cannot do any pixel manipulation on a OpenGL texture...

Yes you can, read my above post.

N64vSNES wrote:where if you do it with a SDL surface then you can re-generate the texture. Ontop of all that the is usefull information in the surface such as dimensions, color depth etc

If it's loaded in as an OpenGL tex where do you expect to magically find all of that information to construct an SDL_Surface?

dandymcgee wrote:

MrDeathNote wrote:I think having a class which holds the GL texture and the SDL surface is one of your only options, you could have a pointer to the SDL surface in the class so that your not using much extra memory when your not using it. I don't see that you have too many options...

Well the pointer isn't the memory issue, it's having all of of those SDL_Surfaces loaded in memory.

Well if thats the problem he should just load the texture into an sdl_surface as a buffer then free it after he does the manipulations and stores the surface in a GL texture. It'll be expensive but at least it wouldn't be stored permanently. But in all honesty i'd go down the route you said and use ogl to manipulate the pixels instead of using SDL.

To the OP: What you're looking for here is an OpenGL extension called "WGL_ARB_pbuffer" (for windows) or "GLX_SGIX_pbuffer" (for X11). What this does is allows you to do asynchronous DMA of the front buffer to client memory. Asynchronous means that it will happen without hogging CPU cycles or the driver forcing a wait state until the data is ready. If you absolutely must convert this back to an SDL_Surface, OpenGL provides you all of the information you need to do so. With this extension it would not be necessary to create an SDL_Surface to re-upload the image as the API provides you a way to do this already without consuming client space resources or much client space time.

I'd avoid the "lazyfoo" method for pixel manipulation as that method is very rudimentary and atrociously slow.

So the rundown is this: A PBO is just a piece of memory on the card which resides in and around (usually on) the frame buffer. In terms of how you see it, it's merely a handle. You do not need to allocate resources to receive the buffer, OpenGL will give you a pointer to it. With that you then have write access to the pbuffer on the card itself. Now the way this works is going to be a little backwards from what you might think. When dealing with texture memory, OpenGL does not afford you a way to do DMA directly to and from texture memory aside from glTexImage, glCopy operations, glSubTexImage and so forth. These all require a large buffer to be tossed back & forth and is not an efficient use of time at all. The goal is to keep the operations happening in a driver controlled (OPenGL controlled) space. So what actually happens here is that whatever is in the back buffer is copied directly to the pbuffer. Since this is all in a driver space and the pbuffer resides on framebuffer memory, this is an extremely fast operation...the call will return instantaneously.

So you need to get your texture into the backbuffer. Then what you need to do is setup a fullscreen texture mapped quad pass with no image filtering whatsoever and should ideally be a size identical to the image's size so as to not introduce artifacts from filtering. Once your backbuffer is full, you can copy it to the pbuffer and obtain a pointer to it. From there you can do your manipulation and actually buffer it back to the texture with minimal penalty. This does not consume system resources with the exception being your pixel manipulation code.

If you want more details on this method, or it sounds like what you're looking for, respond here and I can hopefully get you on the right track.

dandymcgee wrote: Never do that.

Never have, never will I just had the urge to point out it was possible.

dandymcgee wrote: Yes you can, read my above post.

Fair enough....

dandymcgee wrote: If it's loaded in as an OpenGL tex where do you expect to magically find all of that information to construct an SDL_Surface?

I have no idea what your even talking about here, what I meant to say was you would be getting rid of information that can be usefull such as the dimensions of the image you've loaded and its color dept.