Chapter 3.3 Using Graphics in Games

3.2.1. Bitmap Creation Tools

The game developer has a wide variety of tools and sources to acquire and create graphics utilized in game development. These range from self-developed graphics, to open-source and public domain works one could download, to purchasable artist-created graphical elements. Here, we’ll talk briefly about some of the available options very generally, as they can vary greatly over time and depending on the manufacturer and operating systems used.

Images for use as bitmaps can be drawn, captured, or generated depending on the tools utilized. Most computer systems come with some form of simple graphical drawing program or image display/manipulation program. These programs may let you create stand-alone drawings, such as a Paint-type drawing package, or annotate/manipulate preexisting graphics like photographs.

After creation or modification, those items can then often be saved in differing graphics formats such as .jpg, .bmp, or .png. In the software used for working on images, there typically are functions that can transform the image via, for example, rotating, scaling, changing the number of colours (altering the bitmap colour depth—we’ll talk about this later), or perhaps applying other effects. It is through the use of such tools that the game developer can often create the graphical elements required for their games, such as backgrounds and other in-game objects.

Game developers can also search online for more powerful, free open-source graphical tools to use in the development of their games. These can range from graphical editing programs such as GIMP to artificial intelligence image producers such as DALL-E. With these tools a game developer can create their own graphics for development use.

3.2.2. Creating Bitmaps

As noted, one can often use the simple graphics tools that come with a system to create required bitmaps. Let’s say I want to create a game about cats exploring space. I’ll call it the Cat Astronaut Training Simulator, or CATS for short. The game will have a background of outer space, and for that, I’ll use a star field photograph I’ve taken. The size of the images from my camera, resolution-wise, is 3008 × 2000, 24-bit colour, and the file size is 3 MB, so I’ll want to shrink it down to, say, 1024 × 768 and perhaps reduce the colour depth to make it a smaller image.

3.2.3. Supported Bitmap Formats

One of the first questions you might ask at this point is, What does Allegro support for graphics in terms of formats? The choice of format will depend on the specific requirements of the application, such as the desired resolution, colour depth, and level of compression (to save on file space for your resources . . .). Here, the Allegro 5 development library supports a good variety of graphics formats, providing the developer with a wide selection.

Note that to use the bitmap graphics, we need to use another one of Allegro’s many add-ons. Here, for the purpose of graphics, it’s the image handling add-on, so in any program, we would include:

And initialize that with:

Here is a brief overview of the supported graphics formats and their features:

• BMP (Bitmap): BMP is a raster graphics format that is commonly used for images and animations. It supports a wide range of resolutions and colour depths, making it a versatile choice for game development.
• PNG (Portable Network Graphics): PNG is a lossless image format that is widely used for web and mobile applications. It supports transparency, which allows for the creation of images with transparent backgrounds.
• JPEG (Joint Photographic Experts Group): JPEG is a widely used lossy image format that is commonly used for photographs and other high-quality images. It supports high compression ratios, making it a good choice for applications where file size is a concern.
• GIF (Graphics Interchange Format): GIF is an animated image format that is commonly used for web and mobile applications. It supports animation, which allows for the creation of moving images.
• TGA (True Colour Graphics): TGA is a lossless image format that is commonly used for professional applications. It supports high colour depths and is well suited for applications that require high-quality images.

The supported colour depths and resolutions for bitmaps are:

• • 8-bit greyscale (1 colour)
• • 16-bit greyscale (256 colours)
• • 24-bit colour (16 million colours)
• • 32-bit colour (4,294,967,296 colours)

The 32-bit colour depth is quite impressive but probably seldom used. (From the human perspective, could one even tell 4 billion colour differences from 16 million? And would the file size increase be worth it?)

Allegro 5 supports a wide range of screen resolutions as well. Here is a list of some of the commonly used screen resolutions that Allegro 5 supports:

