Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alpha Centauri - Artifacts around video playback #279

Closed
vv221 opened this issue Nov 24, 2022 · 9 comments
Closed

Alpha Centauri - Artifacts around video playback #279

vv221 opened this issue Nov 24, 2022 · 9 comments
Assignees

Comments

@vv221
Copy link

vv221 commented Nov 24, 2022

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.

@icculus icculus self-assigned this Nov 25, 2022
@vv221
Copy link
Author

vv221 commented Nov 25, 2022

More details on the Alpha Centauri build used to trigger this bug is shared in another issue: #277 (comment)

@sulix
Copy link
Contributor

sulix commented Nov 25, 2022

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
Copy link
Author

vv221 commented Nov 25, 2022

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
Copy link
Author

vv221 commented Nov 25, 2022

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: #277 (comment)

@icculus
Copy link
Collaborator

icculus commented Nov 25, 2022

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

Please do!

@vv221
Copy link
Author

vv221 commented Nov 25, 2022

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
Copy link
Contributor

sulix commented Nov 27, 2022

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.)

sulix added a commit to sulix/sdl12-compat that referenced this issue Nov 27, 2022
Currently, if there are multiple SDL_DisplayYUVOverlay() calls in a row,
we force an SDL_Flip() between them, in order to make sure that the
screen is updated. However, this results in the non-YUV video surface
also being updated, even if it otherwise wouldn't be.

Instead, copy the code from all of the other places where we force an
update of the screen, which checks if the surface is dirty, and if not
calls PresentScreen() directly without updating the VideoSurface. (After
checking we're in the correct thread, of course...)

This hopefully fixes video artefacts in Alpha Centauri (bug libsdl-org#279)
@vv221
Copy link
Author

vv221 commented Nov 27, 2022

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 pushed a commit that referenced this issue Nov 27, 2022
Currently, if there are multiple SDL_DisplayYUVOverlay() calls in a row,
we force an SDL_Flip() between them, in order to make sure that the
screen is updated. However, this results in the non-YUV video surface
also being updated, even if it otherwise wouldn't be.

Instead, copy the code from all of the other places where we force an
update of the screen, which checks if the surface is dirty, and if not
calls PresentScreen() directly without updating the VideoSurface. (After
checking we're in the correct thread, of course...)

This hopefully fixes video artefacts in Alpha Centauri (bug #279)
@icculus
Copy link
Collaborator

icculus commented Nov 28, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants