How to compile SDL in an IDE-style

Peiyun_Hu · April 9, 2013, 6:56am

Hey, guys,

I’m really a new hand to SDL and eager to make something with this amazing
library.

Now I’m going to port SDL into a new platform. But when I was trying to
compile SDL in an IDE-style like what is said in README.Porting, which is
compile with all source files. I found many link errors like

peiyun at Peiyun-Linux:sdl_try$ make sdl_link

gcc -Isdl_include/ sdl_lib/*.o code/init.c -o sdl_init
sdl_lib/SDL.o: In function SDL_InitSubSystem': SDL.c:(.text+0x17): undefined reference toSDL_StartTicks’
sdl_lib/SDL_audio.o: In function SDL_RunAudio': SDL_audio.c:(.text+0x23d): undefined reference toSDL_Delay’
sdl_lib/SDL_audio.o:(.data+0x0): undefined reference to PULSE_bootstrap' sdl_lib/SDL_audio.o:(.data+0x8): undefined reference toALSA_bootstrap’
sdl_lib/SDL_audio.o:(.data+0x10): undefined reference to DSP_bootstrap' sdl_lib/SDL_audio.o:(.data+0x18): undefined reference toDMA_bootstrap’
sdl_lib/SDL_audio.o:(.data+0x28): undefined reference to
DUMMYAUD_bootstrap' sdl_lib/SDL_cdrom.o: In functionSDL_CDROMInit’:
SDL_cdrom.c:(.text+0x13): undefined reference to SDL_SYS_CDInit' sdl_lib/SDL_cdrom.o: In functionSDL_CDROMQuit’:
SDL_cdrom.c:(.text+0x774): undefined reference to SDL_SYS_CDQuit' sdl_lib/SDL_diskaudio.o: In functionDISKAUD_WaitAudio’:
SDL_diskaudio.c:(.text+0x1ea): undefined reference to SDL_Delay' sdl_lib/SDL_events.o: In functionSDL_Lock_EventThread’:
SDL_events.c:(.text+0x36): undefined reference to SDL_Delay' sdl_lib/SDL_events.o: In functionSDL_GobbleEvents’:
SDL_events.c:(.text+0x106): undefined reference to SDL_Delay' sdl_lib/SDL_events.o: In functionSDL_WaitEvent’:
SDL_events.c:(.text+0x8dd): undefined reference to SDL_Delay' sdl_lib/SDL_gamma.o: In functionCalculateGammaRamp’:
SDL_gamma.c:(.text+0xd6): undefined reference to pow' sdl_lib/SDL_gamma.o: In functionCalculateGammaFromRamp’:
SDL_gamma.c:(.text+0x1ee): undefined reference to log' SDL_gamma.c:(.text+0x205): undefined reference tolog’
sdl_lib/SDL_joystick.o: In function SDL_JoystickInit': SDL_joystick.c:(.text+0x10): undefined reference toSDL_SYS_JoystickInit’
sdl_lib/SDL_joystick.o: In function SDL_JoystickName': SDL_joystick.c:(.text+0xef): undefined reference toSDL_SYS_JoystickName’
sdl_lib/SDL_joystick.o: In function SDL_JoystickOpen': SDL_joystick.c:(.text+0x20c): undefined reference toSDL_SYS_JoystickOpen’
sdl_lib/SDL_joystick.o: In function `SDL_JoystickClose’:

I thought I did not compile the source files in a correct way. So is there
anyone could tell me how to do it right?

Many thanks!

Best,
Peiyun–
Peiyun Hu ???
Department of Computer Science and Technology, Tsinghua University
Beijing, P.R.China
Zip Code: 100084

Sik_the_hedgehog · April 9, 2013, 7:20am

Looks like SDL_config.h is adapted for Linux. Did you make sure it
didn’t get overwritten by accident when building?

That said, about stuff like pow and log, that means the math library
isn’t included. Is this an embedded system without floating point or
weak floating point or something like that? Or just not configured
properly?

2013/4/9, Peiyun Hu <penn.peiyun at gmail.com>:> Hey, guys,

I’m really a new hand to SDL and eager to make something with this amazing
library.

Now I’m going to port SDL into a new platform. But when I was trying to
compile SDL in an IDE-style like what is said in README.Porting, which is
compile with all source files. I found many link errors like

peiyun at Peiyun-Linux:sdl_try$ make sdl_link

gcc -Isdl_include/ sdl_lib/*.o code/init.c -o sdl_init
sdl_lib/SDL.o: In function SDL_InitSubSystem': SDL.c:(.text+0x17): undefined reference toSDL_StartTicks’
sdl_lib/SDL_audio.o: In function SDL_RunAudio': SDL_audio.c:(.text+0x23d): undefined reference toSDL_Delay’
sdl_lib/SDL_audio.o:(.data+0x0): undefined reference to PULSE_bootstrap' sdl_lib/SDL_audio.o:(.data+0x8): undefined reference toALSA_bootstrap’
sdl_lib/SDL_audio.o:(.data+0x10): undefined reference to DSP_bootstrap' sdl_lib/SDL_audio.o:(.data+0x18): undefined reference toDMA_bootstrap’
sdl_lib/SDL_audio.o:(.data+0x28): undefined reference to
DUMMYAUD_bootstrap' sdl_lib/SDL_cdrom.o: In functionSDL_CDROMInit’:
SDL_cdrom.c:(.text+0x13): undefined reference to SDL_SYS_CDInit' sdl_lib/SDL_cdrom.o: In functionSDL_CDROMQuit’:
SDL_cdrom.c:(.text+0x774): undefined reference to SDL_SYS_CDQuit' sdl_lib/SDL_diskaudio.o: In functionDISKAUD_WaitAudio’:
SDL_diskaudio.c:(.text+0x1ea): undefined reference to SDL_Delay' sdl_lib/SDL_events.o: In functionSDL_Lock_EventThread’:
SDL_events.c:(.text+0x36): undefined reference to SDL_Delay' sdl_lib/SDL_events.o: In functionSDL_GobbleEvents’:
SDL_events.c:(.text+0x106): undefined reference to SDL_Delay' sdl_lib/SDL_events.o: In functionSDL_WaitEvent’:
SDL_events.c:(.text+0x8dd): undefined reference to SDL_Delay' sdl_lib/SDL_gamma.o: In functionCalculateGammaRamp’:
SDL_gamma.c:(.text+0xd6): undefined reference to pow' sdl_lib/SDL_gamma.o: In functionCalculateGammaFromRamp’:
SDL_gamma.c:(.text+0x1ee): undefined reference to log' SDL_gamma.c:(.text+0x205): undefined reference tolog’
sdl_lib/SDL_joystick.o: In function SDL_JoystickInit': SDL_joystick.c:(.text+0x10): undefined reference toSDL_SYS_JoystickInit’
sdl_lib/SDL_joystick.o: In function SDL_JoystickName': SDL_joystick.c:(.text+0xef): undefined reference toSDL_SYS_JoystickName’
sdl_lib/SDL_joystick.o: In function SDL_JoystickOpen': SDL_joystick.c:(.text+0x20c): undefined reference toSDL_SYS_JoystickOpen’
sdl_lib/SDL_joystick.o: In function `SDL_JoystickClose’:

I thought I did not compile the source files in a correct way. So is there
anyone could tell me how to do it right?

Many thanks!

Best,
Peiyun

–
Peiyun Hu ???
Department of Computer Science and Technology, Tsinghua University
Beijing, P.R.China
Zip Code: 100084

Sik_the_hedgehog · April 9, 2013, 7:21am

Wait forget what I said, I saw README.Porting and thought you were
porting to a new OS… or is that the case?

Also CD functions? Is this SDL 1.2, by any chance?

2013/4/9, Sik the hedgehog <@Sik_the_hedgehog>:> Looks like SDL_config.h is adapted for Linux. Did you make sure it

didn’t get overwritten by accident when building?

That said, about stuff like pow and log, that means the math library
isn’t included. Is this an embedded system without floating point or
weak floating point or something like that? Or just not configured
properly?

2013/4/9, Peiyun Hu <penn.peiyun at gmail.com>:

Hey, guys,

I’m really a new hand to SDL and eager to make something with this
amazing
library.

Now I’m going to port SDL into a new platform. But when I was trying to
compile SDL in an IDE-style like what is said in README.Porting, which is
compile with all source files. I found many link errors like

peiyun at Peiyun-Linux:sdl_try$ make sdl_link

gcc -Isdl_include/ sdl_lib/*.o code/init.c -o sdl_init
sdl_lib/SDL.o: In function SDL_InitSubSystem': SDL.c:(.text+0x17): undefined reference toSDL_StartTicks’
sdl_lib/SDL_audio.o: In function SDL_RunAudio': SDL_audio.c:(.text+0x23d): undefined reference toSDL_Delay’
sdl_lib/SDL_audio.o:(.data+0x0): undefined reference to
PULSE_bootstrap' sdl_lib/SDL_audio.o:(.data+0x8): undefined reference toALSA_bootstrap’
sdl_lib/SDL_audio.o:(.data+0x10): undefined reference to DSP_bootstrap' sdl_lib/SDL_audio.o:(.data+0x18): undefined reference toDMA_bootstrap’
sdl_lib/SDL_audio.o:(.data+0x28): undefined reference to
DUMMYAUD_bootstrap' sdl_lib/SDL_cdrom.o: In functionSDL_CDROMInit’:
SDL_cdrom.c:(.text+0x13): undefined reference to SDL_SYS_CDInit' sdl_lib/SDL_cdrom.o: In functionSDL_CDROMQuit’:
SDL_cdrom.c:(.text+0x774): undefined reference to SDL_SYS_CDQuit' sdl_lib/SDL_diskaudio.o: In functionDISKAUD_WaitAudio’:
SDL_diskaudio.c:(.text+0x1ea): undefined reference to SDL_Delay' sdl_lib/SDL_events.o: In functionSDL_Lock_EventThread’:
SDL_events.c:(.text+0x36): undefined reference to SDL_Delay' sdl_lib/SDL_events.o: In functionSDL_GobbleEvents’:
SDL_events.c:(.text+0x106): undefined reference to SDL_Delay' sdl_lib/SDL_events.o: In functionSDL_WaitEvent’:
SDL_events.c:(.text+0x8dd): undefined reference to SDL_Delay' sdl_lib/SDL_gamma.o: In functionCalculateGammaRamp’:
SDL_gamma.c:(.text+0xd6): undefined reference to pow' sdl_lib/SDL_gamma.o: In functionCalculateGammaFromRamp’:
SDL_gamma.c:(.text+0x1ee): undefined reference to log' SDL_gamma.c:(.text+0x205): undefined reference tolog’
sdl_lib/SDL_joystick.o: In function SDL_JoystickInit': SDL_joystick.c:(.text+0x10): undefined reference toSDL_SYS_JoystickInit’
sdl_lib/SDL_joystick.o: In function SDL_JoystickName': SDL_joystick.c:(.text+0xef): undefined reference toSDL_SYS_JoystickName’
sdl_lib/SDL_joystick.o: In function SDL_JoystickOpen': SDL_joystick.c:(.text+0x20c): undefined reference toSDL_SYS_JoystickOpen’
sdl_lib/SDL_joystick.o: In function `SDL_JoystickClose’:

I thought I did not compile the source files in a correct way. So is
there
anyone could tell me how to do it right?

Many thanks!

Best,
Peiyun

–
Peiyun Hu ???
Department of Computer Science and Technology, Tsinghua University
Beijing, P.R.China
Zip Code: 100084

Peiyun_Hu · April 9, 2013, 9:06am

Yes, I want to port SDL into a new OS, called ucore. And the version is
1.2.15.

By the way, after I added a SDL_config_ucore.h, and added macros in
SDL_platform.h, how should I do, to indicate the target OS, or indicate
which config.h should be used?On Tue, Apr 9, 2013 at 3:21 PM, Sik the hedgehog <sik.the.hedgehog at gmail.com wrote:

Wait forget what I said, I saw README.Porting and thought you were
porting to a new OS… or is that the case?

Also CD functions? Is this SDL 1.2, by any chance?

2013/4/9, Sik the hedgehog <sik.the.hedgehog at gmail.com>:

Looks like SDL_config.h is adapted for Linux. Did you make sure it
didn’t get overwritten by accident when building?

That said, about stuff like pow and log, that means the math library
isn’t included. Is this an embedded system without floating point or
weak floating point or something like that? Or just not configured
properly?

2013/4/9, Peiyun Hu <@Peiyun_Hu>:

Hey, guys,

I’m really a new hand to SDL and eager to make something with this
amazing
library.

Now I’m going to port SDL into a new platform. But when I was trying to
compile SDL in an IDE-style like what is said in README.Porting, which
is

compile with all source files. I found many link errors like

peiyun at Peiyun-Linux:sdl_try$ make sdl_link

gcc -Isdl_include/ sdl_lib/*.o code/init.c -o sdl_init
sdl_lib/SDL.o: In function SDL_InitSubSystem': SDL.c:(.text+0x17): undefined reference toSDL_StartTicks’
sdl_lib/SDL_audio.o: In function SDL_RunAudio': SDL_audio.c:(.text+0x23d): undefined reference toSDL_Delay’
sdl_lib/SDL_audio.o:(.data+0x0): undefined reference to
PULSE_bootstrap' sdl_lib/SDL_audio.o:(.data+0x8): undefined reference toALSA_bootstrap’

sdl_lib/SDL_audio.o:(.data+0x10): undefined reference to
`DSP_bootstrap’

sdl_lib/SDL_audio.o:(.data+0x18): undefined reference to
`DMA_bootstrap’

sdl_lib/SDL_audio.o:(.data+0x28): undefined reference to
DUMMYAUD_bootstrap' sdl_lib/SDL_cdrom.o: In functionSDL_CDROMInit’:
SDL_cdrom.c:(.text+0x13): undefined reference to SDL_SYS_CDInit' sdl_lib/SDL_cdrom.o: In functionSDL_CDROMQuit’:
SDL_cdrom.c:(.text+0x774): undefined reference to SDL_SYS_CDQuit' sdl_lib/SDL_diskaudio.o: In functionDISKAUD_WaitAudio’:
SDL_diskaudio.c:(.text+0x1ea): undefined reference to SDL_Delay' sdl_lib/SDL_events.o: In functionSDL_Lock_EventThread’:
SDL_events.c:(.text+0x36): undefined reference to SDL_Delay' sdl_lib/SDL_events.o: In functionSDL_GobbleEvents’:
SDL_events.c:(.text+0x106): undefined reference to SDL_Delay' sdl_lib/SDL_events.o: In functionSDL_WaitEvent’:
SDL_events.c:(.text+0x8dd): undefined reference to SDL_Delay' sdl_lib/SDL_gamma.o: In functionCalculateGammaRamp’:
SDL_gamma.c:(.text+0xd6): undefined reference to pow' sdl_lib/SDL_gamma.o: In functionCalculateGammaFromRamp’:
SDL_gamma.c:(.text+0x1ee): undefined reference to log' SDL_gamma.c:(.text+0x205): undefined reference tolog’
sdl_lib/SDL_joystick.o: In function SDL_JoystickInit': SDL_joystick.c:(.text+0x10): undefined reference toSDL_SYS_JoystickInit’
sdl_lib/SDL_joystick.o: In function SDL_JoystickName': SDL_joystick.c:(.text+0xef): undefined reference toSDL_SYS_JoystickName’
sdl_lib/SDL_joystick.o: In function SDL_JoystickOpen': SDL_joystick.c:(.text+0x20c): undefined reference toSDL_SYS_JoystickOpen’
sdl_lib/SDL_joystick.o: In function `SDL_JoystickClose’:

I thought I did not compile the source files in a correct way. So is
there
anyone could tell me how to do it right?

Many thanks!

Best,
Peiyun

–
Peiyun Hu ???
Department of Computer Science and Technology, Tsinghua University
Beijing, P.R.China
Zip Code: 100084

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
Peiyun Hu ???
Department of Computer Science and Technology, Tsinghua University
Beijing, P.R.China
Zip Code: 100084

Nathaniel_J_Fries · April 9, 2013, 1:43pm

Porting SDL 1.2 is pretty pointless at this juncture. It’s a relic, and infinitely less awesome than SDL2.0, which is what you should be porting instead.

Anyway, first you have to make a default configuration header in ucore (ie SDL_config_ucore.h) and include that from SDL_config.h if building for ucore.
AFAIK, there is no reference on this, although if you’re an experience C programmer you’ll probably understand what each macro is for without much effort anyway.
Basically, this config header will change how SDL (and potentially its sister libraries) will build themselves.

If ucore is fully POSIX-compliant and can run X11, porting SDL will probably not require much mucking about in source code, and simply filling out config.h properly.------------------------
Nate Fries

Peiyun_Hu · April 9, 2013, 2:04pm

Thanks for your advice! I’ve figured out how the config header works, and
I’ve created a basic config header for uCore.

Now I was confused about the video driver information, actually, I’m told
that the video is like frame buffer in Linux, but I do not know how to
describe it in the config. Should it be directfb, or fbcon?

As to the version of SDL, I have a game I want to port into uCore, which is
based on SDL, called PAL(one of the most famous RPG Game in China). I have
no idea about the backward compatibility of SDL 2.0.

Sorry about the messed up topic in this thread. :-POn Tue, Apr 9, 2013 at 9:43 PM, Nathaniel J Fries wrote:

**
Porting SDL 1.2 is pretty pointless at this juncture. It’s a relic, and
infinitely less awesome than SDL2.0, which is what you should be porting
instead. [image: Wink]

Anyway, first you have to make a default configuration header in ucore (ie
SDL_config_ucore.h) and include that from SDL_config.h if building for
ucore.
AFAIK, there is no reference on this, although if you’re an experience C
programmer you’ll probably understand what each macro is for without much
effort anyway.
Basically, this config header will change how SDL (and potentially its
sister libraries) will build themselves.

If ucore is fully POSIX-compliant and can run X11, porting SDL will
probably not require much mucking about in source code, and simply filling
out config.h properly.

Nate Fries

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
Peiyun Hu ???
Department of Computer Science and Technology, Tsinghua University
Beijing, P.R.China
Zip Code: 100084

Sik_the_hedgehog · April 9, 2013, 6:11pm

Forget about directfb and fbcon, use whatever your OS provides (which
in turn means provide your own code). Unless you have something
compatible with one of those it won’t work.

Also as a quick hack: just overwrite SDL_config.h with your own and
don’t run ./configure. Heck, make the file read-only if really needed
to ensure it doesn’t get overwritten during building.

2013/4/9, Peiyun Hu <penn.peiyun at gmail.com>:> Thanks for your advice! I’ve figured out how the config header works, and

I’ve created a basic config header for uCore.

Now I was confused about the video driver information, actually, I’m told
that the video is like frame buffer in Linux, but I do not know how to
describe it in the config. Should it be directfb, or fbcon?

As to the version of SDL, I have a game I want to port into uCore, which is
based on SDL, called PAL(one of the most famous RPG Game in China). I have
no idea about the backward compatibility of SDL 2.0.

Sorry about the messed up topic in this thread.

On Tue, Apr 9, 2013 at 9:43 PM, Nathaniel J Fries wrote:

**
Porting SDL 1.2 is pretty pointless at this juncture. It’s a relic, and
infinitely less awesome than SDL2.0, which is what you should be porting
instead. [image: Wink]

Anyway, first you have to make a default configuration header in ucore
(ie
SDL_config_ucore.h) and include that from SDL_config.h if building for
ucore.
AFAIK, there is no reference on this, although if you’re an experience C
programmer you’ll probably understand what each macro is for without much
effort anyway.
Basically, this config header will change how SDL (and potentially its
sister libraries) will build themselves.

If ucore is fully POSIX-compliant and can run X11, porting SDL will
probably not require much mucking about in source code, and simply
filling
out config.h properly.

Nate Fries

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
Peiyun Hu ???
Department of Computer Science and Technology, Tsinghua University
Beijing, P.R.China
Zip Code: 100084

Driedfruit · April 9, 2013, 5:21am

Hello list!

I’ve noticed a major change in 8-bit images / SDL_Color, which leads to
many unexpected behaviors.

In SDL 1.2, SDL_Color doesn’t have “a” value, but the SDL_PixelFormat
has an “alpha” value, set to SDL_ALPHA_OPAQUE (255) for RRGGBB palettes.

In SDL 2, SDL_Color does have an “a” value, and the SDL_PixelFormat
lacks the “alpha” value.

Now, in most cases (like making a new surface using
SDL_CreateRGBSurface, which does set the “a” to 255), this works fine,
but it’s really confusing in other situations.

For example, consider the following code:

SDL_Color red;
red.r = 255;
red.g = 0;
red.b = 0;

Then, in SDL1.2:

   SDL_SetColors(surface, &red, 0, 1);

or in SDL2:

    SDL_SetPaletteColors(surface->format->palette, &red, 0, 1);

Now, try blitting this “surface” onto a 32-bit surface.

In SDL1.2, alpha would be 255, and the whole thing would be blitted
correctly. In SDL2, you’ve just reset the alpha value for “red” to 0
(because you didn’t specify it explicitly), and the color would
actually appear as transparent.

What you should’ve done is also set:
red.a = 255;

It bit me in another way too, images loaded via SDL_LoadBMP now appear
to have zeroes for alphas in their palettes.

This, I’m not sure if it’s a problem with my images (does BMP even
support alphas in palettes? Somebody, please answer this!)

As a workaround, I’m doing something like:

for (int i = 0; i < surface->format->palette->ncolors; i++)
surface->format->palette->colors[i].a = 0xFF;

It’s simple, but it took me a while to figure out what was going on,
and I imagine people porting their SDL1.2 code might run into the same
issue.

So, there’s possibly a bug in SDL_LoadBMP, and in either case, this
change should be documented extensively on the wiki (in SDL_Color,
SDL_AllocPallete, SDL_CreateRGBSurface, migration guide, etc).

P.S. Just checked, the wiki on SDL_Color doesn’t even mention the "a"
value

Driedfruit · April 9, 2013, 5:24am

(Super sorry for double posting, apparently I’m an idiot and don’t
understand how mailing lists work, but this should go into a new
thread.)

Hello list!

I’ve noticed a major change in 8-bit images / SDL_Color, which leads to
many unexpected behaviors.

In SDL 1.2, SDL_Color doesn’t have “a” value, but the SDL_PixelFormat
has an “alpha” value, set to SDL_ALPHA_OPAQUE (255) for RRGGBB palettes.

In SDL 2, SDL_Color does have an “a” value, and the SDL_PixelFormat
lacks the “alpha” value.

Now, in most cases (like making a new surface using
SDL_CreateRGBSurface, which does set the “a” to 255), this works fine,
but it’s really confusing in other situations.

For example, consider the following code:

SDL_Color red;
red.r = 255;
red.g = 0;
red.b = 0;

Then, in SDL1.2:

   SDL_SetColors(surface, &red, 0, 1);

or in SDL2:

    SDL_SetPaletteColors(surface->format->palette, &red, 0, 1);

Now, try blitting this “surface” onto a 32-bit surface.

In SDL1.2, alpha would be 255, and the whole thing would be blitted
correctly. In SDL2, you’ve just reset the alpha value for “red” to 0
(because you didn’t specify it explicitly), and the color would
actually appear as transparent.

What you should’ve done is also set:
red.a = 255;

It bit me in another way too, images loaded via SDL_LoadBMP now appear
to have zeroes for alphas in their palettes.

This, I’m not sure if it’s a problem with my images (does BMP even
support alphas in palettes? Somebody, please answer this!)

As a workaround, I’m doing something like:

for (int i = 0; i < surface->format->palette->ncolors; i++)
surface->format->palette->colors[i].a = 0xFF;

It’s simple, but it took me a while to figure out what was going on,
and I imagine people porting their SDL1.2 code might run into the same
issue.

So, there’s possibly a bug in SDL_LoadBMP, and in either case, this
change should be documented extensively on the wiki (in SDL_Color,
SDL_AllocPallete, SDL_CreateRGBSurface, migration guide, etc).

P.S. Just checked, the wiki on SDL_Color doesn’t even mention the "a"
value :(–
driedfruit

Driedfruit · April 9, 2013, 9:38am

Thanks, I see.

I’ve checked and no, BMP files can’t have alpha channel in their
palette.

Here’s the relevant part of the spec
http://msdn.microsoft.com/en-us/library/windows/desktop/dd162938(v=vs.85).aspx
and a copy-paste for the lazy

typedef struct tagRGBQUAD {
BYTE rgbBlue;
BYTE rgbGreen;
BYTE rgbRed;
BYTE rgbReserved;
} RGBQUAD;
rgbReserved - This member is reserved and must be zero.

So, this change should be reverted to the way SDL1.2 behaved (ignored
the 4th component), like so

— a/src/video/SDL_bmp.c Mon Apr 08 18:37:50 2013 -0400
+++ b/src/video/SDL_bmp.c Tue Apr 09 13:36:24 2013 +0400
@@ -259,7 +259,9 @@
SDL_RWread(src, &palette->colors[i].b, 1, 1);
SDL_RWread(src, &palette->colors[i].g, 1, 1);
SDL_RWread(src, &palette->colors[i].r, 1, 1);

           /* Last byte must be ignored, so we overwrite it */
           SDL_RWread(src, &palette->colors[i].a, 1, 1);

           palette->colors[i].a = SDL_ALPHA_OPAQUE;
       }
   }

}–
driedfruit

