next up previous contents index
Next: main Up: main Previous: main   Contents   Index

startsection subsection20in-0.25Processing Mouse Events The mouse is a fairly simple input device. A mouse (or trackball) reports changes in its position with respect to a fixed unit of measure. For instance, a movement of 1 inch forward and 2 inches to the left (with respect to the mousepad) might correspond to 400 vertical mouse units and horizontal units. These units are called mickeys, and their exact meaning varies from mouse to mouse. It is important to realize that, at the lowest level, the mouse has no concept of the screen area or the pointer; it simply measures relative motion.

The code listing that follows demonstrates simple mouse event processing with the SDL event interface.

Code Listing 6.-8 (mouse-events-sdl.c)  

This program begins exactly as one of our early SDL video examples did. In fact, it is one of our early video examples, minus the drawing code. We need to open a window in order to receive events, but the window's contents are inconsequential. Once the window is open, the program kicks off the event loops and begins to monitor the mouse.

Suppose that the user quickly moves the mouse from the coordinates (10,10) to (25,30), relative to the position of the window. SDL would report this as an SDL_MOUSEMOTION event. The event structure's motion.x and motion.y fields would contain 25 and 30, respectively. The xrel and yrel fields would contain 15 and 20, since the mouse traveled 15 pixels to the right and 20 down. It is possible that this motion would be broken into two or more mouse events (depending on the speed at which the user moved the mouse, among other things), but this can be dealt with by averaging mouse motion over several animation frames.

SDL's event-processing model is sufficient in most cases, but sometimes a program simply needs to know the current position of the mouse, regardless of how it got there. Programs can bypass the event interface entirely with the SDL_GetMouseState function. Unfortunately, this function does not automatically read the mouse's current state; it simply reports the most recently read coordinates. If you choose to bypass the event system, you must call the SDL_PumpEvents function periodically to ensure that your program receives up-to-date input device information.

Warning
SDL's event processing is not completely thread-safe. In particular, functions that collect new input (SDL_PollEvent, SDL_WaitEvent, and SDL_PumpEvents) should be called only from the thread that originally set the video mode (with SDL_SetVideoMode). However, it is safe to call the SDL_PeepEvents function (not discussed here) from another thread.

It's possible to have SDL set up a completely separate event-processing thread, but this is only partially implemented and generally unportable. Your best bet is to handle input processing in your game's main thread.


next up previous contents index
Next: main Up: main Previous: main   Contents   Index
Mika Myllynen 2003-02-19