stride3d / stride3d/stride

Game Window not resizing correctly (when AdaptBackBufferToScreen is set)

Open
#1,147 8 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

area-Graphics bug
Dominant language
C#
Stars
7.8k
Forks
1.2k
Avg merge
2d 17h
Merged PRs (30d)
49

Description

Release Type: Official Release (4.1.0.1459-beta, .Net 5.0.8)

Version: ^^^

Platform(s): Windows Desktop build

Describe the bug
When attempting to resize the game window (in windowed mode), the expected default behaviour of resizing does not occur, and the window will change it's size/position in ways it shouldn't (because something else was being changed)

To Reproduce
Steps to reproduce the behavior:

  1. Build any project and run it (Debug/Release are the same)
  2. Attempt to resize the game window that appears

Expected behavior
The window expands/contracts in the way that was desired. E.g. If dragging the right side of the window, it should increase in width, and have no other changes.

Actual Behaviour
The game window does 'funky shit' that is completely wrong. Things I have experienced:

  1. When attempting to make the window wider, the width stays the same, but the height shrinks instead (so the aspect ratio I was trying to get would probably be correct, but it changed the wrong thing)
  2. Same thing for the height
  3. The game window sets itself to 4k resolution, despite me being on a 1080p monitor.
  4. The window will forcibly set it's width (and I believe height too sometimes) to a number when I attempt to resize that seems reasonably close to 4k resolution

Screenshots

  1. Log of screen dimensions It should be noted that I never made the window larger in any dimension (not purposefully), just tried to shrink it and move it. It enlarged itself on it's own
  2. Recording of me testing code. Some things to note:
    • Flags 1-4 are me manually enlarging/shrinking the window via code using a loop, this works as expected
    • Flag 5 is 'no behaviour', where I disable my code and let Stride do it's own thing. It seems that changing the height seems to mostly work, but changing the width messes everything up. Also the 4k thing I mentioned happens several times, as well as the window being a completely different size to what it's supposed to be.
    • Flag 6 is my attempt at fixing it by forcibly setting the window size to what it's supposed to be (Window.SetSize(Window.PreferredWindowedSize);). This seems to work because, like i noted before, setting the dimensions from code works fine, it's just the user part that's broken

Log and callstacks
N/A AFAIK

Additional context
When changing the resolution and or position via code, the window appears to act normally - the issue appears to be only through user interaction.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the issue in a Windows Desktop build with AdaptBackBufferToScreen enabled, following the resize steps and comparing user resizing with Window.SetSize(Window.PreferredWindowedSize). Trace the window-resize path and verify that dragging each edge changes only the intended dimension without forcing an incorrect size or resolution.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp
Domain
desktop, game-dev
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.