SDL_GetRGBA, SDL_GetRGB are hard to use correctly

[smcv]

As seen in #8317, to do format-sensitive colour conversion, you have to memcpy the right number of bytes into the low-order bits of a Uint32 (which do not necessarily start at byte 0!), and then pass that to SDL_GetRGBA() or SDL_GetRGB() to decode it into its colour channels. This seems unnecessarily tricky to get right.

One possibility to make this easier (and make implementing #8319 easier, if we want it) would be to change their signature from the current:

void SDL_GetRGB(Uint32 pixel, const SDL_PixelFormat *, Uint8 *, Uint8 *, Uint8 *);
void SDL_GetRGBA(Uint32 pixel, const SDL_PixelFormat *, Uint8 *, Uint8 *, Uint8 *, Uint8 *);

to be something more like

void SDL_GetRGB(const void *pixel, const SDL_PixelFormat *, Uint8 *, Uint8 *, Uint8 *);
void SDL_GetRGBA(const void *pixel, const SDL_PixelFormat *, Uint8 *, Uint8 *, Uint8 *, Uint8 *);

and do the "memcpy the right number of bytes into the low-order bits of a Uint32" step internally.

This might be troublesome for src/render/software/SDL_drawline.c, though.

[smcv]

Relatedly, I'm not sure that the uses of SDL_GetRGBA in src/video/SDL_shape.c and test/testshape.c are actually correct for 24-bits-per-pixel images, particularly on big-endian. They're certainly wrong for CPU architectures where unaligned accesses cause a SIGBUS or a silently wrong answer. But maybe nobody ever actually uses 24bpp in those contexts?

[slouken]

@icculus, I'd like to go ahead and export the functions @smcv added. If you're calling into the SDL API for each pixel, you don't care about speed, and we should at least make sure it works with the least amount of caveats.

[icculus]

As long as the documentation has a big "this is not fast!" warning on it, that's fine with me.