MakoEnergy02
I am attempting to compile SDL on WindowsXP 32-bit, using MinGW. The problem I am having is when I attempt to compile, when it gets to "SDL_systhread.c" it errors:
C:\Repos\Mezzanine\Mezzanine\libincludes\common\sdlsrc\SDL\src\thread\generic\SDL_systhread.c|29|error: conflicting types for 'SDL_SYS_CreateThread'
C:\Repos\Mezzanine\Mezzanine\libincludes\common\sdlsrc\SDL\src\thread\generic\..\SDL_systhread.h|35|note: previous declaration of 'SDL_SYS_CreateThread' was here
I do have SDL_THREADS disabled in my cmake configuration as I do not want or need SDL making threads for me, I have another thread provider. It seems the generic "dummy" implementation does not account for the two extra parameters needed for the "SDL_SYS_CreateThread" method when "SDL_PASSED_BEGINTHREAD_ENDTHREAD" is defined.
Yuri K. Schlesner
The array returned by SDL_GetKeyboardState is also used internally by SDL to keep track of pressed/released keys and must not be modified, lest weird behaviour occurs. Because of this I believe it's return type should be changed to return a const pointer, which will provide a code indication of that fact.
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.
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.
