Sun, 20 Oct 2013 10:35:51 -0700 Use vertex arrays for drawing points in addition to lines
Sam Lantinga <slouken@libsdl.org> [Sun, 20 Oct 2013 10:35:51 -0700] rev 7842
Use vertex arrays for drawing points in addition to lines
Sun, 20 Oct 2013 10:19:51 -0700 Fixed bug 1392 - Debian patch: do not propagate -lpthread
Sam Lantinga <slouken@libsdl.org> [Sun, 20 Oct 2013 10:19:51 -0700] rev 7841
Fixed bug 1392 - Debian patch: do not propagate -lpthread 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.
Sun, 20 Oct 2013 10:10:14 -0700 Fixed bug 2158 - Pixel missing in SDL_RenderDrawLines
Sam Lantinga <slouken@libsdl.org> [Sun, 20 Oct 2013 10:10:14 -0700] rev 7840
Fixed bug 2158 - Pixel missing in SDL_RenderDrawLines 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.
Sun, 20 Oct 2013 09:58:37 -0700 Fixed compiling with the new X11 symbol wrapping
Sam Lantinga <slouken@libsdl.org> [Sun, 20 Oct 2013 09:58:37 -0700] rev 7839
Fixed compiling with the new X11 symbol wrapping
Sun, 20 Oct 2013 17:23:43 +0200 Fix bug 1300 by querying current border size in ConfigureNotify, and adjusting window coordinates accordingly.
Stefanos Apostolopoulos <stapostol@gmail.com> [Sun, 20 Oct 2013 17:23:43 +0200] rev 7838
Fix bug 1300 by querying current border size in ConfigureNotify, and adjusting window coordinates accordingly.
Sat, 19 Oct 2013 01:29:23 -0700 Fixed bug 2162 - SDL_RenderClear not clearing entire render target
Sam Lantinga <slouken@libsdl.org> [Sat, 19 Oct 2013 01:29:23 -0700] rev 7837
Fixed bug 2162 - SDL_RenderClear not clearing entire render target 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.
Fri, 18 Oct 2013 10:56:45 -0400 Fixed the XInput2 X11 symbols.
Ryan C. Gordon <icculus@icculus.org> [Fri, 18 Oct 2013 10:56:45 -0400] rev 7836
Fixed the XInput2 X11 symbols.
Fri, 18 Oct 2013 00:49:59 -0700 Fixed bug 2108 - CMake does not set X11 includes properly for sdl2-config and friends
Sam Lantinga <slouken@libsdl.org> [Fri, 18 Oct 2013 00:49:59 -0700] rev 7835
Fixed bug 2108 - CMake does not set X11 includes properly for sdl2-config and friends 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.
Fri, 18 Oct 2013 00:47:22 -0700 Fixed bug 2123 - SDL_BlitScaled crashes in src/video/SDL_blit_N.c:2145
Sam Lantinga <slouken@libsdl.org> [Fri, 18 Oct 2013 00:47:22 -0700] rev 7834
Fixed bug 2123 - SDL_BlitScaled crashes in src/video/SDL_blit_N.c:2145 We need to reset the blit function when switching between scaled and unscaled blits.
Fri, 18 Oct 2013 00:13:51 -0700 Fixed bug 2139 - SDL_CreateWindow/WIN_GL_LoadLibrary fails due to external iconv not being able to convert path
Sam Lantinga <slouken@libsdl.org> [Fri, 18 Oct 2013 00:13:51 -0700] rev 7833
Fixed bug 2139 - SDL_CreateWindow/WIN_GL_LoadLibrary fails due to external iconv not being able to convert path 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)
(0) -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 tip