Chapter 4. 4 Programming Sprites in Allegro 5

4.1.1. Using Static Sprites in Allegro 5

In Allegro 5, a sprite is simply another bitmap object that can be displayed on the screen. You may notice that this sounds similar to the description of bitmap given in the previous chapter which raises an important question: What distinguishes sprites from ordinary bitmaps? A sprite bitmap (which we will just refer to as a sprite) is typically a moving object and not considered part of the background of a game. So we have now two layers, if you will, of images being utilized: a bitmap for a game background and then the moving of stationary objects on top of that—sprites. Sprites tend then to be small graphic images, with sizes like 32 × 32 and 64 × 64, or 128 × 128 and 256 × 256, although they could be of any size. However, when it comes to the animation aspect of the sprite, these smaller sizes are of benefit (since an animate sprite is a matrix of single bitmaps amalgamated in a larger object—more on that later).

Sprites are commonly utilized for the player character, nonplayer characters (NPCs), in-game objects, and weapons fire (projectiles, beams, etc.) The sprite is then a self-contained object that will have characteristics allowing it to be unitized through various means: movement around the screen (or the denial of movement), detection of collisions with objects, and so on.

As we look at an example of a sprite program, here we see some of the logic in the simplistic style of Allegro, providing the ability to use the same routines, building upon them to do more complex actions, thus easing the programmer’s work by using familiar processes. As such, you will see commonalities in the routines and setup used for bitmaps and what we classify as sprites, allowing us to use similar library routines but for differing purposes.

In the example program, we load two bitmaps: one to use as the background and the other as the movable sprite. We’ll use our CatCosmos.png as the background and a simple flying saucer sprite, SmallSaucer.png (see figure 4.1)

Now one of the issues we have to deal with for sprites is, What do we display and what do we hide? If we use the saucer image as is, we will see the full image: the red square and the saucer. Oh, but it’s way too big for the size of our screen, as you can see in figure 4.2.

So we need to resize the saucer (we can do that in a graphics package like GIMP) and hide the red areas.

4.1.2. Alpha Blending and Its Purpose

In computer graphics, we use a function called alpha blending to make areas transparent or opaque. In addition to RGB (red, green, blue), some graphics come with a fourth value associated with their colours, giving them RGBA, where the A value is an alpha, a bit value used to indicate transparency. If the bitmap you decide to use doesn’t have an alpha channel, Allegro has a routine to specify what colour the developer wishes to define as that alpha value, which will display as transparent or opaque. The process is to define the specified colour to establish a “mask” (the area that will be transparent, letting a background show through), defining it as an “alpha channel.”

The routine to do this is:

Colours in Allegro 5 are typically represented using the ALLEGRO_COLOR structure, which includes red, green, blue, and alpha (transparency) components. For the routine, one can define a transparent colour in advance:

Here, you can use the ALLEGRO_COLOR al_map_rgb(unsigned char r, unsigned char g, unsigned char b) routine, which converts r, g, b (ranging from 0 to 255) into an ALLEGRO_COLOR, using 255 for alpha, and then call it like so:

Alternately, one can embed the al_map_rgb routine right in the other routine:

We then need to call the blending routine in our code to enable the use of the alpha channel and have transparency:

Then Allegro will handle the rest when we draw the sprite.

Transparency is a powerful tool for creating effects like ghostly figures, smoke, shadows, or UI elements that need to overlay the game without completely obscuring the background. Translucent sprites are also useful for visual cues, such as indicating that a character is in stealth mode or partially invisible, or for effects like energy shields and force fields.

Our sprite’s red background, though, isn’t pure red. This becomes clear when one tries to run a test program using the bitmap and setting the transparency value of 255 for al_map_rgb. If one does that, you will still see the red square background. Computers are precise when it comes to numerical values, and so we need to find out what “shade” of red this is. As such it is necessary here to use a graphics program (like the free GIMP graphics package) and then a tool like the colour sampler (usually a small dropper type of icon), which will tell you the RGB values for that point, for example.

From the information provided, we see the RGB values are 237, 28, 36 for the red square area. We then would change those values in the code like so:

This allows the red areas to become transparent, as seen in figure 4.4.

Let’s look at the program code to do this. Here is a simple Allegro 5 program that displays a spaceship sprite and lets one move it across a background image using the keyboard keys.

