Hello list,
Here is a patch proposal to provide rendering to a texture.
It can be applied to the current trunk of SDL 1.3.
Currently, the only renderer on which I implemented it is the GL one.
What it does:
It adds a new function in SDL_video.h :
int SDL_SetTargetTexture(SDL_TextureID textureID)
where textureID is the ID of the texture to target, or 0 to revert the
target back to the window.
The texture has to be created with an access value of
SDL_TEXTUREACCESS_TARGET to be used this way.
A corresponding function is added to the renderer functions table.
What do you think of it?
FlorentOn Fri, Jun 19, 2009 at 3:36 PM, Sam Lantinga wrote:
It doesn’t, I’m just pointing out that there is an equivalent to the 1.2
functionality that Floren was using, with about the same performance.
Oh, I misread your comments. You’re not actually creating a surface from a
texture. You’re creating a reference to existing streaming texture pixels
with a temporary SDL_Surface structure that other SDL API’s can draw to.
This is actually how the SDL 1.2 “video surface” API is implemented. You
can see an example in SDL_compat.c
As far as actual render target support, I’m not opposed to it, but when we
implemented the experimental 1.3 render target support a while back, there
wasn’t uniform support for the feature across API and graphic cards at the
time.
You’re welcome to submit patches though. You can even use that old branch
for reference:
http://www.libsdl.org/cgi/viewvc.cgi/branches/SDL-1.3-textureAPI/
On Thu, Jun 18, 2009 at 8:47 PM, Mason Wheeler wrote:
OK, I’m lost. How does creating a new surface from an existing texture
equate to copying from one texture to another? Once you create the new
surface, it still needs to be converted to a texture to be usable, with the
corresponding performance hit. What we’re looking for is to draw textures
directly onto each other as render targets so as to keep the surface ->
texture conversions to an absolute minimum.
*
*From: Sam Lantinga
**Subject: Re: [SDL] Blitting from one texture to another (was: Mac OS
X speed)
FYI, this is what streaming textures and SDL_CreateRGBSurfaceFrom() are
for.
Some functions you’ll need:
SDL_QueryTexture(), SDL_QueryTexturePixels(),
SDL_PixelFormatEnumToMasks(), SDL_CreateRGBSurfaceFrom(), etc.
On Wed, Jun 17, 2009 at 6:07 PM, Florent GMail (imap) <@florent_boudet wrote:
Sorry to bring back this old thread, but I am interested in the subject
that was discussed here.
I think the game I’m working on could benefit greatly from an API in SDL
1.3 allowing blitting from one texture to another.
I am facing with the following problems that can be resolved with such a
feature:
-
My game composes an image with a lot of tiles. All the tiles are loaded
as textures, and blitted individually for every frame on the screen. In SDL
1.2, I used to compose my image in an intermediate surface on which I only
update the deltas between frames, and then blit this intermediate surface on
the screen. On SDL 1.3, using an intermediate surface and transfering it to
a texture to blit on the screen is too slow, and I get better performances
when blitting every tile individually each frame. However, I notice a
sensible frame drop when the number of tiles tend to increase. I think
having an intermediate texture that can be used as the intermediate surface
of the SDL 1.2 version could help smooth the framerate, but this requires
the ability to blit from one texture to another.
-
To manage transition effects, I sometimes have to render the whole
screen to an offscreen buffer. In SDL 1.2, it was a simple matter of
blitting to an offscreen SDL_Surface instead of blitting on the display
surface. On SDL 1.3, I have to keep a copy of my textures as SDL_Surface to
be able to blit them on an SDL_Surface that will be copied to a texture in
order to achieve the same effects. This would be enhanced a bit in terms of
speed and memory consumption if there was a way to blit from one texture to
another.
Is there something preventing the adoption of this kind of feature in SDL
1.3? If no, I would be glad to work on it.
I think almost every implementation of OpenGL feature this ability (but
sometimes in nonstandard ways).
Florent
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
-------------- next part --------------
A non-text attachment was scrubbed…
Name: set_target_texture.diff
Type: text/x-patch
Size: 10020 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20090623/34cdd3fd/attachment.bin