bloboats: Text (font? sprites?) not loaded

[smcv]

Prerequisites:

• Debian testing (Debian 12 alpha)
• apt install bloboats (Debian package version 1.0.2+dfsg-4+b1)
• Relevant libraries:
  • libsdl1.2debian version 1.2.15+dfsg2-8 (real SDL 1.2)
  • libsdl1.2-compat version 1.2.56-2 from Debian
  • libsdl1.2-compat version 1.2.58 locally-built during Steam Runtime development
  • libsdl2-2.0-0 version 2.24.0+dfsg-1
  • libsdl-image1.2 version 1.2.12-13+b1

To reproduce:

• Run bloboats (using the real SDL 1.2)
• Observe how menu is meant to look
• Exit
• Run LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/sdl12-compat bloboats (using 1.2.56-2 from Debian)
• Exit
• Run with 1.2.58 in the LD_LIBRARY_PATH
• Exit

Expected result: in all three cases, the menu renders normally

Actual result: with real SDL 1.2 the menu renders normally. With sdl12-compat, either 1.2.56 or 1.2.58, the text in the menu is replaced by white rectangles.

(Actual gameplay not tested.)

[icculus]

This is working for me.

[icculus@taise ~]$ SDL12COMPAT_DEBUG_LOGGING=1 LD_LIBRARY_PATH=/home/icculus/projects/sdl12-compat/cmake-build bloboats 
INFO: sdl12-compat, built on Oct  3 2022 at 21:25:24, talking to SDL2 2.25.0

[icculus]

(I'm on Ubuntu 22.04, using what is presumably the Debian package for bloboats, but I can't vouch for what SDL satellite libraries I'm using...could be built from source or whatever Ubuntu provides.)

[smcv]

OK, this is odd. With either 1.2.58-1 (from Debian) or 1.2.58 (locally built) or eba13ef (locally built), it is working fine for me with SDL_VIDEODRIVER=wayland (in a GNOME 43 session), but I'm getting white boxes instead of the letter sprites with the default X11 driver.

[icculus]

Ah, it reproduces on my laptop (using XWayland, not the Wayland backend), and not on my nvidia GPU (X11) desktop system.

This is feeling like it's going to be an OpenGL bug in the game, but I'll look further real fast just in case.

[icculus]

So this gets an SDL_VIDEOEXPOSE event on startup, deletes all its textures and rebuilds them. This is a bug in the game.

When rebuilding them, it glDeleteTextures() the existing GL texture, generates a new one, and reuploads the texture data, but doesn't update the texture name with the new one from glGenTextures. This is a bug in the game.

My guess (although I'm not at the desktop machine to verify) is that Nvidia's GL probably reuses texture names, so when you delete one, the next gen call reuses the same handle, causing this to work out by luck, but Mesa apparently just keeps incrementing the texture name.

My other guess is that Wayland never sends an EXPOSE event, since it's compositor-based. I guess SDL 1.2 doesn't send an expose event during SDL_SetVideoMode() on x11?

Worryingly, we send the 1.2 SDL_VIDEOEXPOSE event for both SDL_WINDOWEVENT_EXPOSED and SDL_WINDOWEVENT_SHOWN, which is surprisingly to me that neither triggers on Wayland, and that there might be some other game that we needed a SDL_VIDEOEXPOSE on startup to fix. I'll have to check.

I'll see what 1.2 does here, though....maybe it doesn't send SDL_VIDEOEXPOSE on window creation.

[icculus]

testsprite under sdl12-compat (these are the SDL2 events from SDL_EVENT_LOGGING=1)

INFO: SDL EVENT: SDL_WINDOWEVENT (timestamp=45 windowid=1 event=SDL_WINDOWEVENT_SHOWN data1=0 data2=0)
INFO: SDL EVENT: SDL_WINDOWEVENT (timestamp=46 windowid=1 event=SDL_WINDOWEVENT_HIDDEN data1=0 data2=0)
INFO: SDL EVENT: SDL_WINDOWEVENT (timestamp=102 windowid=1 event=SDL_WINDOWEVENT_SHOWN data1=0 data2=0)
Screen is at 8 bits per pixel
Screen is in system memory
Sprite is in system memory
INFO: SDL EVENT: SDL_WINDOWEVENT (timestamp=122 windowid=1 event=SDL_WINDOWEVENT_MOVED data1=640 data2=337)
INFO: SDL EVENT: SDL_WINDOWEVENT (timestamp=122 windowid=1 event=SDL_WINDOWEVENT_EXPOSED data1=0 data2=0)
INFO: SDL EVENT: SDL_WINDOWEVENT (timestamp=122 windowid=1 event=SDL_WINDOWEVENT_FOCUS_GAINED data1=0 data2=0)
INFO: SDL EVENT: SDL_WINDOWEVENT (timestamp=122 windowid=1 event=SDL_WINDOWEVENT_TAKE_FOCUS data1=0 data2=0)
INFO: SDL EVENT: SDL_WINDOWEVENT (timestamp=122 windowid=1 event=SDL_WINDOWEVENT_TAKE_FOCUS data1=0 data2=0)

What testsprite sees from SDL_PollEvent, with sdl12-compat:

EVENT 17 (SDL_VIDEOEXPOSE)
EVENT 17 (SDL_VIDEOEXPOSE)
EVENT 1 (SDL_ACTIVEEVENT)

With classic SDL 1.2:

EVENT 1 (SDL_ACTIVEEVENT)

[icculus]

Hmm...real SDL 1.2 isn't sending expose events even when I cover the window fully with something else and uncover it again. I guess this is a side effect of modern X11 using a compositor, too.

[icculus]

So when real 1.2 decides to send VIDEOEXPOSE events is complicated, with a tangle of various extensions even before you consider compositors, but one notable place is the literal X11 Expose event, where it only sends it along if SDL_SetVideoMode has completed, and I suspect that's probably what we should do here, too.

[smcv]

Confirmed fixed as of 67f8b3a (1.2.58 + 29 commits)