I still haven't figured out why my application is being minimized when I try to raise, it but my previous workaround is causing issues.
For now the correct way to raise and/or restore the window is as follows:
if ( !(SDL_GetWindowFlags( window ) & SDL_WINDOW_MINIMIZED) )
{
SDL_RaiseWindow( window );
}
if ( SDL_GetWindowFlags( window ) & SDL_WINDOW_MINIMIZED )
{
SDL_RestoreWindow( window );
}
I will investigate the window state change rules more fully in the future.
CR: Alfred Reynolds
When we get a kCGEventTapDisabledByTimeout or
kCGEventTapDisabledByUserInput, the event tap would perform an invalid
memory access. void pointers are so fun.
This code only runs if you explicitly build with SDL_MAC_NO_SANDBOX.
Patrice Mandin
I encountered a problem trying to load a 8-bit paletted BMP file using SDL. This file was generated using GIMP 2.8. It has a big BITMAPINFOHEADER (0x6c bytes for biSize field), and thus the palette is incorrectly setup.
Lorenzo Pistone
this patch adds support for the horizontal wheel in Windows. It is shamelessly copied off the vertical wheel code, but I guess that that is a value added in consistency.
Thanks to Denis Bernard!
Also, changed the Android manifest so the app doesn't quit with orientation
changes, and made testgles.c exit properly on Android.
This bumps the build SDK level to 12 (up from 10). Runtime requirements remain
the same (at API level < 12 joystick support is disabled).
Also enables building SDL for armv7 and x86.
A port of the ANGLE library (OpenGL ES 2.0 for Direct3D) to WinRT, via https://github.com/stammen/angleproject, is used as a base.
To enable, clone 'angleproject' into the directory one above where SDL/WinRT is, open the file SDL/include/SDL_config_winrt.h, and uncomment the #defines that begin with 'SDL_VIDEO_OPENGL'. From there, apps can create an OpenGL capable SDL_Window via the flag, SDL_WINDOW_OPENGL, and an OpenGL ES 2 context via SDL_GL_CreateContext. The Direct3D 11.1 renderer cannot be used alongside SDL_WINDOW_OPENGL. Only Windows 8/8.1 is supported for now. Shaders may need to be precompiled, in some (all?) cases.
norfanin
The audio_enumerateAndNameAudioDevicesNegativeTests test in testautomation_audio.c reports a failure for SDL_GetAudioDeviceName when called on a driver that has only the default device. SDL_GetNumAudioDevices reports 1, but SDL_GetAudioDeviceName does not check if the index passed by the caller is in that range in this case. For positive numbers anyway.
This can be reproduced with the dummy driver on Windows and Linux.
Mai Lavelle
I've recently tried to create multiple windows and process key events for them, and found that key events weren't being generated for most of the windows. After some investigating I've observed the following effects. All but the most recently created window experience these effects...
- a focus lost event is generated immediately after the focus gained event, even tho window still has focus
- key events report window id 0 rather than the id of the window which has focus, SDL thinks no window has focus?
- giving focus to a non SDL window and then selecting an SDL window causes events to be generated as expected, but only until focus changes again
Focus change events are queued and delayed (200 ticks) before they are dispatched. The problem occurs when a focus out and focus in event are received on the same tick. When these delayed events are dispatched they will be sent in the order determined by the window list rather than the order in which they are received.
The focus out dispatch is implemented by calling SDL_SetKeyboardFocus(NULL). This will remove focus from any window, regardless of whether it is the one originally targeted by the X11 event.
Since SDL_SetKeyboardFocus() will always dispatch a focus lost event as needed, the easiest solution is simply to only call SDL_SetKeyboardFocus(NULL) when SDL_GetKeyboardFocus() matches the target window.
The first bug had mouse motion events not getting sent out on non-touch devices, if and when a mouse button wasn't pressed.
The second bug caused virtual mouse motion events to get sent out-of-order on touch devices: the motion event would get sent after the touch occurred, rather than before.
To enable the Debug Layer, set the hint, SDL_HINT_RENDER_DIRECT3D11_DEBUG to '1'.
The Debug Layer will be turned off by default, both in Release and Debug builds (of SDL).
Nitz
I was going through the SDL_IntersectRectAndLine function and wondered to see the ComputeOutCode function implementation.
The problem in this algo is, x and y axis are getting check with respect to 0, Which is wrong, it should be get checked with respect to rectangle x and y axis.
C.W. Betts
The recommended way of getting a file name that POSIX file APIs can open in OS X when using an NSString is -[NSString fileSystemRepresentation]. However, the current filesystem API in hg uses -[NSString UTF8String].
Andreas Ertelt
The problem in question is caused by changeset 7771 (http://hg.libsdl.org/SDL/rev/5486e579872e / https://bugzilla.libsdl.org/show_bug.cgi?id=2121)
The redefinition of __inline__ (introduced by the addition of begin_code.h:128's "|| __STRICT_ANSI__") results in mingw's gcc throwing multiple
warning: always_inline function might not be inlinable [-Wattributes]
as well as a whole bunch of redefinitions of mingw internals which break linking of projects including the SDL2 headers.
Sean McKean
I am running Ubuntu 12.04 (GL version 1.4 Mesa 8.0.4) , and on drawing a set of lines through the renderer through SDL_RenderDrawLines() (looped or not) or SDL_RenderDrawRect() I notice a pixel missing. For RenderDrawLines() it seems to be the second point in the sequence; for RenderDrawRect() it is the lower-right. This can be fixed by specifying SDL_RenderDrawPoint(s), but wouldn't it be easier to specify each pixel in a GL_POINTS glBegin/End loop in the OpenGL code, just to make sure?
I also ran the same program on Android; the rendering seemed to be correct, which uses glDrawArrays.
Kevin Wells
Overview:
SDL_RenderClear is only clearing part of a texture when it is the render target and a different size than the screen.
Steps to Reproduce:
1) This only occurs with the render driver set to direct3d, so: SDL_SetHint(SDL_HINT_RENDER_DRIVER,"direct3d")
Also, my window was 1280x720.
2) Create a texture for a render target with a resolution of 1024x1024:
texture=SDL_CreateTexture(main_window.renderer,SDL_PIXELFORMAT_RGBA8888,SDL_TEXTUREACCESS_TARGET,1024,1024);
SDL_SetTextureBlendMode(texture,SDL_BLENDMODE_BLEND);
3) Target the texture for rendering: SDL_SetRenderTarget(main_window.renderer,texture);
4) Set the draw color to whatever you want (problem occurs with both 0,0,0,0 and 0,0,0,255 among others) and then clear the render target:
SDL_SetRenderDrawColor(main_window.renderer,0,0,0,0);
SDL_RenderClear(main_window.renderer);
Actual Results:
Only about the top 3/4s of the texture gets cleared on calling SDL_RenderClear. The bottom 1/4 or so does not clear.
Expected Results:
Entire render target should be cleared.
J?nis R?cis
Brief history:
We recently ported a game from SDL 1.2 to SDL 2. While doing Windows testing, I soon discovered that the game exits without opening a window with my cross-compiled SDL2.dll, but works great with the SDL2.dll from the MinGW SDK on libsdl.org. It was as simple as swapping out the DLLs to make it work.
Running the game in Wine showed that the game actually does run, up until the call to SDL_CreateWindow, which fails and leads the game to print out an error:
Failure to create window (LoadLibrary("OPENGL32.DLL"): (null))
Which basically says that there was no error, but maybe that's a Wine quirk.
The error string originates in SDL_windowsopengl.c, in WIN_GL_LoadLibrary, which contains this piece of code:
wpath = WIN_UTF8ToString(path);
_this->gl_config.dll_handle = LoadLibrary(wpath);
SDL_free(wpath);
if (!_this->gl_config.dll_handle) {
char message[1024];
SDL_snprintf(message, SDL_arraysize(message), "LoadLibrary(\"%s\")",
path);
return WIN_SetError(message);
}
After some digging, I discovered the culprit: WIN_UTF8ToString returns NULL. Why? Because it calls iconv_open from an iconv.dll that does not support the UCS-2-INTERNAL encoding. Why does the official SDL2.dll work? Because it calls no external iconv functions at all.
It turns out that the Fedora MinGW infrastructure (from which I obtained the conventiently prebuilt iconv.dll) does not provide a DLL from libiconv, but instead provides a DLL from a minimal Windows library called win-iconv. Which knows a good bit, but doesn't know anything about UCS-2-INTERNAL:
http://code.google.com/p/win-iconv/source/browse/trunk/win_iconv.c#155
So there are two problems here:
1) The error message is clearly useless, because LoadLibrary is an innocent bystander. Instead wpath should probably checked for NULL, and a more appropriate error should be set. Ideally something that makes it clear than an external iconv is causing trouble.
2) SDL doomed itself at the ./configure step, by finding an existing iconv and happily using it without confirming support for the mandatory encodings required by SDL.
There are certainly a few easy ways out of the situation (although I didn't yet manage to figure out how to prevent ./configure from looking for external iconv), but this had me completely stomped for a good while, so I figured it's worth writing down if anything.
(Search also found this, which talks a little about using UTF-16LE instead of UCS-2-INTERNAL: https://bugzilla.libsdl.org/show_bug.cgi?id=2075)
Andreas Ertelt
SDL_dxjoystick.c is setting the classguid for device (dis)connect events to USB Devices in general:
dbh.dbcc_classguid = GUID_DEVINTERFACE_USB_DEVICE;
Wouldn't it make more sense to have it just subscribe to Hid device events? This would mean less meaningless events reaching the application.
Marcus von Appen
Revision eecbcfed77c9 of the SDL hg repo introduces the new
SDL_GetSystemRAM() function, which breaks the build on FreeBSD. Find
attached a patch, which unbreaks the build and also should (for most
cases) properly implement the sysctl support it.
T. Joseph Carter
As discussed (possibly to death), the Linux joystick driver does not actually report events for added or removed joysticks when you haven't got udev support.
We simply cannot know about removed joysticks without udev. But we can (and we should) report adding them. This brings the legacy case in line with pretty much the rest of SDL's joystick drivers.
This reverts http://hg.libsdl.org/SDL/rev/7cdeb64faa72 and fixes it in
the correct way. If you call SDL_SetWindowPosition on a fullscreen
window, it would update the x & y variables for the window, but not
actually move the window (since it was fullscreen). That would make the
internal state of the SDL_Window incorrect, causing
SDL_WarpMouseInWindow to offset incorrectly.
This makes it so SDL_SetWindowPosition updates the `windowed' x & y
coordinates, which take effect when you revert from fullscreen.
norfanin
Some of the tests keep using the pointers of a destroyed SDL_Window when the common event handling handled the close event. The event handler itself does not NULL the pointer after the destruction.
The attached patch adds a loop in the handler that will assign NULL to the destroyed window. It also adds checks to some of the tests so they skip those windows by checking for NULL.
On Android available touch devices are now added with video initialization (like
the keyboard). This fixes SDL_GetNumTouchDevices() returning 0 before any touch
events happened although there is a touch screen available. The adding of touch
devices after a touch event was received is still active to allow connecting
devices later (if this is possible) and to provide a fallback if the new init
did not work somehow. For the implementation JNI was used and API level 9 is
required. There seems to be nothing in the Android NDK's input header (input.h)
to implement everything on C side without communication with Java side.
This can break builds of existing SDL/WinRT apps. To fix, remove the reference to SDL_winrt_main.cpp, then add a reference to the renamed file, SDL_winrt_main_NonXAML.cpp. If you get a build error about a missing .winmd file, enable the /ZW compiler flag for that one file (at minimum).
XAudio2 2.8's header file, xaudio2.h, doesn't compile in plain C code for WinRT
apps, not automatically at least. Initially, this file was adapted to compile
as C++, however these changes are now deprecated in favor of some preprocessor
based hacks that should get xaudio2.h to compile (while making sure XAudio2
still works).
This change should allow apps to render correctly in Portrait mode, at minimum,
Support for orientation changes is pending.
Thanks to Pierre-Yves for assistance!
