SDL Bug wrt. mouse focus?

We have basically finished the GUI subsystem of the game. However, when writing the Code to handle the mouse pointer leaving the application window (for example, to remove the hovering state of a widget near the window border) I investigated a problem which I think is a bug in SDL.

When clicking into a different window, holding the mouse button pressed, moving the cursor into our SDL window and release the mouse button there, then we don't get an SDL_ACTIVEEVENT which reports gained mouse focus for the window. This is OK as long as the mouse button is pressed, since all mouse events are still delivered to the originating window then.

The problem with this is that when querying the application state via SDL_GetAppState, SDL still reports the window not having mouse focus until the mouse leaves and enters the window again. This confuses our code since there are some checks for the application having mouse focus before e.g. setting a button's state to be hovered by the mouse.

There is a quite easy workaround for the problem:

SDL_WM_GrabInput(SDL_GRAB_ON);
SDL_WM_GrabInput(SDL_GRAB_OFF);

This is executed whenever the mouse moves over our window or it is clicked and SDL reports that we don't have mouse focus. In this case we can be quite sure that the mouse actually is over our window, so the mouse grab does not warp the mouse cursor. However, this causes SDL to update the application's mouse focus state.

There is still a little issue with this: When the mouse button is released over a button, the the button is not shown hovered until the next mouse click or movement, since the application state is only rechecked on these two events. However, that's not a major problem, and we can live with it.

I am not yet sure whether there is the same problem on Windows, but I have tested it using GNOME with the Metacity window manager. Anyway, as a good net citizen I filed a proper bug report.

Composing images of multiple textures

For the curious: The game is developed with SDL using OpenGL for graphics output and will support all three major platforms: Windows, Linux and Mac OS X.

Yesterday, I wrote a class to load arbitrary-sized images into possibly multiple textures none of which is greater than 256*256. I don't know how restrictive modern graphics cards are in what texture sizes they accept, but this way I think we are safe to also support older cards. Everything went quite well, until I tried to render a rotated image composed of multiple textures. The result was something like what can be seen on the first screenshot. Somehow there were visible lines at the texture boundaries.

It took me a while to find out what happend here. The problem was that, when rendering a textured primitive with OpenGL, it repeats the same texture when specifying texture coordinates greater than one. Now, when drawing a rotated quad, OpenGL seems to have accessed such a texture coordinate for interpolation, even though I never gave a number greater than 1.0 to glTexCoord.

Once I understood the problem, it was easy to fix. Simply tell OpenGL not to repeat the texture, but clamp texture coordinates to the range [0,1]. This is done using glTexParameteri, by setting the GL_TEXTURE_WRAP_S and GL_TEXTURE_WRAP_T parameters to GL_CLAMP.

Another solution seems to be to set it to GL_CLAMP_TO_EDGE_EXT, but this requires the GL_EXT_texture_edge_clamp extension, and GL_CLAMP works well enough already.