On Wed, 10 Apr 2013 09:53:11 -0400 Jonathan Dearborn wrote:

Yeah, it’s a very new change so it hasn’t been worked into the wiki
yet. The reason that it breaks semantics with SDL 1.2 is because
SDL_Color used to have “unused” instead of “a”, which clearly implies
that it did not have an effect on palettes previously. It does sound
like the effect on SDL_LoadBMP may need to be looked at.

Jonny D

On Tue, Apr 9, 2013 at 1:24 AM, Driedfruit <@Driedfruit> wrote:
(Super sorry for double posting, apparently I’m an idiot and don’t
understand how mailing lists work, but this should go into a new
thread.)

Hello list!

I’ve noticed a major change in 8-bit images / SDL_Color, which
leads to many unexpected behaviors.

In SDL 1.2, SDL_Color doesn’t have “a” value, but the
SDL_PixelFormat has an “alpha” value, set to SDL_ALPHA_OPAQUE (255)
for RRGGBB palettes.

In SDL 2, SDL_Color does have an “a” value, and the SDL_PixelFormat
lacks the “alpha” value.

Now, in most cases (like making a new surface using
SDL_CreateRGBSurface, which does set the “a” to 255), this works
fine, but it’s really confusing in other situations.

For example, consider the following code:

SDL_Color red;
red.r = 255;
red.g = 0;
red.b = 0;

