Best way to rotate a sprite?

SDL Development
1

Hey everyone,

At the moment, I am using a rather dodgy control method in my game where the direction button changes the sprite on screen to face that direction, but each direction has its own bitmap:

Up button loads bitmap 0,
Right button load bitmap 1, etc.

What I want to do is change this so there is only one bitmap needed for the sprite and the buttons rotate the sprite, or make it go backwards or forwards along the angle it’s facing - the same control system used in the original Grand Theft Auto. I don’t see anything in the SDL docs that directly allow you to control the rotation of a SDL_surface (and from this I can do the forward and backward motion along the vector of the sprite direction). Is there any libraries that allow you to do this directly to the surface, or can anybody help with code for this problem?

Thanks,
Tane Piper: http://tane.cream.org

2

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.)

* Just rotating a sprite won't change the lighting of the
  image (obviously), so unless the sprite is created with
  the ligh right from top (rather unusual), it will look
  plain wrong.

If you don’t cane about “realistic” ligthing, I’d recommend you grab
SGE or some other lib (I’m too lazy to find the URLs for you right
now :wink: and do the rotation load time, creating an array of surfaces
indexed by the direction of the object. This is fast and simple, and
lets you test different numbers of images very easilly.

Later on, you can either ditch the rotation code and load a set of
prerendered images, or combine the methods; have 8 or 16 prerendered
images with correct lighting, and rotate at load time to generate
intermediate images if you want more.

//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 —On Sunday 26 January 2003 19.34, Tane Piper wrote:

Hey everyone,

At the moment, I am using a rather dodgy control method in my game
where the direction button changes the sprite on screen to face
that direction, but each direction has its own bitmap:

Up button loads bitmap 0,
Right button load bitmap 1, etc.

What I want to do is change this so there is only one bitmap needed
for the sprite and the buttons rotate the sprite, or make it go
backwards or forwards along the angle it’s facing - the same
control system used in the original Grand Theft Auto. I don’t see
anything in the SDL docs that directly allow you to control the
rotation of a SDL_surface (and from this I can do the forward and
backward motion along the vector of the sprite direction). Is
there any libraries that allow you to do this directly to the
surface, or can anybody help with code for this problem?

3

Hey everyone,

At the moment, I am using a rather dodgy control method in my game
where the direction button changes the sprite on screen to face that
direction, but each direction has its own bitmap:

Up button loads bitmap 0,
Right button load bitmap 1, etc.

What I want to do is change this so there is only one bitmap needed
for the sprite and the buttons rotate the sprite, or make it go
backwards or forwards along the angle it’s facing - the same control
system used in the original Grand Theft Auto. I don’t see anything in
the SDL docs that directly allow you to control the rotation of a
SDL_surface (and from this I can do the forward and backward motion
along the vector of the sprite direction). Is there any libraries
that allow you to do this directly to the surface, or can anybody help
with code for this problem?

To rotate sprites into arbitrary directions, you can always use openGL
and make everything textures on simple polygons. These can be rotated
like crazy. There is some learning curve involved with openGl, but it
can do this kind of thing.On Sun, 26 Jan 2003 18:34:36 -0000 “Tane Piper” <tane.piper at ukonline.co.uk> wrote:

@Florian_Schmidt
http://www.arted.biz/mista.tapas

4

[…]

To rotate sprites into arbitrary directions, you can always use
openGL and make everything textures on simple polygons. These can
be rotated like crazy. There is some learning curve involved with
openGl, but it can do this kind of thing.

Yes - and OpenGL is great for 2D in many other ways as well.
(Blending, scaling with interpolation, etc.)

The only problem is that it won’t really run at all without h/w
accelerated OpenGL. S/w emulation on any CPU available to normal
people even today makes seconds/frame a more suitable unit than fps.

Also, it seems like there are some 3D cards these days that have only
Direct3D/DirectGraphics drivers, and obviously, OpenGL code will run
in software mode on those as well, unless you can find something that
implements OpenGl on top of Direct3D/DirectGraphics, and is solid
enough for serious use.

//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 —On Sunday 26 January 2003 20.57, Florian Schmidt wrote:

5

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). 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.

  • Just rotating a sprite won’t change the lighting of the
    image (obviously), so unless the sprite is created with
    the ligh right from top (rather unusual), it will look
    plain wrong.
    If you don’t cane about “realistic” ligthing, I’d recommend you grab
    SGE or some other lib (I’m too lazy to find the URLs for you right
    now :wink: and do the rotation load time, creating an array of surfaces
    indexed by the direction of the object. This is fast and simple, and
    lets you test different numbers of images very easilly.
    Later on, you can either ditch the rotation code and load a set of
    prerendered images, or combine the methods; have 8 or 16 prerendered
    images with correct lighting, and rotate at load time to generate
    intermediate images if you want more.

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.
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.

Tane Piper
http://tane.cream.org

6

a solution would be to take each sprite that can rotate and rotate them to
all the angles youd need rotation for and store them so when your in the
game, you dont need to rotate them, you just use the proper pre-rendered
picture.> ----- Original Message -----

From: tane.piper@ukonline.co.uk (Tane Piper)
To:
Sent: Sunday, January 26, 2003 2:33 PM
Subject: Re: [SDL] Best way to rotate a sprite?

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). 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.

  • Just rotating a sprite won’t change the lighting of the
    image (obviously), so unless the sprite is created with
    the ligh right from top (rather unusual), it will look
    plain wrong.
    If you don’t cane about “realistic” ligthing, I’d recommend you grab
    SGE or some other lib (I’m too lazy to find the URLs for you right
    now :wink: and do the rotation load time, creating an array of surfaces
    indexed by the direction of the object. This is fast and simple, and
    lets you test different numbers of images very easilly.
    Later on, you can either ditch the rotation code and load a set of
    prerendered images, or combine the methods; have 8 or 16 prerendered
    images with correct lighting, and rotate at load time to generate
    intermediate images if you want more.

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.
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.

Tane Piper
http://tane.cream.org

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

7

This is something I have to do in my game right now, software-based
SDL_Surface rotation. SDL_gfx has a pretty fast method of rotating. If
you’re into the math of it, you can take your hand at writing a
Bresenham-line based method of rotating, which from what I read is the
fastest way to do it. Anyway, I do have a GPL-licensed function that
SDL_gfx and any other software-based solution I could find. If you want
to check it out:

it’s the SDL_Surface *rotate( SDL_Surface *s, float ang ); function in
that file. But yeah, I agree with everybody else, you should cache all
the rotations you’ll need or use hardware accelerated rotations.from my testing and the testing of a friend works a little faster than

On Sun, 2003-01-26 at 10:34, Tane Piper wrote:

Hey everyone,

At the moment, I am using a rather dodgy control method in my game
where the direction button changes the sprite on screen to face that
direction, but each direction has its own bitmap:

Up button loads bitmap 0,
Right button load bitmap 1, etc.

What I want to do is change this so there is only one bitmap needed
for the sprite and the buttons rotate the sprite, or make it go
backwards or forwards along the angle it’s facing - the same control
system used in the original Grand Theft Auto. I don’t see anything in
the SDL docs that directly allow you to control the rotation of a
SDL_surface (and from this I can do the forward and backward motion
along the vector of the sprite direction). Is there any libraries
that allow you to do this directly to the surface, or can anybody help
with code for this problem?

Thanks,
Tane Piper: http://tane.cream.org

–
Chris Thielen <@Christopher_Thielen>

8

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
enough.

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 —On Sunday 26 January 2003 23.33, Tane Piper wrote:

9

Do you REALLY need 360 different angles for your images, though?

I mean, why stop there? Why not allow the car to move in fractions of degrees?
Have 720 different images? Or 1440? :^)

