Image rotation

SDL Development
1

I am writing a game that consists of controlling a ship that travels
around an arena shooting other ships. The right/left keys rotate the
ship, and the up/down keys propel it in the direction it is pointing.

I need to generate the rotated frames of the ship somehow, but there
doesn’t seem to be an easy way of doing it.

I have one image of the ship that is 128x128 with a black background. For
the ship, I resized the image to 49x49 and then filled in the background
with bright orange (for transparency).

Originally, I wanted to have a rotated image every 5 degrees, and store
all of the rotated images in one file so I could just modify the
SDL_Rect’s x and y coords to change the image used for the ship. The
problem with doing this is that when you rotate the image, the corners
stick out, so you have to cut them off while trying to keep the
center the same to avoid jitteryness. After rotation and cutting,
the resulting image must be resized down to the 49x49, and then the
background must be colored in with orange. Doing this with all 72 frames
for the image would take hours with gimp, and then arranging each frame
into one big image would take much more time than that, because every
image must be positioned perfectly.

I can use ImageMagick’s convert command to generate the rotated images
with a bash script, but the problem still remains of cutting off the
extraneous edges made from rotating, resizing to 49x49, coloring the
background orange, and then adding them all to each other (convert
can append).

I’m sure there is some algorithm that would rotate the image in-game from
one sprite, but I am not so sure that it would be fast enough.
Additionally, I have no idea whatsoever how such a beast would be written.

There will be many different ships, so anything I decide on will have to
be done for each ship.

Anyone know of something that would automate this process, or know of the
above mentioned algorithm and it’s implementation?

Thanks!

-helo--------------
DVD-Playing-HOWTO - http://helo.org/dvd/howto

2

There are several ways to do this.
First, you could rotate and assemble the sprite in game (not in the gameloop,
but create the rotated and assembled image on startup). With this method, you
would have a routine you could call again and again for each new rotated
sprite (which would be very handy). The other way is to make the background
of the ship transparent in gimp and move it to a layer, rotate it, shrink it,
bucket-fill the lowest layer with the color of your choice, save it and repeat.
Then assemble the pictures. This could be done with gimps script-fu (I have
been told that it’s pretty easy, but I have yet to try this myself).
One thing about the last method that’s nice is that you can retouch each frame
(lightning/shadow) so things will look nicer.

inful
BLiP!

3

Hi Nathan,
the comp.graphics.altgorithms-faq says:On Wed, Mar 15, 2000 at 04:13:23PM -0600, Nathan Rowlan wrote:

I’m sure there is some algorithm that would rotate the image in-game from
one sprite, but I am not so sure that it would be fast enough.
Additionally, I have no idea whatsoever how such a beast would be written.

There will be many different ships, so anything I decide on will have to
be done for each ship.

Anyone know of something that would automate this process, or know of the
above mentioned algorithm and it’s implementation?

Subject 3.01: How do I rotate a bitmap?

The easiest way, according to the comp.graphics faq, is to take
the rotation transformation and invert it. Then you just iterate
over the destination image, apply this inverse transformation and
find which source pixel to copy there.

A much nicer way comes from the observation that the rotation
matrix:

    R(T) = { { cos(T), -sin(T) }, { sin(T), cos(T) } }

is formed my multiplying three matrices, namely:

    R(T) = M1(T) * M2(T) * M3(T)

where

    M1(T) = { { 1, -tan(T/2) },
              { 0, 1         } }
    M2(T) = { { 1,      0    },
              { sin(T), 1    } }
    M3(T) = { { 1, -tan(T/2) },
              { 0,         1 } }

Each transformation can be performed in a separate pass, and
because these transformations are either row-preserving or
column-preserving, anti-aliasing is quite easy.

Reference:

Paeth, A. W., "A Fast Algorithm for General Raster Rotation",
Proceedings Graphics Interface '89, Canadian Information
Processing Society, 1986, 77-81
[Note - e-mail copies of this paper are no longer available]

[Gems I]

But since I don’t understand that myself I would use another way :wink:

The idea is to basicaly do 2d-texture-mapping on a fixed polygon ;). Let the
middle of the bitmap be (0,0). Then the corners are (-24,-24), (24,-24) and
so on. That’s so you can better rotate them, because that’s what you do. You
rotate them by 5? (or whatever), which creates a new box, overlaying (in
your mind) the original bitmap. The upper-left corner my have moved to
something like (-22,-26), that is outside the original bitmap. You then loop
through the x and y-coordinates of a destination bitmap (same size), and
take the pixels from your rotated box. You find the source-pixel by
interpolating between the rotated edges/corners. The first pixel will come
from the abovementioned upper-left-corner. The next comes from (upperleft +
(upperright - upperleft) / 49). And so on. If a source-pixel would be read
from outside the original (as e.g. the corners would always be) then it’s
automaticaly transparent.
Note that if you rotate to the left, your ship will turn right. Also note
that the center of the ship must be the center of the rotation, but this
need not be the center of the bitmap, it’s just easier that way. What is
needed though is, that the ship has enough room inside it’s bitmap to rotate
with a fixed center. Otherwise the position where the sprite needs to be
plotted on the screen would depend on the animation-frame in a realy ugly
way.
As for speed, there’s a lot of optimization-potential in this kind of stuff,
but I would rather do it once before the game starts.
I hope I explained it ok, if not email me. Drawing pictures on paper also
helps to visualize it.

All the best,
rob

4

Robert Linden wrote:

    R(T) = { { cos(T), -sin(T) }, { sin(T), cos(T) } }

But since I don’t understand that myself I would use another way :wink:

Let’s say you want to rotate point p = (x,y) around the origin with
angle T (note that this is supposed to be a capital theta ;)) all you
have to do is to calculate R(T)*p to get the rotated point. It is a
simple matrix multiplication (linear algebra). That more complex looking
formula can be used if you want to perform anti aliasing, but I guess
you will rather use gimp or photoshop for those effects ;).

So (x,y) rotated around the origin with angle T gets (x * cos(T) - y *
sin(T), x * sin(T) + y * cos(T)). Basically you could rotate the edge
points first to know how big the rotated image will get. Don’t mind if
the image gets larger as long as you fill the obsolete parts with a
color key. I think SDL has a feature to use RLE transparency
’compression’ so this won’t be a performance hit.

So far for the little math behind it. But if you want your game to look
a bit cool I suggest you precalculate those frames and save them (using
gimp e.g.).–
Daniel Vogel My opinions may have changed,
666 @ http://grafzahl.de but not the fact that I am right

5

Nathan Rowlan wrote:

I am writing a game that consists of controlling a ship that travels
around an arena shooting other ships. The right/left keys rotate the
ship, and the up/down keys propel it in the direction it is pointing.

I need to generate the rotated frames of the ship somehow, but there
doesn’t seem to be an easy way of doing it.

I have one image of the ship that is 128x128 with a black background. For
the ship, I resized the image to 49x49 and then filled in the background
with bright orange (for transparency).

Originally, I wanted to have a rotated image every 5 degrees, and store
all of the rotated images in one file so I could just modify the
SDL_Rect’s x and y coords to change the image used for the ship. The
problem with doing this is that when you rotate the image, the corners
stick out, so you have to cut them off while trying to keep the
center the same to avoid jitteryness. After rotation and cutting,
the resulting image must be resized down to the 49x49, and then the
background must be colored in with orange. Doing this with all 72 frames
for the image would take hours with gimp, and then arranging each frame
into one big image would take much more time than that, because every
image must be positioned perfectly.

I can use ImageMagick’s convert command to generate the rotated images
with a bash script, but the problem still remains of cutting off the
extraneous edges made from rotating, resizing to 49x49, coloring the
background orange, and then adding them all to each other (convert
can append).

I’m sure there is some algorithm that would rotate the image in-game from
one sprite, but I am not so sure that it would be fast enough.
Additionally, I have no idea whatsoever how such a beast would be written.

There will be many different ships, so anything I decide on will have to
be done for each ship.

Anyone know of something that would automate this process, or know of the
above mentioned algorithm and it’s implementation?

Since my first solution for anything is a script, I’d go with automation
using the standard(?) Unix image processing tools.
Take a look at:
pnmscale
ppmchange
pnmrotate
pnmcut
pnmcat

plus all of the XXXto{pnm,ppm} and {pnm,ppm}toXXX to convert file
formats

Hopefully that helps

Julian.