Chapter 8. Every Pixel Counts – Adding Visual Effects

Throughout the previous chapters, we have constantly been adding functionality. We finally reached a point where our game is playable, where all the game mechanisms are implemented. With a bit of creativity, you should already be able to write your own small game. Nevertheless, we are not going to quit now—a game is more than just gameplay. A very important part of games are the graphics. Be it cutting-edge 3D scenes in the newest real-time strategy game or the nostalgic atmosphere of a pixel-art indie title, graphics determine to a big extent how the player feels.

In this chapter, we are going to look behind the scenes of rendering. We are going to cover various techniques that are used in modern games to create graphical effects of different kinds. To mention a few:

• Texture atlases and how different objects can be stored in one texture

• Texture mapping and vertex arrays

• Particle systems to create effects such as fire or smoke

• Animations that...

Defining texture atlases

A texture atlas describes the concept of a single texture that contains multiple objects. You may also encounter other terms, such as sprite sheet, or tile set in the case of squared tiles put together. Texture atlases allow having fewer image files, which decreases the amount of switches between different textures at runtime. Since texture switching is a rather slow operation on the graphics card, using texture atlases may result in notable speedups. Till now, we used separate textures for each object: one for each aircraft, pick-up, projectile, button, and background. Every texture was stored in its own PNG file. The code design looked as follows:

• Textures were stored inside TextureHolder, our container storing sf::Texture objects.

• We had an enum Textures::ID to identify the different textures in a TextureHolder. By that, we could easily refer to different textures without knowing the actual sf::Texture object or the filename.

• The textures used in the scene were...

Low-level rendering

Besides the high-level convenience classes sf::Sprite, sf::Text and sf::Shape, SFML provides a low-level graphics API which is more complicated to use, but allows more flexibility. In the next section, we are going to look behind the scenes of rendering and discuss corresponding techniques as they are implemented in SFML.

OpenGL and graphics cards

The graphics card architecture consists of many components. Notable are the graphics processing unit (GPU), which performs computations on the graphics card, and the video memory, which stores data such as textures. In contrast to their counterparts CPU and RAM, graphics cards' components are highly optimized to process 2D and 3D graphics.

SFML is built on top of the Open Graphics Library (OpenGL). OpenGL is, like DirectX, a specification of an interface to the graphics card. Operating systems provide an API written in C that allows applications to access graphic card functionality. Newer graphics cards support higher OpenGL versions...

Particle systems

Visual effects such as fire, rain, or smoke have one thing in common: they have a continuously changing nature and cannot be meaningfully described using a single sprite. Even an animated sprite is too limited for many cases, because such effects should come with certain randomness. Fire may have sparks flying in arbitrary directions; smoke may be blown away by the wind.

This is why we need another model to visualize these sorts of effects: particles. A particle is a tiny object that makes up a part of the whole effect; you can imagine it as a small sprite. Each particle by itself looks boring, only in combination do they lead to an emergent visual pattern such as fire.

A particle system is a component that manages the behavior of many particles to form the desired effect. Emitters continuously create new particles and add them to the system. Affectors affect existing particles with respect to motion, fade-out, scaling, and many other properties.

Given a particle texture...

Animated sprites

Alright, now we have got particles, let's accompany them with an animated explosion. So far our aircraft have just disappeared when you shot them down. That's not satisfying. When you destroy something like an aircraft, you expect a huge explosion, don't you?

We already had a look at texture rectangles and sprite sheets. This knowledge will be used to build our animation. An animation consists of several frames, and we represent these frames as separate rectangles inside one larger texture, similar to what we now do with entities. Do not confuse animation frames with the game loop frames—the former represents just a state of an animation, which usually lasts for many game loop iterations.

This is the sprite sheet we use for the animation. How does it work? As time elapses, we move the texture rect from one frame to the other, until the animation is finished.

We do not define the animation class as a scene node but only as a drawable and a transformable object. It can then...

Post effects and shaders

You know those big budget games with dedicated graphics programmers on them? One of the techniques they use is something called post rendering or post effects. It's an effect that is applied after the scene has already been rendered. Using that data, we perform whatever visual effect we want on it. One way to create effects is using shaders, which we will delve into later.

The first thing to cover is how to perform a post effect, how it works, and then we will actually create an effect called bloom using shaders.

Fullscreen post effects

Well, the effect has to be applied to the whole screen, otherwise it is pretty useless. That is why we define a specific PostEffect class in order to make this a bit easier.

class PostEffect
{
    public:
        virtual            ~PostEffect();
        virtual void       apply(const sf::RenderTexture& input,sf::RenderTarget& output) = 0;

        static bool        isSupported();

    protected:
        static void       ...

Summary

Meanwhile, our aircraft shooter now deserves the name "game", as it is no longer some half-hearted sprites put together. We have seen a lot of modern graphical and rendering techniques and how they fit in our game. After an in-depth look at the rendering process (render targets, textures, vertices), we integrated a particle system for the missile, an animation for the explosion, and a shader for the bloom effect on the whole scene.

Note that there exist already implementations for many of the techniques shown in this chapter. In case you don't want to reinvent the wheel, you could have a look at the Thor library, which is developed by one of the authors of this book. Thor extends SFML by providing fully configurable particle systems and animations. Other features include color gradients, input and resource handlers, timer utilities, and much more. The library is available at www.bromeon.ch/libraries/thor.

In the next chapter we will cover how to play audio using SFML's Audio module...