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!
This is part of an overall effort to use the name, "WinRT", rather than "WindowsRT" (or "Windows RT"), as the shorthand name often seems to mean something different than the longhand name. (WinRT is an API, Windows RT is a product name)
This change removes some code that attempted to allow non-standard window sizes, the idea of which was to do display scaling, and a hackish one at that. If display scaling is needed, use SDL_Renderer as appropriate.
- moved SDL_WinRTApp.* from src/video/windowsrt/ to src/core/winrt/, and renamed them to SDL_winrtapp.* (to mimick case-sensitivity used elsewhere in SDL)
- renamed all "windowsrt" directories (in src) to "winrt", as the shorthand name is used more often (and, IMO, "WinRT" != "Windows RT", not entirely at least)
norfanin
SetupWindowData in SDL_windowswindow.c doesn't initialize two members of SDL_WindowData with NULL. This is an issue because other parts of the SDL code seem to make the assumption that this is the case. WIN_DestroyWindowFramebuffer for example uses data->mdc and data->hbm if they're not NULL.
Lloyd Bryant
SDL_CreateTexture() is succeeding (i.e. returning a valid pointer) when the requested horizontal or vertical size of the texture exceeds the maximum allowed by the render. This results in hard-to-understand errors showing up when later attempting to use that texture (such as with SDL_SetRenderTarget()).
Added a reference to SDL_Direct3D9GetAdapterIndex to SDL_test_common.c so SDL will fail to compile if the new symbol isn't included properly.
CR: Jorgen
aBothe
I tried to experiment a bit with SDL2 and OpenGL today and noticed that something caused some weird flickering when resizing my nicely drawn SDL2/OpenGL window:
Just after resizing, the background went black and I had to let my OpenGL code redraw the contents..
However, after some hours spent with googling I found out that in OpenGL examples where this CWBackPixel flag was not used when creating X windows, there was no flickering while resizing the window.
See http://www.sbin.org/doc/Xlib/chapt_04.html @ "The Window Background" for more info.
# Date 1379621782 -3600
# Thu Sep 19 21:16:22 2013 +0100
Work around a false-positive in the X11 mouse wheel code
This false positive occurs when one particular button on my mouse is
pressed. The kernel which I'm using is patched to cause a release event to
be synthesised immediately when the mouse says that this button is pressed
because the mouse doesn't signal release until the button is next pressed.
(Also documents a false negative, observed with the horizontal scroll wheel
on the same mouse.)
X11_RestoreWindow() had a call ordering problem that prevented activation, and X11_RaiseWindow() wasn't attempting activation. Windows and OS X both activate in these cases.
CR: saml
SDL provides an SDL_VIDEO_X11_VISUALID environment variable that lets you override
window visuals, but it wasn't being checked for OpenGL windows.
CR: Sam.
We can't use _try/_except without the C runtime, and we can't use inline
asm with the Win64 compiler. We'll need to move this to an .asm file or
something later.
kikuchan
Some joysticks with high sampling rate need to be read() more fast,
otherwise it delay user inputs due to internal queue.
Especially, an app that issues SDL_PollEvent() not so frequent
norfanin
When SDL_vsnprintf handles the %x format specifier, a boolean is set to signal forced lower case. It also should be able to signal forced upper case for the %X specifier. A boolean is not sufficient anymore. The attached patch adds an enum for the three cases: lower, upper and no change.
Pallav Nawani
This effects all SDL_Logxxx functions. On android, the debug output has a priority that is 1 higher than intended, ie, if you try SDL_LogInfo, the log has the priority of Warn instead.
SDL_syssem.c:159 comparison of unsigned expression >= 0 is always true
Solved by comparing unsigneds directly
SDL_systimer.c:164: warning: control may reach end of Compile
Solved by returning the default value if all else fails.
SDL_androidgl.c:41:1: warning: type specifier missing, defaults to 'int'
SDL_androidgl.c:47:1: warning: control reaches end of non-void function
Solved by adding void return type to the function implementation
Make it so XInput devices are listed before DirectInput devices, and that the XInput
devices are sorted by userid in ascending numeric order (so device 0 comes first).
Now multiple XInput controllers map correctly to device indexes instead of grabbing
the first available userid, and are completely separated out from DirectInput.
Also, the hardcoded limitation on number of DirectInput devices is gone. I don't
expect there to really ever be more than eight joysticks plugged into a machine, but
it was a leftover limitation for a static array we didn't actually use anymore.
Fixes Bugzilla #1984. (etc?)
- also adds OS X specific magic for bundled apps adding an Info.plist property of name SDL_FILESYSTEM_BASE_DIR_TYPE to the following values will change the bahaviour.
* bundle -- use the bundle directory e.g. "/Applications/MyGame/Blah.app/"
* parent -- use the bundle parent directory e.g. "/Applications/MyGame/"
* resource -- use the bundle resource directory (default) e.g. "/Applications/MyGame/Blah.app/Contents/Resources/"
- detect that you tried to open a gamecontroller in xinput mode and failed, then re-get the mapping for the dinput variant you did open (and most likely now just fail the open)
CR: SamL
This entire function is kind of a mess and more complicated than needed, but I don't want to refactor it too heavily tonight. May look at improving how the indexes are assigned more significanly later. The way it handles not finding a valid "gamepad" type device is also super broken, it leaves in place the xinput bindings but opens the controller with dinput and ends up with completely wrong mappings, not solving that now, but fixing the bug where we'd very frequently not find a controller due to gaps in assigned player numbers should mostly avoid it.
Andreas
The issue comes down to this line on MSDN:
"TranslateMessage produces WM_CHAR messages only for keys that are mapped to ASCII characters by the keyboard driver."
"WM_KEYDOWN and WM_KEYUP combinations produce a WM_CHAR or WM_DEADCHAR message. WM_SYSKEYDOWN and WM_SYSKEYUP combinations produce a WM_SYSCHAR or WM_SYSDEADCHAR message."
Except for WM_CHAR, none of these messages are used in SDL. Hence TranslateMessage should be dropped entirely and proper handling be included in the WM_KEYDOWN event.
Currently TranslateMessage is called for every message even if it must not be called in certain cases (like "An application should not call TranslateMessage if the TranslateAccelerator function returns a nonzero value.").
WM_CHAR message handling should remain for external processes posting these messages - additionally, WM_UNICHAR should be added.
I made a patch for src/video/windows/SDL_windowsevents.c that seems to work fine. It doesn't solve the "missing" composition for Khmer, but at least input for languages that cannot be mapped to ASCII characters (and for which IME is not used) will now work on Windows.
Jianyu Guan
I found I make a big mistake that when dstA==0, I just simply let *dstp=*srcp and forgot to make dstRGB = srcRGB*srcA.
The if consition "(*dstp & amask) == 0" in BlitRGBtoRGBPixelAlphaMMX and BlitRGBtoRGBPixelAlphaMMX3dNow should be removed.
I see the Remarks of function SDL_BlitSurface shows that "when SDL_BLENDMODE_BLEND, we have dstA = srcA + (dstA * (1-srcA))". however, I tested some pictures but the result implies "dstA=arcA" actually. I stepped into the source code, and found after I set SDL_BLENDMODE_BLEND for the source surface, the final blit function is BlitRGBtoRGBPixelAlphaMMX when I use SDL_BlitSurface on my computer. And I found these codes:
else if (alpha == amask) {
/* opaque alpha -- copy RGB, keep dst alpha */
*dstp = (*srcp & chanmask) | (*dstp & ~chanmask);
The same code is used in BlitRGBtoRGBPixelAlphaMMX3DNOW and BlitRGBtoRGBPixelAlpha. So I think they still keep dst alpha.
Best regards,
Jianyu Guan
If the app is in landscape mode and the user presses the power button, a pause
is followed immediately by a surfaceChanged event because the lock screen
is shown in portrait mode. This triggers a "false" resume.
So, we just pause and resume following the onWindowFocusChanged events.
Also, wait for SDL_APP_WILLENTERBACKGROUND and SDL_APP_DIDENTERBACKGROUND before
blocking the event pump.