For most 2D gaming purposes, 16 or even 32 or 36 different angles of your
images is plenty.

At some point, your sprite is so small that the 91 degree and 92 degree
images of the car are indistinguishable.

-bill!On Sun, Jan 26, 2003 at 10:33:59PM -0000, Tane Piper wrote:

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.

10

On this note, I think your right, and I need to re-think it. I was thinking
more 1 image which I rotate through 360-degrees, but I don’t really need
more than 8, or 16 directions at the most. So basically each time I press
the left or right arrow key, it will turn the graphic 22.5 degrees, and then
make it travel along that vector for the up/down arrow keys. If I need to I
can always make the resolution of the turn smaller to make 32 or 36
directions if needed.

Thanks guys, now I can go back to the drawing board.

Tane Piper
http://tane.cream.org

Do you REALLY need 360 different angles for your images, though?

I mean, why stop there? Why not allow the car to move in fractions of
degrees?> Have 720 different images? Or 1440? :^)

For most 2D gaming purposes, 16 or even 32 or 36 different angles of your
images is plenty.

At some point, your sprite is so small that the 91 degree and 92 degree
images of the car are indistinguishable.

11

Well 32 is better than 36, because with 32 different angles you will get
the 45 degree diagonal angles, but with 36 steps the angles will go in
10 degree steps.