4.1.3. Program Example—SpriteMove.c

Now let’s walk through the structure so we understand how it all fits together.

4.1.4. Program Overview

4.2.1. Drawing Scaled Sprites

Scaling a sprite involves resizing it by specific factors along the x and y axes. Scaling is useful when you want to create different-sized enemies or objects without needing multiple versions of the same sprite. For instance, you might have a boss enemy that’s a larger version of a regular enemy sprite. Scaling can also be used for visual effects, like zooming in on a specific game element or making an object appear closer or farther away. If your game was a target shooting game, you could start with a small-scale sprite making the target appear farther away and then gradually increase the scale, creating the appearance of the object getting closer.

To scale a sprite in Allegro 5, you use the al_draw_scaled_bitmap routine. This routine allows you to stretch or shrink the sprite’s width and height to fit your desired dimensions.

This draws a scaled version of the given bitmap to the target bitmap.

• sx: source x
• sy: source y
• sw: source width
• sh: source height
• dx: destination x
• dy: destination y
• dw: destination width
• dh: destination height
• flags: same as for al_draw_bitmap

In the following code line, the sprite is scaled to twice its original size in both dimensions, as indicated by these parameters in the routine call referencing the destination width and height (dw and dh, respectively):

So in our previous example, we replace:

with:

You may also notice that we are utilizing two other Allegro routines here, al_get_bitmap_width() and al_get_bitmap_height(), in place of simply source width and source height—our previous sh and sw values, respectively.

Why do we want to use al_get_bitmap_width and al_get_bitmap_height? In some of these bitmap manipulation routines, we need to specify information related to the dimensions of the sprite in use. The routines al_get_bitmap_width(sprite) and al_get_bitmap_height(sprite) retrieve the original width and height of the sprite, respectively. These values are crucial because they ensure that you are scaling the sprite based on its actual dimensions. Without these routines, you would need to manually track the sprite’s size, which can lead to errors and inconsistencies, especially if the sprite’s dimensions change during development or if you are working with multiple sprites of varying sizes. As such, we simplify the processes here by getting that information from the sprite being used at that moment.

So going back to our code snippet, it would look like this for a scaled bitmap:

4.2.2. Drawing a Flipped Sprite

Flipping a sprite involves mirroring it across the x- or y-axis. Allegro 5 allows you to flip a sprite horizontally, vertically, or both by using the al_draw_bitmap routine with specific flags. Flipping is particularly useful for character sprites that need to face different directions. For example, a character sprite facing right can be flipped to face left without needing a separate sprite. This is efficient for handling movement in platformers or side-scrolling games. Similarly, flipping can be used to mirror environmental elements or objects (think a reflection in a mirror or water here), adding enhancements to the game world environment without extra resources.

Here, we are utilizing the flags available for the al_draw_bitmap routine, namely:

• ALLEGRO_FLIP_HORIZONTAL: Flip the bitmap about the y-axis
• ALLEGRO_FLIP_VERTICAL: Flip the bitmap about the x-axis

That example flips the sprite horizontally. You can also flip it vertically using ALLEGRO_FLIP_VERTICAL. You can also flip both horizontally and vertically in one function call by combining the flags (ALLEGRO_FLIP_HORIZONTAL | ALLEGRO_FLIP_VERTICAL).

4.2.3. Drawing Rotated Sprites

To rotate a sprite, Allegro 5 provides the al_draw_rotated_bitmap routine. This routine allows you to specify an angle of rotation in radians and the center point around which the sprite will rotate. Rotation is essential for many gameplay mechanics, such as aiming weapons, rotating objects, or handling vehicles like cars or spaceships. For example, in a top-down shooter, the player’s ship might rotate to aim in the direction of the mouse or joystick. Rotation can also be used for environmental elements like rotating platforms or spinning objects:

This draws a rotated version of the given bitmap to the target bitmap. The bitmap is rotated clockwise by the specified angle, measured in radians. The point at cx/cy relative to the upper left corner of the bitmap will be drawn at dx/dy, and the bitmap is rotated around this point. If cx,cy is 0,0, the bitmap will rotate around its upper left corner:

• cx: center x (relative to the bitmap)
• cy: center y (relative to the bitmap)
• dx: destination x
• dy: destination y
• angle: angle by which to rotate (radians)
• flags: same as for al_draw_bitmap

