[SDL] When will there be blitting support when using OpenGL

vining at pacificcoast.net vining at pacificcoast.net
Wed Apr 5 12:11:29 PDT 2000

>While I think blitting to/from texture maps and/or blitting from the 3D frame
>buffer would be nice, in most cases they aren't necessary.

Unfortunately, not true. We have no way of guaranteeing that an SDL_Surface has not changed since the last upload (since we can access 
the surface's pixels directly without going through another API), therefore we would need to constantly re-upload. A cruel world.
As for necessity, you're right, but if you wanted to do something like rewrite SDL's video aspect to do 2D blits on top of OpenGL you would 
have to. Sucky.

>It would be nice if (when availible) the same API functions can used to copy
>to/from textures and from 3D framebuffers as are used for blitting.  Not a
>necessity, but a convienence...

A bad one. Not only do you end up forcing a re-upload each time but you work in immediate mode (even worse, forcing a glBegin/glEnd pair 
per blit, because you can't rely on the user to do it and you don't know what mode you'll be in, so you can't do just one), don't hit the best 
pipeline, and run into a few other interesting hassles like that.

>What I think is REALLY ANNOYING, however, is that the documentation seems to
>say that all blitting is disabled... I see no reason to disable off-screen
>surface blitting in a 3D application.

I don't think it is. Whoops! (another one for my doc fix this evening) You still need to be careful though, because you need to remember that 
you always have to re-upload the texture after blitting, and that SDL can't read your mind here. Since you're managing the texture object 
yourself, and SDL isn't, it doesn't know where this accursed thing has to go. Bad practice for an API to rely on users doing the smart 
thing.... I think we can safely say that they never do ;-)



More information about the SDL mailing list