Then, in SDL1.2:
   SDL_SetColors(surface, &red, 0, 1);
or in SDL2:
    SDL_SetPaletteColors(surface->format->palette, &red, 0, 1);
Now, try blitting this “surface” onto a 32-bit surface.

In SDL1.2, alpha would be 255, and the whole thing would be blitted
correctly. In SDL2, you’ve just reset the alpha value for “red” to 0
(because you didn’t specify it explicitly), and the color would
actually appear as transparent.

What you should’ve done is also set:
red.a = 255;

It bit me in another way too, images loaded via SDL_LoadBMP now
appear to have zeroes for alphas in their palettes.

This, I’m not sure if it’s a problem with my images (does BMP even
support alphas in palettes? Somebody, please answer this!)

As a workaround, I’m doing something like:

for (int i = 0; i < surface->format->palette->ncolors; i++)
surface->format->palette->colors[i].a = 0xFF;

It’s simple, but it took me a while to figure out what was going on,
and I imagine people porting their SDL1.2 code might run into the
same issue.

So, there’s possibly a bug in SDL_LoadBMP, and in either case, this
change should be documented extensively on the wiki (in SDL_Color,
SDL_AllocPallete, SDL_CreateRGBSurface, migration guide, etc).

P.S. Just checked, the wiki on SDL_Color doesn’t even mention the
"a" value

