Alex Szpakowski
I actually made a mistake when creating the previous patch file... I forgot to include a crucial line which changed.
I've attached a new patch which just changes the line I forgot, since the other part has already been applied to the repository.
I tested this one by doing a clean rebuild of SDL, and it works with the new patch.
J?nis R?cis
Reopening as compilation with ANSI C throws lots of unnecessary warnings, both using MinGW and using Linux GCC. (BTW, what happened? MinGW is broken to all hell. sdl2-config does not even link SDLMain anymore?)
I think this may have been lost somewhere, so again: GCC supports inlining via __inline__ in all known versions of GCC, regardless of the C standard in use. Please don't assume that __STRICT_ANSI__ implies no inlining support.
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].
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.
Ryan C. Gordon
Sam Lantinga
Andreas Schiffler
Stefanos Apostolopoulos