• • 1920 × 1080 (Full HD)
• • 1600 × 900
• • 1366 × 768
• • 1280 × 720 (HD)
• • 1024 × 768
• • 800 × 600
• • 640 × 480
• • 512 × 384
• • 400 × 300
• • 320 × 240

Note that this is not an exhaustive list; Allegro 5 may support other screen resolutions as well.

3.2.4. Bitmap Information

In every operating system you might use, there will be a way to determine the information for an image, details one will need to know to utilize graphics in their game programs. If you’ve initialized your game to the wrong screen size or wrong colour depth, your graphics will not display properly. As such, it’s prudent to find out that information before implementing a graphical object in your program to avoid errors, since Allegro will load your image fine and not generate an error, but when displayed, you won’t see anything. This situation often leads one to believe that they have an error in their code, but it’s actually a problem with the source image. Improper colour depth can also spoil the look of your game. For example, a 24-bit image rendered in 8-bit will look nothing like the original, losing both resolution and colour variation.

For this example, we will leave the colour depth at 24 but reduce the image size to 1024 × 768. I’m on a Windows 10 system, and so I can use the Photos program that comes with the system. The original image is in a .jpg format, 3008 × 2000, and 3 MB in size. To start with, I want to resize it and then convert it to a bitmap format (.bmp). In the Photos program, under the resize option, when I change the image size to 1024 × 768, it sets the height to 681 to maintain the aspect ratio. I’ll live with that and see how it looks in the demo program, so I select the “save as” function to export the image as CatCosmos.bmp. The file size is now reduced somewhat to 2.75 MB (see figure 3.3).

3.2.5. Choices, Choices . . .

Let’s talk a bit about file types here: the pros and cons of JPEGs and bitmaps. Allegro’s library can handle both formats, but its strength lies in using bitmaps. Bitmaps and JPEGs are both image file formats, but they have some key differences that can affect their performance and usage in certain situations. Here are five potential advantages of using bitmaps over JPEGs; the last three points listed are key for our needs as game developers:

• Higher Resolution: Bitmaps are typically used for images that require high resolution, such as logos, icons, and other graphical elements. Bitmaps can have a higher resolution than JPEGs, which means they can display more pixels per inch (PPI) and provide a clearer, sharper image.
• Lossless Compression: Bitmaps use lossless compression, which means that the original image data is preserved during compression. This is important for images that need to be edited or manipulated in the future, as the original data can be restored without any loss of quality. JPEGs, however, use lossy compression, which means that some of the original data is discarded during compression, and the resulting image may not be as sharp or detailed as the original.
• Transparency: Bitmaps can support transparency, which means that certain parts of the image can be made transparent or semitransparent. This is useful for creating images with overlays or other visual effects that require transparency. JPEGs do not support transparency.
• Flexibility: Bitmaps can be used in a variety of contexts, including web design, graphic design, and game development. They can be scaled up or down to different sizes without losing quality, and they can be used in a variety of software applications. JPEGs are primarily used for web images and are not as versatile as bitmaps.
• Smaller File Size: Bitmaps can be smaller in file size than JPEGs, especially in images that do not require high resolution or complex colour schemes. This is because bitmaps use a different compression algorithm than JPEGs, which allows them to use fewer bits per pixel and results in smaller file sizes. However, this comes at the cost of lower resolution and less detail in the image.

3.3.1. Loading Bitmaps

To use graphics in programs, we will call various routines in the Allegro 5 library. To load a bitmap in Allegro 5, we will use the al_load_bitmap routine. To load a 24-bit colour image like the one we created previously, CatCosmos.bmp, you would call

Here, ALLEGRO_BITMAP is a struct, a custom container representing the bitmap image, and *image is our pointer to the routine call, along with our filename. A short program to display the image follows: BitmapDisplay.c.

3.3.2. Complete Coding Example

3.3.3. Manipulating Bitmap Images

