SDL 1.3: SDL_PixelType

slouken · May 18, 2006, 5:00pm

I’m creating an enumerated pixel format for SDL 1.3.
Did I miss anything important?

typedef enum {
SDL_PixelType_Unknown,
SDL_PixelType_Index1LSB,
SDL_PixelType_Index1MSB,
SDL_PixelType_Index4LSB,
SDL_PixelType_Index4MSB,
SDL_PixelType_Index8,
SDL_PixelType_Packed_RGB332,
SDL_PixelType_Packed_RGBX4444,
SDL_PixelType_Packed_XRGB4444,
SDL_PixelType_Packed_BGRX4444,
SDL_PixelType_Packed_XBGR4444,
SDL_PixelType_Packed_RGBA4444,
SDL_PixelType_Packed_ARGB4444,
SDL_PixelType_Packed_BGRA4444,
SDL_PixelType_Packed_ABGR4444,
SDL_PixelType_Packed_XRGB1555,
SDL_PixelType_Packed_RGBX5551,
SDL_PixelType_Packed_XBGR1555,
SDL_PixelType_Packed_BGRX5551,
SDL_PixelType_Packed_ARGB1555,
SDL_PixelType_Packed_RGBA5551,
SDL_PixelType_Packed_ABGR1555,
SDL_PixelType_Packed_BGRA5551,
SDL_PixelType_Packed_RGB565,
SDL_PixelType_Packed_BGR565,
SDL_PixelType_Packed_RGBX8888,
SDL_PixelType_Packed_XRGB8888,
SDL_PixelType_Packed_BGRX8888,
SDL_PixelType_Packed_XBGR8888,
SDL_PixelType_Packed_RGBA8888,
SDL_PixelType_Packed_ARGB8888,
SDL_PixelType_Packed_BGRA8888,
SDL_PixelType_Packed_ABGR8888,
SDL_PixelType_Uint8_RGB,
SDL_PixelType_Uint8_BGR,
SDL_PixelType_Uint8_RGBA,
SDL_PixelType_Uint8_BGRA,
SDL_PixelType_Uint16_RGB,
SDL_PixelType_Uint16_BGR,
SDL_PixelType_Uint16_RGBA,
SDL_PixelType_Uint16_BGRA,
SDL_PixelType_Uint32_RGB,
SDL_PixelType_Uint32_BGR,
SDL_PixelType_Uint32_RGBA,
SDL_PixelType_Uint32_BGRA,
SDL_PixelType_Float16_RGB,
SDL_PixelType_Float16_BGR,
SDL_PixelType_Float16_RGBA,
SDL_PixelType_Float16_BGRA,
SDL_PixelType_Float32_RGB,
SDL_PixelType_Float32_BGR,
SDL_PixelType_Float32_RGBA,
SDL_PixelType_Float32_BGRA,
SDL_NumPixelTypes
} SDL_PixelType;

Video drivers which support packed pixels in non-native endian formats
should advertise the native endian format, and must do a final swap before
sending the pixel data to the video card.

See ya,
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

Steaphan_Greene · May 18, 2006, 5:10pm

I assume you’re intentionally not including things in other colorspaces
(like YUV)?On Thu, May 18, 2006 at 10:00:48AM -0700, Sam Lantinga wrote:

I’m creating an enumerated pixel format for SDL 1.3.
Did I miss anything important?

–
Steaphan Greene
GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20060518/bc0595c2/attachment.pgp

slouken · May 18, 2006, 5:25pm

Not yet.

-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment> On Thu, May 18, 2006 at 10:00:48AM -0700, Sam Lantinga wrote:

I’m creating an enumerated pixel format for SDL 1.3.
Did I miss anything important?

I assume you’re intentionally not including things in other colorspaces
(like YUV)?

Christian_Walther · May 19, 2006, 6:37pm

Sam Lantinga wrote:

I’m creating an enumerated pixel format for SDL 1.3.
Did I miss anything important?

…
SDL_PixelType_Uint8_RGB,
SDL_PixelType_Uint8_BGR,
SDL_PixelType_Uint8_RGBA,
SDL_PixelType_Uint8_BGRA,
…

What about Uint8_ARGB and Uint8_ABGR? Not sure if it’s “important”, but
why have it for the packed formats and not for the Uint8 (and all other
non-packed) ones?

