Arch Robison | 25 Nov 03:48 2015

MacOS RedFlicker bug

I don't know if the following is an SDL2 bug or MacOS bug.  The problem is that I fill a texture with red, then I fill it with blue (overwriting the red), and then I unlock and present it.  The result is mostly blue, but with *red* near the top.

Complete SDL2 code for the example and how to build it are at .

I reported a similar bug last year to Intel (see for DirectX on Windows and they called it an "OS issue".  I don't know if the MacOS issue is related.
Anyway, I'd appreciate opinions on whether this is an SDL problem, my misuse of SDL, or something to report to Apple.

- Arch D. Robison
SDL mailing list
SDL <at>
Mike Mestnik | 23 Nov 18:38 2015

Touch: Feature requests.

  I've been working on an Asus t300chi and have attempted to add touch
support to the dev version of 0ad.  Here are some things I've found
lacking with the current SDL2 interface.

1. Single touch events, can easily be cropped.  See example.
2. Number of finger delta, a change to the number of fingers in a
SDL_MULTIGESTURE would seem to be important.  Also easily
3. click and double click information.  I don't have code for this
yet, but I'll be writing it.
  a. Indication of how much longer till this motion event could
no-longer be a button event.  Also indicate that this can not later
become a button press, make sure 0 is past the time wher a finger up
event would generate a button press.
  b. If previous touch was button press, if this is a click->drag ect.
and optionally, I don't know how much or little these would help.
4. More information about the absolute finger positions in
SDL_MULTIGESTURE and the delta of these specific measurements.
  a. Min, Max, Avg distance from normalized center.
  b. Some form of indication of the absolute fingers rotated?
    I. divergence of the top most finger from vertical.
    II. max and min degree between two fingers.

Example source/ps/TouchInput.cpp attached.
Attachment (TouchInput.cpp): text/x-c++src, 4559 bytes
SDL mailing list
SDL <at>
Mason Wheeler | 23 Nov 13:43 2015

IMG_SavePNG does not preserve the image format

I've got a utility that opens an 8-bit PNG file, slices it up into several smaller files, and saves them for later use.  When they're used later, the files are loaded and read into an SDL_Surface, and the code locates palette index 0, if it can, to set as a color key before loading them to textures.  Unfortunately, I just discovered that I've got no color key because I've got no palette, because IMG_SavePNG is saving them as a 32-bit image rather than an 8-bit image!  I looked at the source, and sure enough, it checks to make sure that the image is a 32-bit RGBA image, or forcibly converts it before saving if it isn't.

This is really not acceptable.  What would be the simplest way to fix this so that 8-bit images stay 8-bit images?

SDL mailing list
SDL <at>
DLudwig | 23 Nov 00:27 2015

Re: SDL 2.0 compilation with Visual Studio 2015

FYI, this particular bug, whereby there's a build error in SDL_xinput.h, should now be fixed (in the latest code from

Are you still seeing the other build errors?

-- David L.

rotanov wrote:
The first post errors occurred on Windows 7 system with Visual Studio 2015.
On another system (Windows 8 Visual Studio 2015) I got lots of those:


Severity Code Description Project File Line
Error C2011 '_XINPUT_BATTERY_INFORMATION': 'struct' type redefinition [D:\dev\engine\build\sdl\src\sdl-build\SDL2.vcxproj] sdl d:\dev\engine\3rd\sdl\src\core\windows\SDL_xinput.h 122

Maybe related to this commit
SDL mailing list
SDL <at>
MrTAToad | 20 Nov 23:00 2015

Fw: important message

Well, my anti-virus does state that the site is somewhat on the dodgy side...
SDL mailing list
SDL <at>
brada | 20 Nov 17:22 2015

Re: Strange SDL_UpdateTexture() behaviour

This sounds like exactly what I already tried explaining to you. I never promised my code would work (in fact i made a disclaimer to the contrary); I was merely attempting to demonstrate that you need to pass an offset from your pixels array that corresponds to the rect you are trying to update, otherwise you are copying the pixels from the top left of your buffer (it is top left in SDL right?) which are not the pixels you actually change. This is why passing NULL works, because then its updating a rect equal to your entire image which means the top left pixel of the rect to update is in fact the pixels pointer you are passing; unlike when you are trying to update the subrect.

I dont know how to explain it more clearly; I'm sorry.

guido.gonzato wrote:
This is increasingly looking like a bug in SDL_UpdateTexture().

I happened to make it work in a very strange way. Let's modify the code as follows:


   SDL_UpdateTexture (texture, &rect, pixels, pitch);
   // WORKING - update the whole texture
   //  SDL_UpdateTexture(texture, NULL, pixels, pitch);

That is, let's uncomment out the "not working" code and comment out the "working" line.

Compile the program then click around; no pixels will be displayed. But if you keep clicking and manage to hit the (0, 0) pixel, voila! From now on, pixels will be correctly refreshed.

I'm really puzzled. Hints/ideas?

SDL mailing list
SDL <at>
bernard.solle | 20 Nov 13:02 2015

Fw: important message



New message, please read


bernard.solle <at>

SDL mailing list
SDL <at>
Noxalus | 19 Nov 19:05 2015

Detect when we open the iOS Control or Notification Center

Hello everyone

I'm wondering if it's possible to detect when we open the iOS Control (swipe up from screen bottom) or Notification (swipe down from screen top) center in a SDL application.

To handle touch events properly, I need to store data of a SDL_FINGERDOWN event, and I release them when SDL triggers a SDL_FINGERUP event.
Thus, I now exactly how many fingers there are on the screen at any moment.

The problem is that when I open the Control Center (with a swipe up gesture from the bottom part of the screen), SDL fires a SDL_FINGERDOWN event but when the Control Center window appears, we are not into the application anymore for iOS, so if we remove our finger, SDL won't trigger a SDL_FINGERUP event and my SDL application considers that there is still a finger on the screen.

I tried to find a solution using SDL_WindowEvent like SDL_WINDOWEVENT_FOCUS_LOST or SDL_WINDOWEVENT_LEAVE, but they are not fired when we open the Control or Notification center.

Is somebody already encountered this issue?

Thanks a lot for reading me
SDL mailing list
SDL <at>
brada | 19 Nov 18:25 2015

Re: Strange SDL_UpdateTexture() behaviour

I believe its not working because when you are updating a rect, the pixels pointer needs to be set to the first pixel of the rect. it looks like you are passing a pointer to all the pixels in the image so SDL is going to treat that as if it were the pixels for the rect only so you are going to end up with whatever was in the top left rect of the entire buffer.

Try adding an offset to the pointer something like (you probably want to think though this longer than i did)

pixels + (pitch * rect.y) + rect.x

It could be that im completely wrong also
SDL mailing list
SDL <at>
Daniel Gibson | 19 Nov 17:06 2015

Introducing SDL_stbimage.h - creating SDL_Surfaces from image files


I created a small header-only library that uses the awesome stb_image.h 
(see ) to decode image files and creates 
SDL_Surfaces from that (in RGB or RGBA, depending on whether the image 
file had an alpha channel or not):

It supports all file formats supported by stb_image.h, which are 
currently JPEG, PNG, BMP, PSD, TGA, GIF, PIC and PNM (.ppm, .pgm).

Using it is super-easy: Just drop SDL_stbimage.h and stb_image.h in your 
project, and in one of your .c/.cpp files, do

   #include "SDL_stbimage.h"

which will create the implementation of the libraries (both SDL_stbimage 
and stb_image) there. Isn't that a lot easier than integrating libpng, 
libjpeg etc in your buildsystem? :-)

Now you're ready to use it, like:

   SDL_Surface* surf = STBIMG_Load("test.png");
   if(surf == NULL) {
     printf("ERROR: Couldn't load test.png: %s\n", SDL_GetError());

   // ... do something with surf ...


(In your other source files just do #include "SDL_stbimage.h" without 
the #define SDL_STBIMAGE_IMPLEMENTATION to use the STBIMG_* functions)

It also has functions to load from a constant memory buffer and from 
SDL_RWops and a function to create stb_image specific IO-callbacks from 
SDL_RWops, in case you wanna use SDL_RWops and stb_image functions, but 
not SDL_Surface.
See the homepage and the header itself for more details:

I hope you like it!

ancientcc | 19 Nov 09:43 2015

Official repository on GitHub

The offical repository is based on Mercurial currently. It is inconvenient to developer that used to GitHub. In particular, they want to join the SDL development.


Recently, I wrote code on iOS, and hope to add some code to SDL, for example Ble, Gyroscope, Accelerometer etc.


Does the official plan to create SDL repository  on GitHub?


SDL mailing list
SDL <at>