Once again, we look to substitute our code line:

with the new function, and so we might use something like the following:

In this example, the sprite drawn on-screen is now rotated 45 degrees (π / 4 radians) around its center.

Here once more we call some other Allegro routines to get required information, making our coding a bit easier. We are using the al_get_bitmap_width(sprite) / 2 and al_get_bitmap_height(sprite) / 2 routines to make sure we find the center of rotation. These are the center x and center y (cx and cy values). This ensures that the sprite rotates around its center point, which is typically the desired behavior for most game objects. Without these routines, you would need to manually calculate the center based on known dimensions, which is prone to errors and less flexible if the sprite size changes.

4.2.4. Drawing Pivoted Sprites

Pivoting a sprite involves rotating it around a specified pivot point other than its center. Here we still use the al_draw_rotated_bitmap routine. We noted in an earlier chapter the differences between “rotate” and “pivot” as a function of how we define the rotational axis point in our sprite. Pivoted rotation is useful when you want to rotate objects around a specific point, such as a door rotating around its hinge or a windmill’s blades rotating around their base. It adds realism to animations and interactions, making game mechanics more intuitive and visually appealing:

Here, the sprite rotates 45 degrees around its top-left corner (0, 0).

In other cases, you might use the previously studied get width and height routines to help you identify different pivot points. Determining the dimensions of the sprite provides information that allows you to calculate relative positions within the sprite.

For example, you might want to pivot around the sprite’s bottom-right corner by implementing (al_get_bitmap_width(sprite), al_get_bitmap_height(sprite)) in the previous code:

Any of the three previously discussed routines can be substituted in the code example in place of the original al_draw_bitmap(sprite, sprite_x, sprite_y, 0) routine:

4.2.5. Translucent Sprites

We previously covered the concept of transparency in the discussion of the alpha channel and hiding sprite backgrounds with transparency; now let’s look at if we want to modify the sprite itself.

Transparency enables effects such as ghosts, smoke, shadows, and UI overlays and is commonly used for visual cues like stealth, partial invisibility, energy shields, and force fields. To draw a translucent sprite, you can modify its alpha (transparency) value before drawing it. This can be done through the routine al_draw_tinted_bitmap:

Here, the value for ALLEGRO_COLOR tint will be a call to the al_map_rgba_f routine, which will allow us to vary the intensity of the red, green, and blue values, as illustrated in the Allegro documents:

This will draw the bitmap at 50% transparency (the RGB values are premultiplied with the alpha component).

This alpha represents a value where 1 is solid and 0 is transparent. Values between these two numbers then represent the opaqueness or transparency level, so .5 is the 50%.

The concept of a premultiplied alpha is the RGB colour values with the alpha value applied (multiplied by) so A * R, A * G, and A * B, where A would be the same value, so for a half transparent value of 50%, we would have .5 * R, .5 * G and .5 * B or just the 0.5 values seen in the code previously.

Once more using our code snippet as the example, we will replace the basic draw bitmap line with this new routine, resulting in a semitransparent bitmap image:

4.3.1. Program Example—SpriteMoveEffects.c

In the following example, we’ve taken our previous demonstration program and added the following effects:

1. 1. Scaled the saucer size down by 50%
2. 2. Flipped the saucer image horizontally
3. 3. Rotated it 45 degrees clockwise
4. 4. Made the transparency a variable function that oscillates

This numbered list of effects will be referenced in the comments of the code that follows:

A screencap of our semitransparent 45 degree rotated and flipped saucer is shown in figure 4.5.

As you can see, Allegro 5 offers a good selection of functions to modify the colour of screen graphics using various blending functions. These routines can be utilized in a variety of ways to create a more dynamic screen presentation of objects (changing fire intensity, glowing particles, or sparkles), new stylized looks in a scene (changing the palette to pastel shades or using watercolour effects), or immediate visual feedback (a player character glowing after drinking a potion or an indication its been hit by a nonplayer character [NPC] attack).

4.4.1. Using Dynamic Sprites

In the last chapter, we focused on static sprites, which means we worked with a single, unchanging image for each sprite. While we adjusted things like size, orientation, and position, the actual image—what the sprite looked like—stayed the same. We learned how to move the sprite around the screen or change how it appeared, but the sprite’s visual state itself didn’t evolve.

