Denis Bernard
Background information: http://developer.android.com/reference/android/hardware/SensorEvent.html#values
Steps to reproduce: compile testjoystick.c as an android app (change screen size according to your device). While running the app, also run:
adb logcat -c; adb logcat -s 'SDL:*' 'SDL/APP:*'
When tilting the device left/right, the joystick moves in the opposite direction of what one would expect. Or at least, the behaviour is not consistent with the Y axis.
Also when the device sits on a table (obviously not moving), the Z axis value oscillates between -32000 and +32000 (by overflow):
I/SDL/APP ( 1994): Joystick 0 axis 2 value: 32511
I/SDL/APP ( 1994): Joystick 0 axis 2 value: 32575
I/SDL/APP ( 1994): Joystick 0 axis 2 value: 32383
I/SDL/APP ( 1994): Joystick 0 axis 2 value: -32386
I/SDL/APP ( 1994): Joystick 0 axis 2 value: -32450
I/SDL/APP ( 1994): Joystick 0 axis 2 value: -32578
This is caused by the accelerometer yielding a constant value around 9.81 for Z and feeding something like 0.9 to 1.1 to the joystick driver, resulting in the overflow.
Proposed fix in SDLActivity.java (swap X and subtract G from Z reading)
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.
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.
