libsdl-org / sdl12-compat

An SDL-1.2 compatibility layer that uses SDL 2.0 behind the scenes.
Other
193 stars 40 forks source link

Alpha Centauri - Artifacts around video playback #279

Closed vv221 closed 1 year ago

vv221 commented 1 year ago

Alpha Centauri used to be provided with a native engine developed by Loki, that can still be used with ./play.it (using the game build sold on GOG as a basis): https://www.dotslashplay.it/en/games/alpha-centauri

Video of secret projects are surrounded by some artifacts, see the following screenshot: smac With the real SDL 1.2 library, the parts of the screen surrounding the video playback are regular black bars, with no visible artifact.

The opening video (played when launching the game) is not affected.

The attached saved game is one turn before the completion of a secret project. Ending the turn triggers the video playback: secret-project-video.sav.gz

The file needs to be ungzipped, then copied into ~/.loki/smac/saves/.

Since this would require access to a commercial game for investigating the issue, I would be OK to buy a gift code to someone willing to work on this issue but does not own a copy of the game yet.

I am of course willing to provide more information, but since I’m quite new to anything related to SDL I would need step-by-step instructions on how to debug the issue.

vv221 commented 1 year ago

More details on the Alpha Centauri build used to trigger this bug is shared in another issue: https://github.com/libsdl-org/sdl12-compat/issues/277#issuecomment-1327217654

sulix commented 1 year ago

I can't reproduce this (at least with the opening video) with my copy of SMAC here. That's the full Loki version (with the 6.0a patch applied), not the ./play.it modified version, with some version of my wrapper library, which looks pretty similar to the one you mentioned in another of these threads.

vv221 commented 1 year ago

I can't reproduce this (at least with the opening video) with my copy of SMAC here.

My bad, I forgot to add this precision: this does not happen with the opening video, only during gameplay when a secret project video is played.

I updated the issue description to avoid the confusion.

To spawn such a video quickly, I start a game and play a couple turns with everything automated, then start the building of a secret project as soon as one is available. I could share a saved game one turn before the completion of such a project for easier reproducing.

vv221 commented 1 year ago

That's the full Loki version (with the 6.0a patch applied), not the ./play.it modified version

The ./play.it version uses the assets from GOG Windows build + a copy of Loki binaries updated to 6.0b (I don’t remember the origin of the patch, the file is named smac-6.0b-x86.run) + a wrapper shared in another issue: https://github.com/libsdl-org/sdl12-compat/issues/277#issuecomment-1327217654

icculus commented 1 year ago

I could share a saved game one turn before the completion of such a project for easier reproducing.

Please do!

vv221 commented 1 year ago

The attached saved game is one turn before the completion of a secret project. Ending the turn triggers the video playback: secret-project-video.sav.gz

The file needs to be ungzipped, then copied into ~/.loki/smac/saves/.

sulix commented 1 year ago

I can reproduce this with the savegame, but only under Wayland.

The corruption forms a nice border around the final text part of the video: the rest of it renders properly.

Interestingly, this text screen doesn't appear to be a part of the actual video file (at last according to mplayer).

It seems to me like the cause is the SDL_Flip() call in SDL_DisplayYUVOverlay() — it will call SDL_UpdateRects() , which will update the video surface, as well as the YUV overlay. Getting rid of this call (or making it PresentScreen() — though this introduces threading issues) gets rid of the corruption for me. It might be making the inability to skip videos as in #278 worse, though… Can't be sure.

(I also wondered if this could be a threading issue itself — SDL12COMPAT_ALLOW_THREADED_DRAWS=0 doesn't do anything here.)

vv221 commented 1 year ago

I can reproduce this with the savegame, but only under Wayland.

My tests have all been with X.org, I am not using Wayland on this computer. I use Mesa drivers with a AMD GPU, and a 5:4 screen (1280×1024).


Interestingly, this text screen doesn't appear to be a part of the actual video file (at last according to mplayer).

I can confirm that it is not included in the video file itself, but added by the game engine from a text file.

icculus commented 1 year ago

Closing this because @sulix's pull request solved the problem!