[ SDL2 — Part 4] Making things happen

3 min readJan 16, 2022

Making things happen!

Games without any input would be really boring. Actually it wouldn’t be a game at all, just a movie. So let’s look at how we can get input so that the player can actually play the game. But before we do that, we need to take a look at how we do the things updates every frame. ( A frame is a single image of the game, basically each `SDL_RenderPresent(..)` is the end of a frame. )

Previous part

You can find the previous part here.

The game loop

In a game ( and many other applications ) things need to happen over and over again. So you need a big loop that does all of these things. A minimal game loop covers :

Objects needs to be moved
Input handling
Collision detection
….
Rendering

Today we’ll focus on the two first points, we’ll cover collision detection later.

The game loop itself is usually a form of infinite loop :

bool loop = true;while ( loop ) {
    // Do stuff
}

So in order to exit the loop, we need a way of setting the loop bool to false inside the loop. This will make the loop condition ( if ( loop ) ) false and the loop will stop.

Events in SDL2

All events in SDL2 is in the form of an SDL_Event struct. An SDL_Event is a huge structure with tons of member variable with names that generally don’t say a lot about what they’re for. It is used for just about everything ;

Quit event
Mouse events
Keyboard events
Window events( resize, minimize, move, focus, … )
Phone events ( touch, scale, flipping, … )
…And the list goes on…

The type of the event is contained int the .event. This is an enum of the type SDL_EventType If you take a look at the documentation, you’ll see that it has a lot of fields. But to start out, we’ll only look at SDL_Quit and SDL_KeyDown.

Event polling

Now that we know about the SDL_Event, let’s see how we get the event from SDL. The method for doing this is :

int SDL_PollEvent ( SDL_Event* event )

As you can see, it’s pretty straight forward. Just pass it a pointer to a SDL_Event and it will populate the structure. If it returns 0, there are no more events. There could be more than one SDL_Event in each iteration, so we’ll need to put this function in a loop.

bool loop = true;while ( loop ) {
    SDL_Event event;
    while ( SDL_PollEvent( &event ) {
        // Handle events here….
    }
}

SDL_Quit

The first SDL_EventType we’ll be handling is SDL_QUIT. Which occurs when the user quits our game. Either using the x on the top of the window or Alt + F4

bool loop = true;
while ( loop ) {
SDL_Event event;
    while ( SDL_PollEvent( &event ){
        if ( event.type == SDL_QUIT )
            loop = false;
    }
}

And there we go! Now the user can exit the program. Which is rather important…

SDL_KeyDown

Let’s handle a more interesting event. Namely keyboard presses. These have the event type SDL_KeyDown. All possible key presses is stored within the enum called SDL_KeyCode. If you want to see all possible values, you can look at the <a href=”https://wiki.libsdl.org/SDL_Keycode">documentation</a>.

The SDL_KeyCode is stored rather deep withing the SDL_Event at event.key.keysym.symWe won’t dive into the details why it’s stored so many levels down, instead we’ll just focus on the last part, sym which is the actual SDL_KeyCode

Moving things

And now we’ve come to the goal of this part, namely moving something based on user input. Doing this is fairly easy, we already have most code for it. All we need to do is to store the location of what we are trying to move somewhere in an SDL_Rect

We can render a rectangle normally like in the last part and move it around based on user input. We’ll use the following SDL_KeyCode values for movement :

SDLK_LEFT : left arrow key
SDLK_RIGHT : right arrow key
SDLK_UP : up arrow key
SDLK_DOWN : down arrow key

As you can see, the names are very self-explanatory. And moving the item is as simple as incrementing the x and y of the SDL_Rect. So we get

This will handle arrow key presses and move the object accordingly.

Conclusion

And that’s all for this part! As you can see, getting things to move around is fairly simple. In the next part we’ll look at collision detection and end up with something actually resembling a game.

Next part

You can find the next part here.