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

Incorrect window behaviors with Software mode #2671

Open
AlanDrake opened this issue Jan 28, 2025 · 5 comments
Open

Incorrect window behaviors with Software mode #2671

AlanDrake opened this issue Jan 28, 2025 · 5 comments
Labels
backend: sdl2 related to sdl2 library context: graphics mode type: bug unexpected/erroneous behavior in the existing functionality

Comments

@AlanDrake
Copy link
Contributor

Describe the bug
The SDL2 renderer has two issues that I don't recall being there when using true fullscreen:

  • the game screen remains on top after alt tabbing out
  • it often fails to resize the window when switching to windowed mode, keeping full screen size and drawing the game on the top left corner

Not sure if it's due to SDL

AGS Version
AGS 3 and 4 (latest)

To Reproduce
Steps to reproduce the behavior:

  1. Set software renderer and disable borderless fulscreen
  2. launch game
  3. alt-tab to see first issue
  4. alt-enter to see second issue

Expected behavior
Should work just like it does for D3D and OGL.

Desktop:

  • OS: Windows 10
@AlanDrake AlanDrake added backend: sdl2 related to sdl2 library type: bug unexpected/erroneous behavior in the existing functionality labels Jan 28, 2025
@ivan-mogilko
Copy link
Contributor

ivan-mogilko commented Jan 28, 2025

This reminds me of the bug report that I opened in SDL2 repo:
libsdl-org/SDL#7838

Idk if it's same case, but the symptoms are very similar.

That problem only occured if SDL created "direct3d" renderer. This may be controlled by writing "software_driver" in config, as explained in readme: https://github.com/adventuregamestudio/ags/blob/master/OPTIONS.md#configuration-file-options

@AlanDrake
Copy link
Contributor Author

AlanDrake commented Jan 28, 2025

Interesting, if I force software_driver=direct3d it works fine, but if remove it then it's back to working incorrectly.
And to make it more weird, the logs from one case to the other are identical (both report Created SDL Renderer: direct3d).

What could possibly change when "software_driver" is manually set to "direct3d" vs default?

@ivan-mogilko
Copy link
Contributor

ivan-mogilko commented Jan 28, 2025

And to make it more weird, the logs from one case to the other are identical (both report Created SDL Renderer: direct3d).
What could possibly change when "software_driver" is manually set to "direct3d" vs default?

That's what i mentioned in the linked ticket: when renderer is undefined, then SDL creates one in a "batching" mode, but if it's requested explicitly, then the batching mode is disabled (unless requested explicitly too).

@AlanDrake
Copy link
Contributor Author

I see, a SDL2 quirk then.

@ivan-mogilko
Copy link
Contributor

Hmm, since I started to have this behavior too, I guess this might be happening on multi-monitor systems.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backend: sdl2 related to sdl2 library context: graphics mode type: bug unexpected/erroneous behavior in the existing functionality
Projects
None yet
Development

No branches or pull requests

2 participants