Sun, 09 Feb 2014 03:09:56 -0800Updated SDL to version 2.0.2
Sam Lantinga <slouken@libsdl.org> [Sun, 09 Feb 2014 03:09:56 -0800] rev 8197
Updated SDL to version 2.0.2

Sun, 09 Feb 2014 03:09:04 -0800Fixed the OUYA controller mapping on Windows
Sam Lantinga <slouken@libsdl.org> [Sun, 09 Feb 2014 03:09:04 -0800] rev 8196
Fixed the OUYA controller mapping on Windows

Sun, 09 Feb 2014 02:42:59 -0800Added Windows entry for the bluetooth OUYA controller
Sam Lantinga <slouken@libsdl.org> [Sun, 09 Feb 2014 02:42:59 -0800] rev 8195
Added Windows entry for the bluetooth OUYA controller

Sun, 09 Feb 2014 02:04:40 -0800Possibly fixed bug 2250 - Cmake: SDL2 Doesn't install DLLs on Windows
Sam Lantinga <slouken@libsdl.org> [Sun, 09 Feb 2014 02:04:40 -0800] rev 8194
Possibly fixed bug 2250 - Cmake: SDL2 Doesn't install DLLs on Windows

ernest.lee

[Exec] CMake Error at cmake_install.cmake:151 (FILE):
[13:37:43][Exec] file INSTALL cannot find
[13:37:43][Exec] "C:/TeamCity/buildAgent/work/2e3d17a492e75daf/Build/libSDL2.so".

The cmake INSTALL project doesn't work because it uses Linux so shared library paths. Windows uses dlls and I think cygwin also uses dlls. I've included this patch. Can you check if it works?

Sun, 09 Feb 2014 01:56:41 -0800Fixed bug 2385 - error: unknown type name 'IDirect3DDevice9'
Sam Lantinga <slouken@libsdl.org> [Sun, 09 Feb 2014 01:56:41 -0800] rev 8193
Fixed bug 2385 - error: unknown type name 'IDirect3DDevice9'

Sandu Liviu Catalin

I'm unable to compile the latest SDL (directly from the repository) even though I disabled every DirectX option since I don't need DirectX.

I allways het these errors:
D:\DevLibs\SDL\src\render\direct3d\SDL_render_d3d.c:1897:1: error: unknown type name 'IDirect3DDevice9'
D:\DevLibs\SDL\src\render\direct3d\SDL_render_d3d.c:1898:25: error: unknown type name 'SDL_Renderer'

Sun, 09 Feb 2014 01:49:01 -0800Fixed bug 2354 - [ES 2.0] SDL_RenderClear clears render target with wrong color
Sam Lantinga <slouken@libsdl.org> [Sun, 09 Feb 2014 01:49:01 -0800] rev 8192
Fixed bug 2354 - [ES 2.0] SDL_RenderClear clears render target with wrong color

ny00

SDL_RenderClear clears a render target with the wrong color, if the opengles2 renderer driver is used and the target texture's format is SDL_PIXELFORMAT_ARGB8888.

The bug is *not* reproduced if SDL_PIXELFORMAT_ABGR8888 is used as the texture format (the first from the renderer's list).
It is further not reproduced using any of the following renderer drivers: opengl, opengles (apparently powered by Gallium3D), software.
Finally, the correct color can be drawn using SDL_RenderFillRect (instead of SDL_RenderClear).

A few details about the current setup:
- OS: Ubuntu 12.04 for x86_64
- GPU: GeForce GTX 460
- GPU driver version: 331.20-0ubuntu1~xedgers~precise1 (from the xorg-edgers PPA)


---

Seth Williams

Sam,

It appears that the clear just needs to take the render target format into consideration.

Seth.

Fri, 07 Feb 2014 12:03:02 -0500Updated README-macosx.txt to note new minimum requirements, end of PowerPC.
Ryan C. Gordon <icculus@icculus.org> [Fri, 07 Feb 2014 12:03:02 -0500] rev 8191
Updated README-macosx.txt to note new minimum requirements, end of PowerPC.

Fri, 07 Feb 2014 11:55:13 -0500Make non-Clang compilers happy.
Ryan C. Gordon <icculus@icculus.org> [Fri, 07 Feb 2014 11:55:13 -0500] rev 8190
Make non-Clang compilers happy.

Fri, 07 Feb 2014 11:52:35 -0500Tell Clang's static analysis that SDL_assert() is an assertion handler.
Ryan C. Gordon <icculus@icculus.org> [Fri, 07 Feb 2014 11:52:35 -0500] rev 8189
Tell Clang's static analysis that SDL_assert() is an assertion handler.

This lets it know, for example, that when you do this...

SDL_assert(ptr != NULL);

...that (ptr) is definitely not NULL at this point in the program, for the
sake of static analysis. While a buggy program could definitely trigger this
assertion, Clang assumes your assertion check is covering it and won't
report possible NULL dereferences after this point.

Since SDL_assert might continue if the user clicks "ignore", without this
change Clang would notice you checked for NULL (meaning that NULL is a real
possibility here) and still wrote code outside of that test branch that
dereferences the pointer, and thus would always trigger false positives.

Static analysis is fun!

Fri, 07 Feb 2014 09:35:33 -0500slight adjustment to the hot plug test to allow it to be run with hap tics disabled
Edward Rudd <urkle@outoforder.cc> [Fri, 07 Feb 2014 09:35:33 -0500] rev 8188
slight adjustment to the hot plug test to allow it to be run with hap tics disabled