–
driedfruit

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Driedfruit · April 9, 2013, 3:47pm

(The thread hi-jack continues Sorry again)

No, BMP doesn’t allow alpha. 32-bit BMP just adds a padding byte, it’s
completely unused. Some programs seem to allow a non-standard variant
where this byte is used as alpha, but basically one can’t rely on its
value since it’s 0x00 when it’s just padding.

Actually, BMP recently gained support for 32-bit alpha, via
headerV5, on Windows 8. Someone might look into adding support for it.

There’s also a rumored ALPHABITS compression method, which supposedly
is supported by Windows CE, but MSDN seems to deny it.

But this is unrelated to paletted images. Paletted images can’t
have alpha channel indeed.

If SDL_LoadBMP is filling bitmap alphas with zero, this is probably
a bug in SDL and needs to be fixed (same if IMG_Load is doing this
with other image formats).

Some programs leave garbage in this byte, leading to random alpha
values in SDL.

I bet there might be a similar problem with IMG_Load / other formats,
but I feel we’ll only find out on a case by case basis, checking them
all out sounds like a very tedious task

As for the other issues, SDL2.0 is not 100% compatible with SDL1.2.
I’d recommend not using SDL1.2’s surface APIs with SDL2.0 unless
it’s absolutely needed, and instead use the render API.

