[SDL] SDL 1.3 - SDL_Texture or SDL_Surface?

[Sami Näätänen]

On Thursday 02 August 2007, David Olofson wrote:
> On Thursday 02 August 2007, Ryan C. Gordon wrote:
> > > What I'm saying is, simply suggesting OpenGL for anything but the
> > > most
> > > basic 2D rendering isn't very helpful. It works for anything
> > > *but* Windows - which means people on a tight budget, doing
> > > anything other
> > > than retro style and/or low bandwidth games, have to go with
> > > Direct3D
> > > for rendering.
> >
> > So for SDL 1.3, would an equivalent SDL_DIRECT3D flag to match
> > SDL_OPENGL be useful?
>
> Yes - that, and maybe some "semi private" interfaces to allow add-on
> libs to integrate better with the backends. I'm thinking "backend
> plugins" that can hook into the SDL API calls, wrapping or replacing
> some of the backend calls.
>
> For example, say the SDL 1.3 API doesn't have rotation and you want
> to implement an add-on lib/backend plugin that adds that feature.
> You'd hook into the backend calls that are used for SDL_BlitSurface()
> and add implementations that implement rotation. You could do it for
> OpenGL only, and/or Direct3D and/or software - the extension should
> only be activated when a supported backend is used, modulo some
> optional "slow but correct" software fallback, perhaps. Then you add
> some custom calls to set up the rotation parameters.
>
> Of course, it's possible to do this with an application level wrapper
> (ie use SDL_MyBlitSurface() instead of SDL_BlitSurface()), but that
> means you can't directly have add-on libs (SFont, for example) render
> through your feature extended calls.
>
> > You're definitely going to end up with an #ifdef
> > WINDOWS somewhere in your app if you use it, of course, but if you
> > need to get at Direct3D functionality for all the reasons that game
> > developers already write multiple renderer codepaths, it might be
> > useful (and save you a lot of the D3D boiler plate initialization
> > code).
>
> Also, if add-on libs in the form of backend extensions/replacements
> are supported, you can keep the #ifdef WINDOWS mess in reusable
> modules.
>
> Maybe something like this "Advanced2D" I'm talking about will
> eventually become the defacto standard way of doing "almost 3D" in a
> portable way with SDL. (Add-on library with software, OpenGL and
> Direct3D backends.) It's there if it does what you need, no bloat in
> the SDL core, and you can use something else, or use Direct3D and/or
> OpenGL directly if you prefer.
>
> An "Advanced2D" API could (and some would probably suggest that it
> *should*) be built into SDL - but there are many ways to design such
> an API, but no single, obviously correct way. Should it be usable
> with 2D-only acceleration? Is "fast" software rendering a
> requirement? Subpixel accuracy? Antialiazing? How many features until
> everyone goes "Just use OpenGL!"?
>
> If it's a separate project (or several projects with different
> goals), you can use it as is, modify it, hack your own, use somebody
> else's hacked or independent version, or whatever. Some developers
> might want to go all the way to a full blown 3D API, eliminating the
> need for Direct3D + OpenGL support for most 2D and 3D applications.
> Others might just want plain fast zoom and rotation with h/w
> acceleration where available. Same thing; just a matter of feature
> set.

This plugin interface could be usefull for audio and input systems as 
well. This way it would make SDL a Simple interface for GFX, Audio and 
Input. People could provide different kinds of plugins for these 
systems. These interfaces could then be used from small accelerated 
blitter plugins all the way up to 3rd party game engines.