[SDL] Render targets
masonwheeler at yahoo.com
Thu Apr 15 08:06:37 PDT 2010
The guy who proposed that idea created an OpenGL patch for it, but I haven't
tested it so I don't know if it works or not.
As for why I like the first proposal better, it's just sort of the way I think about
the data. A render target isn't a texture, it's an object that contains a texture
but also does other things. In OOP it would probably inherit from SDL_Texture,
but since this is all in C, it would have to contain a SDL_Texture (or a
SDL_Texture pointer) instead.
That texture could do all the same things that any SDL_Texture can do, but it
would have additional functionality (the ability to render to it) that a SDL_Texture
can't do. This would mean, for example, that you can't pass an SDL_Texture
pointer to SDL_RenderCopyBuffer or SDL_RenderSetTarget, so those routines
don't have to check for it. Otherwise, you need special code in them to make
sure that the texture you've passed in uses SDL_TEXTUREACCESS_TARGET
and return an error code if it's wrong, (which the user has to check for because
C doesn't have exceptions) and so on. Compile-time errors that you can't miss
are much better than runtime errors that you can.
----- Original Message ----
From: Sam Lantinga <slouken at libsdl.org>
To: SDL Development List <sdl at lists.libsdl.org>
Sent: Wed, April 14, 2010 11:22:44 PM
Subject: Re: [SDL] Render targets
Was there any particular reason you liked the first proposal better?
The advantage of the TEXTUREACCESS_TARGET is that it's explicitly a
texture and you can do all the normal texture things with it (specify
color blending, etc.)
Does anyone have a first pass at implementation?
On Wed, Apr 14, 2010 at 6:12 AM, Mason Wheeler <masonwheeler at yahoo.com> wrote:
> I kinda like the other idea better, but at the moment I'd be willing to settle for
> whatever is faster to implement. I really do need this functionality *now,*
> which is why I've been talking about it for so long.
>>----- Original Message ----
>>From: Sam Lantinga <slouken at libsdl.org>
>>Subject: Re: [SDL] Render targets
>>There was also the idea of creating SDL_TEXTUREACCESS_TARGET and
>>having an API like this:
>>On Fri, Apr 9, 2010 at 5:37 AM, Mason Wheeler <masonwheeler at yahoo.com> wrote:
>>> Well, I gave a (somewhat) formal definition of what's needed.
>>>>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
>>>>gets displayed on screen. We also have SDL_Texture, an object that you
>>>>render from onto a SDL_Window.
>>>>We have three intrinsic characteristics here: 1) Object you can render
>>>>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
>>>>that has #1 and #2, and not #3.
>>> nfries came up with a decent API specification based on the idea. Here it is:
>>>>// Tells whether or not the renderer supports render buffer - since GL
>>> support will require 3.0+ context
>>>>// 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)
>>>>// Set the target to a render buffer, by default it should be the
>>> window's render buffer
>>>>// Blit from a buffer to another buffer or a 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
>>>>int SDL_GetRenderBufferScaleMode(SDL_RenderBuffer* buffer, int*
>>>>int SDL_SetRenderBufferBlendMode(SDL_RenderBuffer* buffer, int
>>>>int SDL_GetRenderBufferBlendMode(SDL_RenderBuffer* buffer, int*
>>>>Really, though, anything else we could do for renderbuffers would just
>>> be the same as for a texture.
>>> Seems to me that that last part could be simplified quite a bit by having the render buffer actually contain a SDL_Texture pointer. That would eliminate the need for everything from SDL_RenderCopyBuffer on.
> SDL mailing list
> SDL at lists.libsdl.org
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
SDL mailing list
SDL at lists.libsdl.org
More information about the SDL