PS. With 32 (or 16) steps you can use logical and to clamp the angle
after increasing or decreasing it.

angle = (angle + 1) & $1F; // clamps the angle between 0 and 31
angle = (angle - 1) & $1F; // clamps the angle between 0 and 31On Tuesday 28 January 2003 00:40, Tane Piper wrote:

On this note, I think your right, and I need to re-think it. I was
thinking more 1 image which I rotate through 360-degrees, but I don’t
really need more than 8, or 16 directions at the most. So basically
each time I press the left or right arrow key, it will turn the
graphic 22.5 degrees, and then make it travel along that vector for
the up/down arrow keys. If I need to I can always make the
resolution of the turn smaller to make 32 or 36 directions if needed.

12

thats a neet trick> ----- Original Message -----

From: sami.naatanen@kolumbus.fi (Sami Naatanen)
To:
Sent: Monday, January 27, 2003 3:15 PM
Subject: Re: [SDL] Best way to rotate a sprite?

On Tuesday 28 January 2003 00:40, Tane Piper wrote:

On this note, I think your right, and I need to re-think it. I was
thinking more 1 image which I rotate through 360-degrees, but I don’t
really need more than 8, or 16 directions at the most. So basically
each time I press the left or right arrow key, it will turn the
graphic 22.5 degrees, and then make it travel along that vector for
the up/down arrow keys. If I need to I can always make the
resolution of the turn smaller to make 32 or 36 directions if needed.

Well 32 is better than 36, because with 32 different angles you will get
the 45 degree diagonal angles, but with 36 steps the angles will go in
10 degree steps.

PS. With 32 (or 16) steps you can use logical and to clamp the angle
after increasing or decreasing it.

angle = (angle + 1) & $1F; // clamps the angle between 0 and 31
angle = (angle - 1) & $1F; // clamps the angle between 0 and 31

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

13

So basically each time I press the left or right arrow key, it will turn
the graphic 22.5 degrees, and then make it travel along that vector for the
up/down arrow keys.

i’m workin on a game, and doin basically the same thing you want to do. what
i did was pre-render like 36 or so images of each “ship”. then, when the
user presses the left/right keys, i just change the angle the ship is moving
at. then, i my rendering, i just choose which of the 36 bitmaps to draw…

this works good, b/c the ship can be facing in any direction between 0 and
360, down to the precision of float, but the way its gonna show up is one of
36 different pre-rendered pictures… this works real good for me… :slight_smile:

M@ the madprogrammer_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online
Antivirus, VPN, Identity & Privacy Protection | McAfee

14

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1On Tuesday 28 January 2003 00:15, Sami N??t?nen wrote:

PS. With 32 (or 16) steps you can use logical and to clamp the angle
after increasing or decreasing it.

angle = (angle + 1) & $1F; // clamps the angle between 0 and 31
angle = (angle - 1) & $1F; // clamps the angle between 0 and 31

Note that most compilers should optimize this automatically (IIRC gcc does
it even with optimizations disabled). You could always look at the assembly
output just be sure :wink:

cu,
Nicolai
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+NsUWsxPozBga0lwRAu1CAJ42NS87UESGZ5laPhl3YKd8H5sa1gCgwddP
apsnfh0QN0mMjd6392ycw/I=
=19E3
-----END PGP SIGNATURE-----

15

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

PS. With 32 (or 16) steps you can use logical and to clamp the
angle after increasing or decreasing it.

angle = (angle + 1) & $1F; // clamps the angle between 0 and 31
angle = (angle - 1) & $1F; // clamps the angle between 0 and 31

Note that most compilers should optimize this automatically (IIRC gcc
does it even with optimizations disabled). You could always look at
the assembly output just be sure :wink:

You can use the following and it will most likely be optimized to the
above code by almost any compiler.

angle = (angle + 1) % 32;
angle = (angle - 1) % 32;

I simply used the allready optimized version, because the later could
easily give the false impression that any number will do. In fact any
number will do, but only exact powers of two can be optimized to use
and.

PS. got those hex values wrong (not C syntax), but I think everybody got
what I meant.On Tuesday 28 January 2003 19:59, Nicolai Haehnle wrote:

