[SDL] SDL 1.3 - SDL_Texture or SDL_Surface?

[Rainer Deyke]

Sam Lantinga wrote:
> So I'm reviewing the feature list for SDL 1.3, and looking at the video API.
> 
> Given the state of hardware and 3D today, which would people find more useful:
> 1. A brand new texture API with the following features:
>    * color modulation, alpha blending, linear/bilinear scaling
> 2. Acceleration of the existing SDL_Surface API, similar to glSDL

Does the SDL 2D video API even matter?

If you want high-performance, feature-rich 2D graphics with 
acceleration, you're better off using OpenGL (and optionally Direct3D) 
directly.

If you want high-performance, feature-rich 2D graphics without 
acceleration, you're better off using custom blitters to write directly 
to the frame buffer.  Any blitters that SDL provides will either lack 
the features needed for a particular application, or be too slow because 
they support too many unnecessary features.

If you want high-performance, feature-rich 2D graphics with acceleration 
support but without requiring 3D acceleration, you need a high-level API 
that has separate code paths for software rendering and OpenGL 
rendering.  However, as long as SDL provides access to both OpenGL and 
the frame buffer, there is no need for this high level API to be part of 
SDL.  It's actually a good thing if this high-level graphics API is 
separate from SDL, because different applications will need different 
high-level graphics APIs with different feature sets.  I've been using 
this strategy (with my own custom high-level graphics API) for years.

To answer the question more directly:  I like color modulation.  I like 
alpha blending.  I like having different blending modes.  I like 
mirrored and rotated (in 90 degree increments) blitting.  I don't see 
why this cannot be done with existing SDL_Surfaces with the addition of 
an SDL_Blit_Enhanced function.  I don't like scaling at all, and I 
loathe bilinear filtering.  However, I ultimately don't care so long my 
own high-level 2D graphics API continues to work on top of SDL.


-- 
Rainer Deyke - rainerd at eldwood.com