expose low-level colorkey info

[robertpfeiffer]

No description provided.

[robertpfeiffer]

My goal with this branch was to implement a different kind of converting for indexed surfaces, but at this point I am content to just have this so I can handle converted surfaces this way. If you need to know why this is exposed, it's because the PNG loading in SDL_image can load a palette with two identical colours and assign the correct one as the colour key.

I have encountered this behaviour in one of my games already, it's annoying.

I wanted to have a "reverse convert" to convert an 8-bit surface for receiving blits from indexed surfaces. Then I could convert all surfaces to the same palette and color key. Unfortunately, this doesn't work 100% reliably, at least not without assumptions about the palette the png file was saved with, and the palette SDL_image constructs when loading an indexed png.

[robertpfeiffer]

Anyway, it is probably better to expose this so I can write my palette-normaliser in python than to implement the palette-normaliser in C. I should probably check if it's actually faster to do it this way than just 32bit RGBA.

[MyreMylar]

These functions seem reasonable to me, albeit unlikely to be widely used.

Sometimes you do just need to know what SDL is doing under the hood to track down weird bugs.

[Starbuck5]

The docs specify a negative error code, not exactly -1.

[Starbuck5]

These all seem like reasonable functions with straightforward implementation.

• I'd think they should be called get/set_colorkey_mapped, to relate to the other "mapped" Surface functions.
• This needs tests
• Needs docs update to added in 2.5.1

[robertpfeiffer]

Okay. I'll change the name, fix the check for the return value, and update the docs.