I’m not using the surface API to draw to screen, just to pre-composite
my textures.–
driedfruit

JonnyD · April 10, 2013, 1:53pm

Yeah, it’s a very new change so it hasn’t been worked into the wiki yet.
The reason that it breaks semantics with SDL 1.2 is because SDL_Color used
to have “unused” instead of “a”, which clearly implies that it did not have
an effect on palettes previously. It does sound like the effect on
SDL_LoadBMP may need to be looked at.

Jonny DOn Tue, Apr 9, 2013 at 1:24 AM, Driedfruit wrote:

(Super sorry for double posting, apparently I’m an idiot and don’t
understand how mailing lists work, but this should go into a new
thread.)

Hello list!

I’ve noticed a major change in 8-bit images / SDL_Color, which leads to
many unexpected behaviors.

In SDL 1.2, SDL_Color doesn’t have “a” value, but the SDL_PixelFormat
has an “alpha” value, set to SDL_ALPHA_OPAQUE (255) for RRGGBB palettes.

In SDL 2, SDL_Color does have an “a” value, and the SDL_PixelFormat
lacks the “alpha” value.

Now, in most cases (like making a new surface using
SDL_CreateRGBSurface, which does set the “a” to 255), this works fine,
but it’s really confusing in other situations.

For example, consider the following code:

