manuel.montezelo
Since the bug report[1] in 2006 Debian is shipping the patch attached.
[1] http://bugs.debian.org/375822
Maybe nowadays you don't propagate that library for linking, so maybe the patch should be dropped, but at the moment I do not have an easy/quick way to check it.
So I am submitting this report in the case that you consider it useful (even if maybe the patch itself has to be reworked), or otherwise learn if the patch is unneeded or even harmful.
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.
Marcus von Appen
The autotools-based code uses X_CFLAGS and some hackish x_includes code to add some necessary includes to SDL_CFLAGS for proper X11 and OpenGL include handling.
At the moment, the cmake-baed build code does not do that. Below is a patch, which provides the necessary changes to add a proper include to the SDL_CFLAGS.
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)
Denis Bernard
Background information: http://android-developers.blogspot.fr/2010/09/one-screen-turn-deserves-another.html and http://developer.android.com/reference/android/hardware/SensorEvent.html
Right now, the Android accelerometer event handler feeds raw accelerometer data to the SDL Joystick driver. The result is that for landscape-only applications, the axis need to be swapped if running on a portrait device (like a phone), and vice-versa: running a portrait only app on a landscape device like a tablet.
The purpose of this patch is to perform coordinate remapping of the accelerometer data before feeding it to the SDL joystick driver so that the X axis of the joystick is always aligned with the X axis of the display, same for the Y axis.
This has been tested on applications that support screen orientation changes as well as applications with fixed screen orientations, both on phones and tablets.
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.
norfanin
Fixes the version check for some functions that are only present with the MSVC 2013 CRT libraries.
I did my testing wrong and failed to see that 2012 doesn't have these functions. Microsoft implemented them in their upcoming 2013 version, though. The attached patch changes it to the check for the next version.
I also removed the HAVE_ITOA because that would require linking with oldnames.lib and it's easier to just let the SDL implementation take over.
Joseph Carter
There's a whole set of configure tests for BSD's libusbhid, and they only matter on BSD. However, if you have the library on Linux, it gets pulled in as library bloat. And it's bloat of the highest order since not a single function call to the library is ever made unless you're on a *BSD.
Ryan C. Gordon
Sam Lantinga
Stefanos Apostolopoulos
Gabriel Jacobo
Edward Rudd