I think I have found a regression in the SDL2 2.0.6 prerelease checkout from Mercurial that practically breaks the graphics of my game “Rocks’n’Diamonds” (https://www.artsoft.org/rocksndiamonds/) and potentially every SDL2 program that uses SDL_SetColorKey() followed by SDL_ConvertSurface() to set a certain pixel color in a surface as being transparent and convert the surface to a different surface format (in my case to the “native” format for blitting to the target background surface).
At least for my game, this is a real show-stopper with SDL2 2.0.6.
Expected behaviour: All images in the menu and game where the background of the image file is 100% black should be transparent.
Observed behaviour: All images in the game that should be transparent are non-transparent now. Immediately visible at the “door” looking broken on the right side of the screen directly after starting the program. (In addition, all 100% white pixels of the images are transparent now.)
Some debugging revealed that the color key (explicitly set after loading the image files) was changed from totally black (0x00000000) on the old surface to totally white (0x00ffffff) on the new surface created by SDL_ConvertSurface().
I have used “hg bisect” to track down this problem, and found it to be caused by the following commit:
user: Sam Lantinga email@example.com
date: Sat Aug 12 16:59:00 2017 -0700
summary: Fixed bug 2979 - SDL_ConvertSurface does not convert color keys consistently
Related Bugzilla bug: https://bugzilla.libsdl.org/show_bug.cgi?id=2979
Undoing this specific commit in the SDL2 code fixes the problem, which can be reproduced with the Rocks’n’Diamonds source code (download and extract from link above and do a “make run”). I was able to reproduce this problem with Linux (Ubuntu 12.04 x64) and Mac OS X (10.11.6) with the latest SDL2 checkout from Mercurial.
I will also report this problem with a minimal code example and example PNG image file to Bugzilla this evening.