[SDL] Best way to rotate a sprite?

David Olofson david at olofson.net
Sun Jan 26 15:31:01 PST 2003

On Sunday 26 January 2003 23.33, Tane Piper wrote:
> >There are a few solutions for this, but there are some things I
> > think you should consider first:
> >
> >* Rotating surfaces is *expensive*, unless you do it in
> >  hardware - and SDL doesn't support that. (Nor does glSDL,
> >  BTW, as it's not part of the SDL API.)
> >* Rotating in software is doable, but gets *very* expensive
> >  if you want to do it with reasonable image quality.
> >  (Linear interpolation is a minimum requirement, IMHO.)
> Really?  This is a pity, because I want my game to run on min specs
> (166, 32mb ram).

Well, everything is relative. If you're only going to do it with one 
or two sprites, that won't use all that much CPU compared to a 
scrolling background. In a traditional 2D shooter, though, I don't 
think you'll get away with rotating all sprites real time on a 160 
MHz CPU; it'll take more time than the actual blitting. (Which is 
certainly slow enough as it is in 640x480 or higher resolution.)

> I wonder if we are on the same "level" because I
> have seen what I want done before quite easily in games like Grand
> Theft Auto and Micro Machines.  Basicly when I press the Up arrow,
> I want the vehicle to travel along the vector it is facing,
> accelerating, and when you press the Left arrow it starts to turn
> left (both the sprite and the vector it is traveling along) until
> the player lets go the button.  Keep holding it down, and the car
> will just spin and spin.

This can be done without rotating the sprites in real time - and at 
least in older games, that's almast always how it's done. I'd think 
most commercial games use prerendered images, while load time 
rotation might be more common in low budget, free, shareware and 
downloadable games, since it results in smaller files and less 
graphics to draw or render.

> I do kind of care about lighting, but I don't want to have
> pre-rendered turn sequences, or 4-8 direction sprites I interpolate
> between, because the car needs to be able to travel in any
> direction on a 360-degree turning circle.

I never suggested "turn sequences", and you wouldn't interpolate 
between the images, but rather switch base image for rotation based 
on rotation angle. That is, you'd get the same "infinite" resolution 
as with a single image, only there would be multiple versions of the 
image for somewhat correct lighting.

Also note that with a given resolution, there's only a certain number 
of angles you can actuall tell apart my looking at the result. With 
interpolated rotation, the number gets harder to determine, as you 
get some 256 extra steps compared to non-interpolated rotation. You 
need to try it and decide where rotation looks smooth and accurate 

> Also, there will be more
> than just car vehicles, there will be bikes, boats, planes - and I
> don't want to have a lot of resources.  Also, I want to have people
> be able to add their own vehicles, so I don't want too much work
> for people to do.  As I said, I've seen many other games do this,
> so there has to be a simple way to do it, it's probably staring me
> right in the face.

Well, if you want *both* lighting and one single image for each 
object, I think you'll have to grab some surface rotation code and 
add bumpmapping or similar dynamic lighting support to it. Then just 
draw an unlit image and a bumpmap for each image. Depending on 
rendering target (OpenGL, Direct3D, SDL 2D etc) and quality settings, 
rotate and light at load time, or in real time using software, or 
rotate + light in real time using h/w through OpenGL or Direct3D.

Doing it all in h/w means you'll either need to rely on actual h/w 
bumpmapping (which means you get no lighting at all on older cards), 
or approximate it somehow. The most common approach used in 3D games 
is probably to transform the real bumpmap into multiple "lightmaps" 
that you crossfade between depending on where the light source is in 
relation to the surface.

//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
   --- http://olofson.net --- http://www.reologica.se ---

More information about the SDL mailing list