SDL_Color red;
red.r = 255;
red.g = 0;
red.b = 0;

Then, in SDL1.2:
   SDL_SetColors(surface, &red, 0, 1);
or in SDL2:
    SDL_SetPaletteColors(surface->format->palette, &red, 0, 1);
Now, try blitting this “surface” onto a 32-bit surface.

In SDL1.2, alpha would be 255, and the whole thing would be blitted
correctly. In SDL2, you’ve just reset the alpha value for “red” to 0
(because you didn’t specify it explicitly), and the color would
actually appear as transparent.

What you should’ve done is also set:
red.a = 255;

It bit me in another way too, images loaded via SDL_LoadBMP now appear
to have zeroes for alphas in their palettes.

This, I’m not sure if it’s a problem with my images (does BMP even
support alphas in palettes? Somebody, please answer this!)

As a workaround, I’m doing something like:

for (int i = 0; i < surface->format->palette->ncolors; i++)
surface->format->palette->colors[i].a = 0xFF;

It’s simple, but it took me a while to figure out what was going on,
and I imagine people porting their SDL1.2 code might run into the same
issue.

So, there’s possibly a bug in SDL_LoadBMP, and in either case, this
change should be documented extensively on the wiki (in SDL_Color,
SDL_AllocPallete, SDL_CreateRGBSurface, migration guide, etc).

