In this lesson, we'll explore SDL's window management system, learning how to create, configure, and respond to window events.
We'll cover essential concepts like window creation, error handling, and event processing, providing the foundation needed to build robust windowed applications.
Previously, we’ve seen how we can retrieve aspects of our window’s configuration by checking its window flags. However, we don’t need to continuously monitor our SDL_Window
to understand its state.
For most use cases, monitoring the event loop makes more sense. SDL dispatches a wide variety of events reporting actions performed on our window. In this lesson, we’ll explore this in a bit more detail.
In this lesson, we'll explore SDL's window positioning capabilities, from setting initial window locations to handling dynamic repositioning. We’ll cover
This lesson explores the tools SDL2 offers for controlling window sizes and responding to changes. We’ll cover:
In this lesson, we’ll continue exploring window management with SDL2, focusing on visibility. We’ll cover:
SDL2 provides tools for controlling mouse movement in our applications. In this lesson, we'll explore how to constrain the mouse cursor to specific windows and regions, giving you precise control over user input. Key topics covered:
SDL_WINDOW_MOUSE_GRABBED
SDL_SetWindowMouseGrab
SDL_SetWindowMouseRect
So far, our example programs have been using the mouse to control a pointer within our window, letting users point and click on UI elements. However, many programs, especially first-person games, use the mouse differently. For example:
The first step of implementing any application is writing the foundational code that keeps the program running until we or the user decide it’s time to quit. This code is often called the application loop, main loop, or, if we’re making a game, the game loop.
Typically, every iteration of the loop involves 3 steps:
On most platforms, multiple applications can be open at once. However, when the user is providing input on their keyboard, they typically only intend to provide that input to one of the open applications.
Users can select which application is active by, for example, clicking within its window.
Operating systems typically apply more vibrant styling to the active window. In the following example, the left window is inactive, while the right is active.
Accordingly, the user will not expect the left window to react to keyboard events, as their input is likely intended for the right window instead:
In desktop environments, users can have multiple windows open at once. On most platforms, only a single window can have input focus at a time, which is typically gained by the user clicking on the window:
This is referred to as input focus, and we covered it in more detail in our earlier lesson on keyboard input:
In this lesson, we’ll introduce the related concept of mouse focus. A window has mouse focus if the user’s pointer is currently hovering over it. The window with mouse focus is not necessarily the same as the window with input focus.