I was wondering if there are any limitations to either SDL_DisplayFormat or
SDL_DisplayFormatAlpha, I know these functions convert the specified
SDL_Surface * to the display format and then return it, but I wondered if there
would be any limitation, such as crossplatform or dependant on the screen or
something? For example, would something possibly not work if I made a function
that returned a surface with SDL_DisplayFormatAlpha on a surface I created on
someone else’s computer?
Those aren’t really “limitations”, but rather the expected behavior of the DisplayFormat functions. When you use those functions, they convert the existing pixel data to the same format as your current display surface. So if your friend has a different display color depth or byte ordering or whatever, then when you send your pixel data to him, it will not look right without more information. If you’re able to send the SDL_PixelFormat structure info and the pixel data, then you have everything you need to reconstruct the image on the other end. You need to have the pixel data and a good idea of how the data is stored (RGBA, ARGB, RGB, BGR, 32-bit, 24-bit, 16-bit, etc.) in order to transfer the image. So if you know the format of the data already (i.e. a common format), it is probably better to just send it without calling DisplayFormat, so your friend can use the same knowledge of the format to load the image using SDL_CreateRGBSurfaceFrom(). Even so, it is still better to save the surface (as .png or something) so that you benefit from a common encoding and compression. Then you just send the file.
To: sdl at libsdl.org
From: modjusticar at hotmail.com
Date: Wed, 23 Jul 2008 16:22:23 +0000
Subject: [SDL] Limitations to SDL_DisplayFormat?
Hello,
I was wondering if there are any limitations to either SDL_DisplayFormat or
SDL_DisplayFormatAlpha, I know these functions convert the specified
SDL_Surface * to the display format and then return it, but I wondered if there
would be any limitation, such as crossplatform or dependant on the screen or
something? For example, would something possibly not work if I made a function
that returned a surface with SDL_DisplayFormatAlpha on a surface I created on
someone else’s computer?
Those aren’t really “limitations”, but rather the expected behavior of the
DisplayFormat functions.
When you use those functions, they convert the existing pixel data to the
same format as your current
display surface. So if your friend has a different display color depth or
byte ordering or whatever, then
when you send your pixel data to him, it will not look right without more
information. If you’re able to send
the SDL_PixelFormat structure info and the pixel data, then you have
everything you need to reconstruct
the image on the other end. You need to have the pixel data and a good idea
of how the data is stored (RGBA,
ARGB, RGB, BGR, 32-bit, 24-bit, 16-bit, etc.) in order to transfer the
image. So if you know the format of
the data already (i.e. a common format), it is probably b
etter to just send it without calling DisplayFormat, so your friend can use
the same knowledge of the format
to load the image using SDL_CreateRGBSurfaceFrom(). Even so, it is still
better
to save the surface (as .png or something) so that you benefit from a common
encoding and compression. Then> you just send the file.
To: sdl libsdl.org
From: modjusticar hotmail.com
Date: Wed, 23 Jul 2008 16:22:23 +0000
Subject: [SDL] Limitations to SDL_DisplayFormat?
Hello,
I was wondering if there are any limitations to either SDL_DisplayFormat or
SDL_DisplayFormatAlpha, I know these functions convert the specified
SDL_Surface * to the display format and then return it, but I wondered if
there
would be any limitation, such as crossplatform or dependant on the screen
or
something? For example, would something possibly not work if I made a
function
that returned a surface with SDL_DisplayFormatAlpha on a surface I created
on
So suppose I make a library with a function that uses DisplayFormat, and the
user uses my library to make his or her program, then my function will use the
user’s display format to convert the image to, and then it should be compatible
with his or her display as well?
Those aren’t really “limitations”, but rather the expected behavior of the
DisplayFormat functions.
When you use those functions, they convert the existing pixel data to the
same format as your current
display surface. So if your friend has a different display color depth or
byte ordering or whatever, then
when you send your pixel data to him, it will not look right without more
information. If you’re able to send
the SDL_PixelFormat structure info and the pixel data, then you have
everything you need to reconstruct
the image on the other end. You need to have the pixel data and a good idea
of how the data is stored (RGBA,
ARGB, RGB, BGR, 32-bit, 24-bit, 16-bit, etc.) in order to transfer the
image. So if you know the format of
the data already (i.e. a common format), it is probably b
etter to just send it without calling DisplayFormat, so your friend can use
the same knowledge of the format
to load the image using SDL_CreateRGBSurfaceFrom(). Even so, it is still
better
to save the surface (as .png or something) so that you benefit from a common
encoding and compression. Then
you just send the file.
To: sdl libsdl.org
From: modjusticar hotmail.com
Date: Wed, 23 Jul 2008 16:22:23 +0000
Subject: [SDL] Limitations to SDL_DisplayFormat?
Hello,
I was wondering if there are any limitations to either SDL_DisplayFormat or
SDL_DisplayFormatAlpha, I know these functions convert the specified
SDL_Surface * to the display format and then return it, but I wondered if
there
would be any limitation, such as crossplatform or dependant on the screen
or
something? For example, would something possibly not work if I made a
function
that returned a surface with SDL_DisplayFormatAlpha on a surface I created
on
So suppose I make a library with a function that uses DisplayFormat, and the
user uses my library to make his or her program, then my function will use the
user’s display format to convert the image to, and then it should be compatible
with his or her display as well?