Managing byte-swapped surfaces?

Hello SDL developpers,

I did not find any information in SDL_PixelFormat or SDL_Surface about
the byte order in the surfaces. On Atari, which has a m68k CPU
(big-endian), custom video cards are seen as little-endian. So if a
program wants to write a 16/24/32 bits pixel, it do not know if it must
byte-swap it or not (same for reading).

I also continue to develop (slowly :frowning: ) the Atari SDL port. I have one
video driver working, keyboard and mouse support. Maybe it would be nice
to write a HOWTO about writing a device driver, as I had to dig in others
drivers’ source to find out how things must work.

On Atari, I can do some things in many ways like timer, threads, cdrom
depending of the OS the user is running. So it would be nice to have all
different parts of SDL ‘driverized’ like audio and video (maybe for 1.3
?). It is necessary because on Atari there are several usable OS, from
TOS (single-tasking, no driver support for all hardware) to Mint
(multitasking, some drivers for hardware). So if in TOS I must write to
hardware directly, in MiNT I can use device drivers (if available).–
Patrice Mandin
WWW: http://www.multimania.com/pmandin
Programmeur Linux, Atari
Sp?cialit?: D?veloppement, jeux

“Patrice Mandin” wrote:

I did not find any information in SDL_PixelFormat or SDL_Surface about
the byte order in the surfaces. On Atari, which has a m68k CPU
(big-endian), custom video cards are seen as little-endian. So if a
program wants to write a 16/24/32 bits pixel, it do not know if it must
byte-swap it or not (same for reading).

SDL always keeps pixel values in the native byte order in surfaces. Adding
a byte order field in the format would complicate the code for rare gains.
For 8, 24 and 32bpp this is not a problem (it’s only a matter of adjusting
the RGBAmasks) but for 16bpp you’re screwed

I’ve been semi-worried about this problem for more modern hardware,
mainly Mac video boards hanging on a little-endian PCI bus, but Mac people
tell me there is some hardware magic being done so that the user sees
a native-endian framebuffer (I’d like to have this confirmed).

Anyway, I believe byte-swapped 16bpp framebuffers should be considered as
"odd and unsupported pixel format" – sorry. I might consider adding
an API for testing whether a surface is byte-swapped, but I’m not fond
of adding an extra optional byteswap to each of the blitter functions.

I still have an atari ST stowed away somewhere and while it’s got its
charm, TOS is one of the absolutely worst excuses for an operating
system I’ve ever encountered, so you have my sympathies

Dans l’article <mailman.1006428184.27794.sdl at libsdl.org>,
“Mattias Engdegard” a tapot? avec
ses petits doigts:

Anyway, I believe byte-swapped 16bpp framebuffers should be considered
as “odd and unsupported pixel format” – sorry. I might consider
adding an API for testing whether a surface is byte-swapped, but I’m not
fond of adding an extra optional byteswap to each of the blitter
functions.

So, I will remove support for non-native endianness surfaces when getting
the SDL_Surface. No problem, thanks for the answer. It is a rare case,
which happens only on some custom video boards.–
Patrice Mandin
WWW: http://www.multimania.com/pmandin
Programmeur Linux, Atari
Sp?cialit?: D?veloppement, jeux