P.S. Just checked, the wiki on SDL_Color doesn’t even mention the "a"
value

–
driedfruit

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Nathaniel_J_Fries · April 10, 2013, 9:33pm

BMP can support alpha, but Microsoft Paint (the defacto tool for creating .bmp images on Windows) doesn’t allow the pixel format to be used. Maybe newer versions do, but the version that shipped with XP certainly didn’t.

If SDL_LoadBMP is filling bitmap alphas with zero, this is probably a bug in SDL and needs to be fixed (same if IMG_Load is doing this with other image formats).

As for the other issues, SDL2.0 is not 100% compatible with SDL1.2. I’d recommend not using SDL1.2’s surface APIs with SDL2.0 unless it’s absolutely needed, and instead use the render API.------------------------
Nate Fries

Sik_the_hedgehog · April 10, 2013, 10:17pm

No, BMP doesn’t allow alpha. 32-bit BMP just adds a padding byte, it’s
completely unused. Some programs seem to allow a non-standard variant
where this byte is used as alpha, but basically one can’t rely on its
value since it’s 0x00 when it’s just padding.

2013/4/10, Nathaniel J Fries :> BMP can support alpha, but Microsoft Paint (the defacto tool for creating

.bmp images on Windows) doesn’t allow the pixel format to be used. Maybe
newer versions do, but the version that shipped with XP certainly didn’t.

If SDL_LoadBMP is filling bitmap alphas with zero, this is probably a bug in
SDL and needs to be fixed (same if IMG_Load is doing this with other image
formats).

As for the other issues, SDL2.0 is not 100% compatible with SDL1.2. I’d
recommend not using SDL1.2’s surface APIs with SDL2.0 unless it’s absolutely
needed, and instead use the render API.

Nate Fries

Nathaniel_J_Fries · April 11, 2013, 2:56am

GDI has supported alpha channels for in-memory bitmaps since at least Win2k (according to MSDN), and I knew that Windows’ bitmap file functions were able to load and save 32-bit bitmaps, so I assumed that the format allowed it and it was just that MSPAINT didn’t; but I guess it’s not the first time I’ve been wrong.

Anyways, I guess that must be the source of his error.

Sik wrote:> No, BMP doesn’t allow alpha. 32-bit BMP just adds a padding byte, it’s

completely unused. Some programs seem to allow a non-standard variant
where this byte is used as alpha, but basically one can’t rely on its
value since it’s 0x00 when it’s just padding.

Nate Fries