[SDL] SDL 1.3 - SDL_Texture or SDL_Surface?

[Lazy Foo]

Sam Lantinga <slouken <at> devolution.com> writes:

> 
> 
> No, it wouldn't, but you would have to associate a texture with any
> SDL_Surface that you wanted to display, and update the texture if the
> surface changed.
> 
> 	-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment
> 

This is what I was afraid of.

SDL's rendering allows me to get graphical apps going quickly and easily. If I
need additional power, I roll my own 2D engine using OpenGL. I can get a
textured quad class together that can do most of what a SDL Surface can do in an
hour or two. It can scale and rotate too. That's what OpenGL does best, powerful
low level graphics. 

Adding bloat to SDL's rendering is a bad idea. This having a texture/surface
micromanagement is a needless hoop we need to jump through that probably
outweighs any real benefit it can provide. Instead of have an API that does one
thing really well, we'll have an API that does a bunch of things not very well.

Let SDL's rendering do what it does best: allow you to put simple graphical apps
together quickly and easily. So I'm going to say option 2.

I also have a vested interest in this as a SDL tutorial site owner. Bloating the
SDL API makes it not beginner friendly. Next week I am going to finally finish
the site after working on it for 2 years on $.60 a day.

Sam, please don't piss on what I've worked on for the past two years.