SDL 1.2.15: Is it possible to have a surface stored in big endian, despite running on an little endian machine?

Hello all,

I’ve got a 16bit surface whose contents I would like to be stored in big-endian, despite the machine being a little-endian one. Is this possible? This post suggests it’s not, but as it’s very old and I don’t know which SDL version this applies to, I wanted to ask here. Managing byte-swapped surfaces?

Adapting the bit mask I’m calling SDL_CreateRGBSurface() with wouldn’t work, as this would leave the bit order of byte-crossing colors in an incorrect state.

Thanks in advance!

SDL_Surfaces don’t have a way to specify byte order of individual color components, so a 16-bit pixel needs to be in native order.

It can, however, let you order components however you like, so a 32-bit RGBA pixel can be in ABGR (that is: little vs big endian), and that will work as long as you give it the right mask when you create the surface. But if it has to be 16-bit in a non-native ordering, you’re going to have to manage the surface yourself: SDL_BlitSurface() will give incorrect results if it ever has to convert the data.

1 Like