While you can manipulate bitmap images in external graphic programs, as we have mentioned previously, you can also do some basic image transformations using the Allegro library on a loaded image in your program.

There are two other transformations—scaling (or changing an image’s size) and rotating (changing the orientation of the displayed image). Allegro provides a few routines representing variations and combinations of those, along with incorporating tinting, so we have:

• • al_draw_scaled_bitmap
• • al_draw_rotated_bitmap
• • al_draw_tinted_bitmap
• • al_draw_scaled_rotated_bitmap
• • al_draw_tinted_scaled_bitmap
• • al_draw_tinted_rotated_bitmap
• • al_draw_tinted_scaled_rotated_bitmap

We’ll just consider the base routine calls (scaled, rotated, and tinted) here, as the combined routines simply add parameters from those base calls.

3.4.1. Complete Coding Example

3.4.2. Bitmap Colour Manipulation

On to our last base routine: al_draw_tinted_bitmap. Its purpose is to create the ability to “highlight” a specific colour in the bitmap (red, green, blue) by multiplying all colours in the bitmap with the highlight colour. The routine also allows for setting the opacity of the bitmap from solid to transparent. While changing the transparency of a bitmap image in your game may not seem useful immediately, it is a handy function for visual effects when utilized with sprites in games (an example could be of a game character that gets “zapped” by a laser and then disintegrates—fades away, a change in transparency). In relation to the background, perhaps as you change scenes, you might fade out from one and fade into the next. The routine’s structure is:

The “tint value” we’re talking about comes from the ALLEGRO_COLOR that you create with the routine al_map_rgba_f(float r, float g, float b, float a). This routine takes four floating-point numbers (each between 0 and 1) representing the red, green, blue, and alpha (transparency) channels, respectively. Here is an example:

In this case, you’re drawing the bitmap with full intensity on the red, green, and blue channels (that’s what the 1’s mean), but the alpha value is set to 0.5. This results in the bitmap being rendered at 50% transparency.

Another example is:

Here, the tint is specified to use only the red component (1 for red, 0 for green, 0 for blue) while keeping full opacity (alpha is 1). This means the bitmap gets tinted red.

So essentially, by adjusting the values you pass to al_map_rgba_f, you control both the transparency and the colour tint applied to your bitmap when you draw it.

3.5.1. Example Program DisplayMap.c

3.5.2. Program Overview

There is a lot going on in this next example: We’re loading a bitmap; magnifying a section of it, which is selected by a moving window; and displaying that in a window on the main bitmap display. As such, let’s go through it in more detail.

3.6.1. Resolution Independence

Resolution independence refers to the ability of a software application to run on displays of different resolutions without losing quality or functionality. In Allegro 5, achieving resolution independence involves scaling graphics and user interface elements dynamically based on the screen’s resolution. This ensures that the application looks consistent and sharp across various devices. The typical approach to this is to utilize routines to query the platform the device is running on for display information and then assign those values to appropriate variables in your program—for example, screen_width and screen_height. This looks something like:

After that, one would optimize routines for screen coordinates to work with the returned information. This can prove to be a complex process if you’re wanting to work with a variety of screen sizes, keep aspect ratios, and so on.

In Allegro 5, one can use transformations to dynamically adapt one’s code to the current system’s screen resolution. By using a transformation that considers screen resolution, you can ensure that graphics scale properly and dynamically. This would be implemented utilizing the following library functions:

where scaleX and scaleY are the scaling factors for width and height (respectively) that take into account the commonly used screen_width and screen_height information:

But we’re a bit ahead of ourselves here, as we haven’t explained transformations. In Allegro 5, these are routines used to modify the position, scale, rotation, and other properties of graphical objects in a 2D space. These effects can be applied to multiple bitmap objects at once, alleviating the need to otherwise perform those actions individually per bitmap object.

