Simple DirectMedia Layer 2.0


To fit the image properly, you need to tell the SDL_RenderCopy() function the size of the texture, as well as the position of the upper left corner of the image in the window. SDL_RenderCopy() expects this information as an SDL_Rect.

This data structure simply encapsulates the dimensions of a rectangle. In other words, SDL_RECT pos; first draws a rectangle. SDL counts the pixels from the left upper corner of the window, starting at 0. In this example, I want the upper-left corner of the texture to be 150 pixels from the left edge of the window and 100 pixels from the top edge of the window. These two numbers are stored in the variables x and y:

pos.x = 150;
pos.y = 100;

To define the width and height of the texture window, you use the pos.w and pos.h variables. To avoid texture distortion by the renderer, you thus assign the width and height of the texture to it. You can either painstakingly use a paint program to discover these two values, or you can use the SDL_QueryTexture() function:

SDL_QueryTexture(texture, NULL, NULL, &pos.w, &pos.h);

This returns the pixel format (RGB, YUV, or similar), a pointer to the actual bitmap in memory, and the width and height of the texture. This information is no longer of interest, which is why SDL_QueryTexture() keeps it to itself, thanks to the two NULLs.

At this point, pos contains the position and size that the renderer will use to paint the texture in the window. You only need to pass a pointer to pos to SDL_RenderCopy():

SDL_RenderCopy(renderer, texture, NULL,&pos);

The results are shown in Figure 4. Using the same principle, you can then draw more textures in the window. The renderer draws the first textures copied first. In the following example,

SDL_RenderCopy(renderer, rear, NULL,NULL);
SDL_RenderCopy(renderer, front, NULL, NULL);

the renderer would first paint the rear texture in the window and then glue the front texture on top. At the end of the code, you need to tell the renderer to display the updated window contents:


This last step only seems superfluous at first glance: If the renderer directly output every drawing action in the window, you would be able to see how the image was built up from individual textures. The result would be ugly, flickering animations.

Figure 4: After passing the dimensions and the position of the texture to SDL_RenderCopy(), the logo is finally displayed correctly.

Bus Stop

If you were to put together the code snippets as a program and launch it, you would briefly see a window appear and immediately disappear. To prevent that, you could stop the program just for two seconds:


However, a more elegant approach is to allow the user to quit by pressing a key, clicking on the window, or pressing the close button in the title bar. From this point on, SDL 1.2 users will be back on familiar ground: Keystrokes, mouse clicks, and other inputs are events in SDL.

Please Wait

Each event first ends up in a queue. The next event in the queue is retrieved by the SDL_WaitEvent() function. If the queue is empty, SDL_WaitEvent() waits until an event occurs. Then, you only need to query what event is occurring. The resulting switch/case monster is shown in Listing 1.

Listing 1

Event Handling in SDL


The helper variable quit only indicates whether the end of the program has been reached. SDL_WaitEvent() picks up the next event from the queue and puts it into a data structure of the SDL_Event type. The structure stores the event type in a variable named type. If the user presses a key, type has a value of SDL_KEYDOWN. The myevent.key.keysym.scancode event variables reveal what key this was. The key number is translated by SDL_GetScancodeName() into the corresponding letter or the label.

Because the keyboard on any given system will tend to differ, SDL assigns a symbolic name to each key, which is stored in the myevent.key.keysym.sym variable. The SDL_GetKeyName() function converts this to a readable result (Figure 5). An SDL_MOUSEBUTTONDOWN type event is created if the user clicks on the window. The mouse pointer coordinates are stored in the variables myevent.motion.x and myevent.motion.y. A game would evaluate these coordinates and check which game object lies below them.

Figure 5: In this example, the user has pressed the semicolon on the (;) keyboard. The programmer should always evaluate the virtual key codes to the extent possible.

The user triggers the SDL_QUIT event on quitting the program. In addition to the three cases presented, SDL supports many more events [4]. For example, if the user releases a key, this triggers an SDL_KEYUP event.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content


    Red Hat’s head of X development describes the evolution of AIGLX.

  • Tcl3D

    Tcl3D brings the world of 3D effects to TCL scripting. We’ll show you how to get started with building your own 3D scripts.

  • Pi Flight Simulator

    A Raspberry Pi 4B with Linux can solve the equations for a real-time nonlinear aircraft simulation, including the emulation of modern aircraft flight displays.

  • Xgl and Compiz

    A member of Suse’s X11 team delivers an insider’s look at Xgl.

  • Playful Progress: Blender 2.49 Enhances Game Engine and Panoramic View

    Blender 2.49 is still profiting from its experience developing Big Buck Bunny and the Yo Frankie! Blender game. Much of what goes into the new release is on account of the Game Engine, with its video integration and performance boost.

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More