This resolves lots of confusion around resizable windows. Most people don't expect a viewport to be implicitly set when the renderer is created and then not to be reset to the window size if the window is resized.
Added common test command line parameters --logical WxH and --scale N to test the render logical size and scaling APIs.
The visibility attribute warnings in Haiku gl.h can be fixed by editing gl.h and changing the line:
#elif defined(__GNUC__) || (defined(__SUNPRO_C) && (__SUNPRO_C >= 0x590))
to
#elif (defined(__GNUC__) && __GNUC__ >= 4) || (defined(__SUNPRO_C) && (__SUNPRO_C >= 0x590))
as described in: http://dev.haiku-os.org/ticket/8882
Axel Dörfler
Currently, the default install target for Haiku is /boot/develop/tools/gnupro. However, this is not the expected install place. Instead, /boot/common should be used.
Gerry JJ
The state bitmask in SDL_MouseMotionEvent is stored in an Uint8. Unfortunately this doesn't actually have room for 8 buttons because SDL skips 4 button indices after the third mouse button (at least here on Linux x86-64, probably related to wheel handling?), so it's really just enough to track 4 buttons. For example, on a Logitech MX310 mouse I've got, even though the mouse has 6 buttons total, the left and right side buttons and extra middle button have indexes 8, 9 and 10, and the last two won't fit in the 8 bit button state.
The source of the button state (in SDL_Mouse) is already 32-bit, and the state field in SDL_MouseMotionEvent is 32-bit aligned and followed by three 8-bit padding fields. So simply changing the SDL_MouseMotionEvent state to an Uint32 and removing the padding fields fixes this, and I think it should be binary compatible, at least for little endian.
This is not completely thread-safe since it's possible for an event to come in and be unfiltered between the flush call and the setting of the new filter, but it's much better than it was.
Alex Szpakowski
When calling SDL_SetWindowPosition(window, SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED), the window moves to the correct position but it seems to internally set its x/y position values to the literal value of the SDL_WINDOWPOS_CENTERED define.
This causes all sorts of problems when SDL functions which use the window position (e.g. SDL_SetWindowGrab) are called after the aforementioned SDL_SetWindowPosition call.
Looking at the SDL_SetWindowPosition code, it seems that SDL_SendWindowEvent with the SDL_WINDOWEVENT_MOVED event is called at the end of the function using the literal value of the SDL_WINDOWPOS_CENTERED define, instead of the newly set window->x and window->y values.
SDL_SendWindowEvent then sets the values of window->windowed.x and window->windowed.y to that value (0x2FFF0000, aka 805240832.)
I have attached a patch which changes SDL_SetWindowPosition to make sure SDL_SendWindowEvent is called with the correct coordinate values, if SDL_WINDOWPOS_CENTERED is used (fixes the issue for me.)
Tested with Mac OS 10.8.3.