Transformations are used extensively in game development and graphics programming. They allow for dynamic object movement, animations, camera movement, and more. For instance, in a platformer game, transformations are used to move characters, enemies, and the camera that follows the player. As such, transformations in Allegro 5 are powerful tools that allow developers to manipulate graphics in 2D space. They are essential for creating dynamic, interactive, and visually appealing applications. By understanding and using translation, scaling, and rotation, and combining these transformations effectively, developers can greatly enhance the visual quality and interactivity of their Allegro 5 projects.

3.6.2. Types of Transformations

Looking at the list of transformation routines here, you’ll note that the first three have equivalent routines to some of the earlier bitmap manipulation operations:

• Translation (Moving Objects): This changes the position of an object in the 2D space. For example, moving an object from one location to another.
• Scaling (Resizing Objects): Scaling either increases or decreases the size of an object. This can be uniform (keeping the aspect ratio the same) or nonuniform (changing the width and height by different amounts).
• Rotation (Spinning Objects): This involves rotating an object around a point, typically its center. Rotation is usually measured in degrees or radians.
• Shearing: Shearing is a less commonly used transformation that skews the shape of an object.

Let’s consider scaling. Using transformations in Allegro 5 (such as al_rotate_transform), vs. relying on simpler drawing commands like al_draw_rotated_bitmap, comes down to flexibility, performance, and ease of applying multiple transformations at once.

Here’s a breakdown of why you might prefer one over the other:

1. 1. Flexibility with Multiple Transformations
   • Using al_rotate_transform and the transformation matrix (ALLEGRO_TRANSFORM)

     If you need to apply multiple transformations together (e.g., rotation, scaling, and translation), a transformation matrix allows you to combine all transformations before drawing.

     Example: You can scale, rotate, and translate an object in a single transformation rather than doing them separately with different routines.

   • Using al_draw_rotated_bitmap

     This routine is simpler but only rotates around a specific point when drawing.

     If you need additional transformations, like scaling or skewing, you cannot do that easily with al_draw_rotated_bitmap.

2. 2. Performance Considerations
   • Using al_draw_rotated_bitmap

     This is optimized for performance when all you need is rotation.

     The routine is simpler and faster if you don’t need complex transformations.

     It’s great for simple sprite rotation, such as rotating a spaceship or a top-down character.

   • Using al_rotate_transform

     If you apply multiple transformations, using a transformation matrix is often more efficient than applying multiple individual drawing operations.

     It reduces redundant calculations since transformations can be precomputed and reused.

3. 3. Transforming the Entire Scene vs. Individual Objects
   • Using al_use_transform with al_rotate_transform

     If you need to apply transformations to the entire coordinate system, using al_use_transform allows all subsequent drawing operations to inherit the transformation.

     Example: If you want to rotate everything in a scene (like a rotating camera view), a transformation matrix is the correct approach.

   • Using al_draw_rotated_bitmap

     If you only need to rotate one object while keeping everything else unchanged, al_draw_rotated_bitmap is easier.

4. 4. Example Comparisons
   • Using al_draw_rotated_bitmap (Simpler, Object-Specific)

   ALLEGRO_BITMAP *sprite = al_load_bitmap("sprite.png");

   float x = 200, y = 200; // Position on-screen

   float angle = ALLEGRO_PI / 4; // Rotate 45 degrees

   float cx = al_get_bitmap_width(sprite) / 2.0;

   float cy = al_get_bitmap_height(sprite) / 2.0;

   al_draw_rotated_bitmap(sprite, cx, cy, x, y, angle, 0);

   This rotates only one bitmap at a time. It’s good for rotating sprites but not for complex transformations.

   • Using al_rotate_transform with al_use_transform (More Advanced, Affects All Drawing)

   ALLEGRO_TRANSFORM transform;

   al_identity_transform(&transform);

   al_translate_transform(&transform,—100,—100); // Move pivot point

   al_rotate_transform(&transform, ALLEGRO_PI / 4); // Rotate 45 degrees

   al_translate_transform(&transform, 100, 100); // Move back

   al_use_transform(&transform);

   al_draw_bitmap(sprite, 200, 200, 0);

   This approach affects all drawing commands after al_use_transform(). It’s useful for scene-wide effects or handling multiple transformations at once.

   As you can see, transforms are useful for more complex operations and can affect a whole screen view, which brings us back to why we might want to use them to achieve display resolution independence in our games.