Now, when we talk about more advanced graphics, we introduce the idea of making the sprite’s image change as well. This is where dynamic sprites come into play. Instead of using a single image, we can swap between multiple images to give the impression that the sprite is moving or performing an action. This is what we call animation.

Animation is all about cycling through different images, or frames, to create the illusion of movement. For example, if you have a character walking, instead of just sliding the same image across the screen, we show different frames where the character’s legs are in different positions. By displaying these frames in quick succession, it looks like the character is actually walking.

We can combine this idea of changing the sprite image with the other transformations we already learned—like adjusting its size or position—to create a fully animated and interactive graphic. In the next steps, we’ll explore how to manage these image sequences and control the speed at which they change. This will allow us to create smooth animations, like making a character run, jump, or even perform more complex actions.

So what does animating a sprite mean? It means swapping between a series of images (or frames) over time to simulate movement. And how do we achieve that? We’ll break it down step-by-step, starting with loading multiple frames for a sprite and figuring out how to time their display to create a seamless animation.

4.4.2. Animated Sprites—Drawing an Animated Sprite

The process of how animation occurs in computer systems is the same as it is in video or film or in retrospect static sprite movement. We have a single frame of image information; we display it, then we make some change to that information and display it, repeating the process as needed. For our static sprites, we displayed the same image repeatedly, for animated sprites we want then to display a changed image or better yet multiple changed images.

We will then have multiple sprite images (variations of a base/initial image) that we will play in sequence, giving the static sprite a dynamic, changing appearance. There are many familiar animation scenes in video games that utilize this effect: the player’s character walking, jumping, or running as opposed to standing still; character combat or weapons firing; and vehicles moving or items being destroyed (e.g., in explosions). All these functions can be accomplished with animated sprites.

The basic routine goes like this: You start with an initial sprite image or a frame, borrowing from video/film terminology. Our character begins standing, then in the next image, he lifts a leg somewhat. In the following image, he extends it forward, then he lowers the leg, and finally the character moves up to that location. So in four images, you have a character take a step forward. Since computers like doing things in power of 2, the typical sequence of frames with some intermediate images will be some multiple, such as 4, 8, or 16. We can refer to this collection of images as a “sprite sheet.”

In the context of a classical 8-bit sprite being displayed, we could look at it as 4 different sprite positions displayed while moving the character around the screen, as in figure 4.6, for example.

Now, we have a few choices in terms of the coding to do this. We start with 8 images that need to be displayed in sequence, so an easy process here would be loading and storing our bitmaps into an array, then calling up the indexed image as required. This could get complicated, though, depending on how many bitmaps we have related to the animation complexity and the number of game elements. It would be better to be able to somehow minimize the number of individual images required while keeping them associated with a character or object but still allowing us the animation ability that the multiple modified bitmaps provide. So what if we can combine those 8 images into a single larger image, a sprite sheet. Then the task coding-wise is to select a portion of that single bitmap representing one of the images in the sequence of 8. If one does this, then we only load the sprite sheet image once (as opposed to loading 8 images), and we use the array function to designate a location within the sprite sheet, like the top left and bottom right coordinates of the individual image we want. By making our sizes convenient, like 32 × 32, the math for selection can be very easy to implement.

In the previous example, we illustrated a forward walking motion; however, typically video game characters move in multiple directions. In this respect, your sprite sheet will need to contain multiple rows of sprites, with each row being utilized for a specific direction. Your images, then, might be arranged as four rows of image sequences—up, left, right, and down. If we use 4 images as the minimal number of changes (although there is nothing stopping you from using only 3 or 2 if you really want a minimalist graphics set or for learning), then that gives us a matrix of 16 images arranged in a 4 × 4 layout. Again, if you keep the individual images’ sizes convenient multiples, the math is logical in its implementation. Recall the array from table 4 in the previous chapter, shown again here as table 9, and assume that each sprite image or cell is 32 × 32.

The x- and y-coordinates for the first row of images in terms of top-left corner and bottom right would be [(0,0), (32,32)]; the second cell, then, is [(32,0), (64,32)]; the third cell [(64,0), (96,32)]; and finally [(96,0), (128,32)]. For the second row, then, the first cell is [(0,32), (32,64)], the second cell [(32,32), (64,64)], and so on—easy multiples of 32 to work with (see table 10).

4.4.3. Grabbing Sprite Frames from an Image—the Sprite Sheet