On Tuesday 28 January 2003 00:15, Sami N??t?nen wrote:

16

In fact the above thing doesn’t work correctly, because the C standard
defines the %-operator as mathematically correct reminder operation.

So the -1 % 32 = -1, but we want it to be 31.

Some compilers make the two above codes identical, although they
shouldn’t.

Should have checked that before posting, but completly forget that. Too
much old and/or buggy compiler experience.On Tuesday 28 January 2003 22:54, Sami N??t?nen wrote:

PS. With 32 (or 16) steps you can use logical and to clamp the
angle after increasing or decreasing it.

angle = (angle + 1) & $1F; // clamps the angle between 0 and 31
angle = (angle - 1) & $1F; // clamps the angle between 0 and 31

angle = (angle + 1) % 32;
angle = (angle - 1) % 32;

17

Can’t you just rotate a sprite by creating a 2D plane and mapping the bmp to it and rotating the plane using the 3D interfaces? I’m assuming by using the 3D stuff you then need to make sure that they have OpenGL, but wouldn’t that work as well if you wanted to rotate realistically rather than being limited to a set number of angles?

  • Joby
    http://jobybednar.com
    Give someone a program - frustrate them for a day.
    Teach them how to program - frustrate them for a lifetime.> ----- Original Message -----

From: sami.naatanen@kolumbus.fi (Sami Naatanen)
Reply-To: sdl at libsdl.org
Date: Wed, 29 Jan 2003 00:30:14 +0200

On Tuesday 28 January 2003 22:54, Sami N??t?nen wrote:

PS. With 32 (or 16) steps you can use logical and to clamp the
angle after increasing or decreasing it.

angle = (angle + 1) & $1F; // clamps the angle between 0 and 31
angle = (angle - 1) & $1F; // clamps the angle between 0 and 31

angle = (angle + 1) % 32;
angle = (angle - 1) % 32;

In fact the above thing doesn’t work correctly, because the C standard
defines the %-operator as mathematically correct reminder operation.

So the -1 % 32 = -1, but we want it to be 31.

Some compilers make the two above codes identical, although they
shouldn’t.

Should have checked that before posting, but completly forget that. Too
much old and/or buggy compiler experience.

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

18

angle = (angle + 1) % 32;
angle = (angle - 1) % 32;

In fact the above thing doesn’t work correctly, because the C standard
defines the %-operator as mathematically correct reminder operation.

So the -1 % 32 = -1, but we want it to be 31.

Use following code instead.

angle = (angle + 1) % 32;
angle = (angle + 31) % 32;

// “angle + 31” misses the chance to be optimized because IA-32 has “dec” instruction
// to decrement a value of the register. But it is not so important.
// Maybe this line will be exectuted less than 1000 times / frame for the purpose.

KentaroFrom: sami.naatanen@kolumbus.fi (Sami Naatanen)
Subject: Re: [SDL] Best way to rotate a sprite?
Date: Wed, 29 Jan 2003 00:30:14 +0200

19

angle = (angle + 1) % 32;
angle = (angle - 1) % 32;

In fact the above thing doesn’t work correctly, because the C
standard defines the %-operator as mathematically correct reminder
operation.

So the -1 % 32 = -1, but we want it to be 31.

Use following code instead.

angle = (angle + 1) % 32;
angle = (angle + 31) % 32;

This is good if the divisor is not an exact power of two. How ever if it
is the original example, which uses and is faster, so no reason to use
this.On Wednesday 29 January 2003 00:55, Kentaro Fukuchi wrote:

From: Sami N??t?nen <sami.naatanen at kolumbus.fi>
Subject: Re: [SDL] Best way to rotate a sprite?
Date: Wed, 29 Jan 2003 00:30:14 +0200

20

Niggle time:

You meant to say the C standard defines the % operator as the mathematically
incorrect remainder, otherwise known as truncation towards zero, and
formally defined as discarding any fractional part of the result. This is
purely for efficiency - mathematically it’s offensive, but unfortunately we
can’t go back in time and add the few extra transistors it would have taken
to do the job properly in the early CPUs.

Regards,

DanielOn Tuesday 28 January 2003 23:30, Sami N??t?nen wrote:

On Tuesday 28 January 2003 22:54, Sami N??t?nen wrote:
In fact the above thing doesn’t work correctly, because the C standard
defines the %-operator as mathematically correct reminder operation.

So the -1 % 32 = -1, but we want it to be 31.