(This is not entirely relevant here, but I once got weird looks when I
mentioned on the Apple OpenGL mailing list that my image loading library
(SDL_image) returned RGBA and not ARGB pixels - ARGB apparently is the
native texture format for ATI hardware, and it seems QuickTime graphic
importers produce it. See
http://lists.apple.com/archives/mac-opengl/2005/Sep/msg00091.html.)

And, just to make sure I’m understanding this correctly:

SDL_PixelType_Packed_RGBA8888 is an Uint32 with R in the most
significant byte and A in the least significant byte?
SDL_PixelType_Uint8_RGBA are four consecutive Uint8s, with R at
address x and A at address x+3?

-Christian

Patrice_Mandin · May 19, 2006, 6:52pm

Le Thu, 18 May 2006 10:00:48 -0700
Sam Lantinga a ?crit:

I’m creating an enumerated pixel format for SDL 1.3.
Did I miss anything important?

[snip]

On Atari and Amiga systems, paletted modes are done using bitplanes
(interleaved or not, depending on the hardware) if you are using the
legacy video chip, so the 'Index’ed modes would not suit it.

Video drivers which support packed pixels in non-native endian formats
should advertise the native endian format, and must do a final swap
before sending the pixel data to the video card.

Then maybe the for-mentionned interleaved bitplanes modes could also be
’converted’ at the same time? In SDL video backend, there is internally
support for a shadow surface (for SW->HW blits from what I remember), so
would it be possible to add an extra conversion routine?–
Patrice Mandin
WWW: http://pmandin.atari.org/
Programmeur Linux, Atari
Sp?cialit?: D?veloppement, jeux

slouken · May 19, 2006, 7:01pm

Video drivers which support packed pixels in non-native endian formats
should advertise the native endian format, and must do a final swap
before sending the pixel data to the video card.

Then maybe the for-mentionned interleaved bitplanes modes could also be
’converted’ at the same time? In SDL video backend, there is internally
support for a shadow surface (for SW->HW blits from what I remember), so
would it be possible to add an extra conversion routine?

Sure, though it should be done inside the video driver so the rest of SDL
doesn’t have to worry about it, unless we want to expose planar and swapped
modes to the rest of the blitting system…

-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

Torsten_Giebl · May 19, 2006, 8:11pm

Hello !

On Atari and Amiga systems, paletted modes are done using bitplanes
(interleaved or not, depending on the hardware) if you are using the
legacy video chip, so the 'Index’ed modes would not suit it.

Video drivers which support packed pixels in non-native endian formats
should advertise the native endian format, and must do a final swap
before sending the pixel data to the video card.

Then maybe the for-mentionned interleaved bitplanes modes could also be
’converted’ at the same time? In SDL video backend, there is internally
support for a shadow surface (for SW->HW blits from what I remember), so
would it be possible to add an extra conversion routine?

How fast are todays AMIGA and ATARI systems ?
Are they fast enough for such a conversion on the fly ?

CU

Patrice_Mandin · May 19, 2006, 8:38pm

Le Fri, 19 May 2006 22:11:17 +0200 (CEST)
“Torsten Giebl” a ?crit:

On Atari and Amiga systems, paletted modes are done using bitplanes
(interleaved or not, depending on the hardware) if you are using the
legacy video chip, so the 'Index’ed modes would not suit it.

Video drivers which support packed pixels in non-native endian
formats should advertise the native endian format, and must do a
final swap before sending the pixel data to the video card.

Then maybe the for-mentionned interleaved bitplanes modes could also
be ‘converted’ at the same time? In SDL video backend, there is
internally support for a shadow surface (for SW->HW blits from what
I remember), so would it be possible to add an extra conversion
routine?

How fast are todays AMIGA and ATARI systems ?
Are they fast enough for such a conversion on the fly ?

Well, on both, the 68060 cpu can do a good job (I know Amiga also has
some ppc boards). For bitplanes -> chunky 8 bits conversion, there are
now routines that can perform the conversion at no cost; i.e. equivalent
to the cost of copying source buffer to destination buffer. This is
possible because of cpu cache, and different ram speeds (source is in
fast ram only for cpu usage, destination in slow ram only accessed by
chips).

In SDL, only video cards are supported on Amiga (using CyberGFX driver
and card). I could not count on video card for Atari SDL port, so I had
to add conversion routines.

And for the slower/non accelerated/standard machines, well, I prefer to
have a working albeit slow app, than a non working one (or with garbage
on screen).–
Patrice Mandin
WWW: http://pmandin.atari.org/
Programmeur Linux, Atari
Sp?cialit?: D?veloppement, jeux

Gerry_Jo_Jellestad · May 20, 2006, 6:55pm

RGBA/ARGB 2222 ? Don’t know if they should be considered “important”, but
I’ve heard of their existence, at least.

Index12 and Index16 could be nice, too.

Are there any plans of supporting indexed types with alpha, btw ?

GerryOn Thu, 18 May 2006 19:00:48 +0200, Sam Lantinga wrote:

I’m creating an enumerated pixel format for SDL 1.3.
Did I miss anything important?

Patrice_Mandin · May 27, 2006, 11:48am

Le Thu, 18 May 2006 10:00:48 -0700
Sam Lantinga a ?crit:

I’m creating an enumerated pixel format for SDL 1.3.
Did I miss anything important?

typedef enum {
[snip]
SDL_PixelType_Index4LSB,
SDL_PixelType_Index4MSB,
[snip]
} SDL_PixelType;

Do you plan to support 16 colours video modes in SDL?–
Patrice Mandin
WWW: http://pmandin.atari.org/
Programmeur Linux, Atari
Sp?cialit?: D?veloppement, jeux