Sprite sheets are a combination of animation frames in a single larger bitmap; we then can load that single bitmap image and ideally select animation frame/areas from that. The process then becomes one of loading a main bitmap, the sprite sheet selecting fixed areas of that (the animation frames), and copying those into the arrays or matrixes for use. Allegro provides us with a function to copy areas of a larger bitmap image al_draw_bitmap_region, and through some clever foreplanning in terms of sizes of the images we create, the math to specify which images to select can become quite easy. If, for example, we have sprite images that are 32 × 32 and we have 4 frames, we combine them to create a main character bitmap that is 128 bits high and 128 bits wide (4 × 32 = 128).

The Allegro 5 function al_draw_bitmap_region is used to draw a specific rectangular region of a bitmap (image) onto the screen. This function is particularly useful when working with sprite sheets, where a single image contains multiple subimages (frames) that represent different parts of an animation or different states of a character:

• sw (source width): The width of the region to draw
• sh (source height): The height of the region to draw
• dx (destination x): The x-coordinate on the screen where the top-left corner of the region will be drawn
• dy (destination y): The y-coordinate on the screen where the top-left corner of the region will be drawn
• flags: Determines how the bitmap is drawn. Common flags include:
  • 0: Normal drawing (no transformations)
  • ALLEGRO_FLIP_HORIZONTAL: Flips the image horizontally
  • ALLEGRO_FLIP_VERTICAL: Flips the image vertically

Let’s go back to our example, the sprite sheet that contains 16 frames in a 4 × 4 grid, where each frame is 32 × 32 pixels. Let’s say you want to draw the third frame in the first row, the one labelled 0,2 in the diagram (frame index 2 in zero-based counting):

Here, you see we’re calculating the sx and sy values based on the frame index and cell size, allowing us to specify that image. In the case of an animation sequence, we can then increment or decrement values to achieve that effect. If we want to go through the animation sequence in the first row, we increment the frame value from 0 to 3; if we want to use a different sequence, we change the row value.

In the simple demonstration program to follow, we’ll use 4 movement animations to go with 4 directions from the keyboard. Pressing the Up, Down, Left, and Right keys changes the character’s direction and updates its position, so we are selecting different sprite images and moving the sprite as well. This means we need 4 animation sets, and it will then fit nicely with our 4 × 4 sprite sheet.

The 4 × 4 sprite sheet layout assumes four rows for movement directions:

• Row 0: Down
• Row 1: Up
• Row 2: Left
• Row 3: Right

For the movement aspect, we then cycle through four frames (columns) for each direction. For our sprite sheet, we’ll use an asset from OpenGameArt.org. One of the things a game designer will need if they aren’t going to create their own graphic and sound assets are open-source graphics and sounds. Many sites can be found that provide these under the auspices of Creative Commons licensing agreements. In many cases, all the artists request is proper acknowledgement of their work as per the applicable Creative Commons licenses, and as a video game designer, you should always seek to attribute and acknowledge the work of others that you have used.

For this example, I’m using the sprite sheet RPG Hero (Walking Cycle) illustrated by Jana Ochse for 2DPIXX and published under a CC BY-SA 3.0 license (see figure 4.6). Many thanks to Jana for providing artwork for those of us lacking the graphical skill to create such necessary and integral assets in our quest to create new games for others to enjoy.

4.4.4. Complete Coding Example

Our result here is the character sprite on-screen changing orientation with respect to the direction it’s moving in and a small animation sequence showing its steps (see figure 4.7). All the graphics required to do this are in the single loaded sprite sheet.

4.4.5. Animated Sprites in Allegro 5

Animated sprites in games have both pros and cons.

1. 2. Better Quality

   Since you’re not limited to the GIF format’s colour palette, you can use full-colour images with higher quality.

2. 3. Performance Optimization

   Sprites can be more efficient, especially when combined with sprite sheets. This reduces the memory footprint and can improve rendering performance.

The choice between using animated GIFs and sprites in Allegro 5 largely depends on your project’s specific needs. If simplicity and ease of use are your primary concerns, you are experienced with utilizing/implementing external libraries, and the limitations of GIFs are acceptable for your project, then using animated GIFs might be the way to go. However, if you need higher-quality animations, more control, and better performance in terms of using routines that already exist in Allegro 5, then implementing animations with sprites is usually the better choice.