tuxfootball: selected option in main menu disappears

[smcv]

Prerequisites:

• Debian testing (Debian 12 alpha)
• Video: GNOME 43 in Wayland mode (with Mesa 22.2.0 on AMD Vega, if it matters)
• Audio: Pipewire 0.3.59, with pipewire-pulse emulating PulseAudio
• apt install tuxfootball (Debian package version 0.3.1-7)
• Some relevant libraries:
  • libsdl1.2-compat either 1.2.58-1 (packaged in Debian experimental) or commit 63e4393 (locally built)
  • libsdl2-2.0-0 version 2.24.1+dfsg-1
  • libsdl-image1.2 version 1.2.12-13+b1
  • libsdl-mixer1.2 version 1.2.12-17+b2
  • libsdl1.2debian (real SDL 1.2) version 1.2.15+dfsg2-8

To reproduce:

• tuxfootball
• LD_LIBRARY_PATH=.../sdl12-compat/_build tuxfootball
• SDL_VIDEODRIVER=wayland LD_LIBRARY_PATH=.../sdl12-compat/_build tuxfootball

and press Up/Down arrow keys.

Expected result: selected option is white, remaining options are gold

Actual result: Real SDL 1.2 works. With sdl12-compat, the selected option vanishes.

Gameplay seems OK as far as I can tell.

[icculus]

It's something with the font atlas image...if I swap font_white.png and font_yellow.png, I get just the current option and none of the others.

[icculus]

There's a color key of 0xFFFFFF (pure white) set for some reason. If I force color keying off for that surface, it renders correctly. Not sure why there's a colorkey at all yet.

[icculus]

Finally got back to this. So here's what's happening.

Eventually, this lands in SDL_Blit_Slow in SDL2. Probably because this is a 32-bit surface with an alpha channel and a colorkey, blitting to a 32-bit surface without an alpha channel, but I don't know.

The difference, of course, is this code in classic SDL-1.2's SDL_CalculateAlphaBlit ...

    if(sf->Amask == 0) {
	if((surface->flags & SDL_SRCCOLORKEY) == SDL_SRCCOLORKEY) {

...where it will only consider the colorkey of a surface at all if it doesn't have an alpha channel. SDL_Blit_Slow in SDL2, though, will discard pixels that match the colorkey and then alpha-blend what's left.

It's not clear to me if this is a bug in SDL-1.2 or a bug in SDL2. :)

We'll probably have to look for this case and just not set the colorkey on the SDL2 surface, though.