3.7.1. Scaling the Entire Scene

By using al_scale_transform(), you can make the coordinate system of your game match the target resolution dynamically. This means that drawing at coordinates (100,100) on a small window will appear in the same relative position on a larger window.

The following code sample scales from a base resolution of 800 × 600 to fit any screen size:

So here in this code segment, if the display size of the platform running the code is 1600 × 1200, the values supplied to the transform would be scale_x = 2 and scale_y = 2, meaning everything is doubled in size.

Conversely, if the screen is 400 × 300 (like on a small mobile device platform), the calculated values of scale_x = 0.5 and scale_y = 0.5 would be applied, meaning everything is shrunk to fit. As a result, all your drawing code remains the same regardless of screen size.

3.7.2. Centering the Game on Any Screen Size

If you scale up or down based on resolution, sometimes you also need to center your game. This can be done by translating the coordinate system.

Example: Centering the Scaled Content

Here, the code ensures that even if the screen is wider or taller than your base resolution, your game remains centered.

3.7.3. Using Logical Coordinates

To abstract your code if you don’t have a specific resolution in mind, sometimes the best approach, instead of working directly with pixels, is to define a virtual resolution (e.g., 800 × 600) and scale everything accordingly. By utilizing this process, you let the game engine/software scale the game screen dynamically to fit the current display screen. The advantages of this method include maintaining the aspect ratio of the screen, better performance optimization and smoother-looking graphics when utilizing antialiasing, and simply keeping game items like the user interface (UI) consistent proportionally to avoid distortions or difficulties reading text.

Example

So here, all drawing routines use a consistent coordinate system based on VIRTUAL_WIDTH and VIRTUAL_HEIGHT. If you always draw and place objects using your base resolution (e.g., 800 × 600), then no matter what resolution the player uses, everything will be resized properly.

If you look at table 8, you’ll see the benefits of using transformations vs. needing to hand tweak your code for multiple displays (not to mention the fact that a programmer might miss incorporating the multitude of resolutions out there these days).

3.7.4. Summing Up How Transformations Work in Allegro 5

Understanding transformations in Allegro 5 is all about working with an ALLEGRO_TRANSFORM object to change how graphics are drawn. The process begins with creating and initializing this object using al_identity_transform, setting it up with the identity matrix. From there, you can move objects around by translating them with al_translate_transform or resize them while keeping their aspect ratios intact using al_scale_transform. If you need to rotate objects, you can use al_rotate_transform to set a specific angle.

One of the cool things about Allegro 5 is that you can combine multiple transformations in sequence. Once you have your transformations set up just the way you want them, you make it the current transformation for drawing operations with al_use_transform.

A couple of examples might help to clarify things. You might use scaling and centering to maintain the aspect ratio or set up a basic transformation by creating and applying it in a straightforward manner. Overall, transformations are a key part of effectively positioning, resizing, and rotating graphics within Allegro 5.

3.7.5. Creating and Setting a Transformation

Before applying a transformation, you first create an ALLEGRO_TRANSFORM object and then apply various transformation operations to it. After setting up the transformation, you make it the current transformation for drawing operations.

Here’s an example of how to create and set a basic transformation:

Transformations can be combined to produce more complex effects. For example, you might want to rotate an object around a point other than its center, scale it, and then move it. The order of transformations is crucial as it affects the final result.

3.7.6. Order of Transformations

The typical order of transformations for achieving a common effect (like rotating an object around its center and then moving it) is:

1. 1. Translate the object to the origin (0,0).
2. 2. Perform the rotation.
3. 3. Scale if necessary.
4. 4. Translate the object to its intended position.

When we use a transformation matrix to modify drawing operations, we typically follow these steps.

3.8.1. Explanation

Here, we’ll take a brief look at some Allegro routines that can be applied to improve the look of your graphics and to utilize the graphics processing unit (GPU) on your graphics cards for increased performance.

Antialiasing is a technique used to reduce the visual defects (like jagged edges) that occur when high-resolution images are displayed in a lower resolution. Texture smoothing refers to the process of blending the colours of an image’s pixels to create a smoother transition between them.

3.8.2. Allegro 5 Implementation

In Allegro 5, you enable antialiasing and texture smoothing through the use of bitmap flags and settings in the graphics library.

These flags tell Allegro to use linear filtering for minification and magnification, which results in smoother textures.

In Allegro 5, both antialiasing and texture smoothing are important for creating more visually appealing and polished graphics in your applications.

3.8.3. Antialiasing

Antialiasing is used to reduce the jagged edges that can appear on diagonal or curved lines in digital images, a phenomenon often referred to as “aliasing.” This effect is especially noticeable in lower-resolution graphics or when scaling images up or down.

In Allegro 5, antialiasing can be applied in several ways, but one of the most common methods is through the use of multisampling. Multisampling works by taking multiple samples at different points within each pixel and then averaging these samples to determine the pixel’s colour. This process smooths out the edges of lines and curves.

3.8.4. Texture Smoothing

Texture smoothing, also known as filtering, is used to improve the appearance of textures when they are scaled or transformed. Without texture smoothing, textures can appear pixelated or blocky, especially when magnified.

In Allegro 5, texture smoothing is typically achieved through linear filtering. Linear filtering works by interpolating the colours of neighboring pixels to calculate the colour of a pixel when a texture is scaled. This results in a smoother transition between pixels.

3.9.1. Allegro 5 Implementation

Allegro 5 supports GLSL (OpenGL Shading Language) shaders. You can load and use shaders to affect rendering in your application:

3.9.2. Shaders and Their Use in Allegro 5

3.10.1. Advantages of Premultiplied Alpha

When working with transparency and blending in graphics programming, especially in game development using Allegro 5, the choice between straight alpha and premultiplied alpha can significantly affect both visual quality and performance. Premultiplied alpha offers several practical advantages:

• Simpler Blending Equations: With RGB values already scaled by alpha, blending calculations become more straightforward, often leading to better performance and fewer rendering artifacts.
• Better Handling of Semitransparent Pixels: Premultiplied alpha reduces visual artifacts around the edges of semitransparent textures, such as halos or dark fringes.
• Improved Overlapping Transparency: It ensures more predictable blending behavior when multiple transparent objects overlap, avoiding darkening or incorrect blending effects.

3.10.2. Using Premultiplied Alpha in Allegro 5

To use premultiplied alpha in Allegro 5, follow these steps:

1. 1. Prepare Images with Premultiplied Alpha

   Ensure that the RGB values in your image are premultiplied by the alpha channel. This can be done in image editing software or programmatically.

2. 2. Set the Correct Blender

   Use the following Allegro 5 function to set the blending mode:

      al_set_blender(ALLEGRO_ADD, ALLEGRO_ALPHA, ALLEGRO_INVERSE_ALPHA);

   • ALLEGRO_ADD: Adds source and destination colours.
   • ALLEGRO_ALPHA: Uses the source’s alpha channel.
   • ALLEGRO_INVERSE_ALPHA: Uses the inverse of the source’s alpha.
3. 3. Draw Your Images

   After setting the blender, draw your images as usual. Allegro will apply premultiplied alpha blending to all subsequent drawing operations.

Example

This example assumes the bitmap has premultiplied alpha. The al_set_blender routine configures the correct blending mode. More details on Allegro 5 blending modes will be covered in the next chapter.