search

hajimehoshi / ebiten

Ebitengine - A dead simple 2D game engine for Go
https://ebitengine.org
Apache License 2.0
11k stars 657 forks source link

SetWindowSize() and Layout() sizes not matching at fractional display scale factors #2978

Open tinne26 opened 6 months ago

tinne26 commented 6 months ago

Ebitengine Version

v2.7.2

Operating System

Go Version (go version)

go1.22.2

What steps will reproduce the problem?

Running the following program with a fractional display scale factor (I tested 125%):

package main

import "fmt"

import "github.com/hajimehoshi/ebiten/v2"

type Game struct {
    windowSize int
    waitLeft int
    lastW, lastH int
    lastWf, lastHf float64
}

func (self *Game) Layout(w, h int) (int, int) {
    if w != self.lastW || h != self.lastH {
        fmt.Printf("new dimensions at layout: %d x %d\n", w, h)
        self.lastW, self.lastH = w, h
    }
    return w, h
}

// (uncomment to test LayoutF() behavior)
// func (self *Game) LayoutF(w, h float64) (float64, float64) {
//  if w != self.lastWf || h != self.lastHf {
//      fmt.Printf("new dimensions at layout: %.02f x %.02f\n", w, h)
//      self.lastWf, self.lastHf = w, h
//  }
//  return w, h
// }

func (self *Game) Update() error {
    if self.waitLeft > 0 {
        self.waitLeft -= 1
    } else { // self.waitLeft <= 0
        if self.windowSize >= 400 { return nil } // don't keep growing indefinitely
        self.windowSize += 1
        self.waitLeft = 120 // two seconds wait (lower is ok too)
        ebiten.SetWindowSize(self.windowSize, self.windowSize)
        fmt.Printf("setting window size to %d x %d\n", self.windowSize, self.windowSize)
    }

    return nil
}

func (self *Game) Draw(*ebiten.Image) {}

func main() {
    ebiten.SetWindowSize(300, 300)
    err := ebiten.RunGame(&Game{ windowSize: 300 })
    if err != nil { panic(err) }
}

What is the expected result?

Layout sizes match most recently set window sizes.

What happens instead?

Running the program with device scale factor 100% makes everything work as expected:

new dimensions at layout: 300 x 300
setting window size to 301 x 301
new dimensions at layout: 301 x 301
setting window size to 302 x 302
new dimensions at layout: 302 x 302
setting window size to 303 x 303
new dimensions at layout: 303 x 303
setting window size to 304 x 304
new dimensions at layout: 304 x 304
setting window size to 305 x 305
new dimensions at layout: 305 x 305
setting window size to 306 x 306
new dimensions at layout: 306 x 306
setting window size to 307 x 307
new dimensions at layout: 307 x 307
setting window size to 308 x 308
new dimensions at layout: 308 x 308
setting window size to 309 x 309
new dimensions at layout: 309 x 309
setting window size to 310 x 310
new dimensions at layout: 310 x 310

Running the program with device scale factor 125% shows discordances:

new dimensions at layout: 300 x 300
setting window size to 301 x 301
setting window size to 302 x 302
new dimensions at layout: 301 x 301
setting window size to 303 x 303
new dimensions at layout: 302 x 302
setting window size to 304 x 304
new dimensions at layout: 304 x 304
setting window size to 305 x 305
setting window size to 306 x 306
new dimensions at layout: 305 x 305
setting window size to 307 x 307
new dimensions at layout: 306 x 306
setting window size to 308 x 308
new dimensions at layout: 308 x 308
setting window size to 309 x 309
setting window size to 310 x 310
new dimensions at layout: 309 x 309

We see that we can get to pretty much any window size, but we tend to undershoot the target value.

Running the program with device scale factor 125% and LayoutF(), to have a more detailed view of what might be going on internally:

new dimensions at layout: 300.00 x 300.00
setting window size to 301 x 301
new dimensions at layout: 300.80 x 300.80
setting window size to 302 x 302
new dimensions at layout: 301.60 x 301.60
setting window size to 303 x 303
new dimensions at layout: 302.40 x 302.40
setting window size to 304 x 304
new dimensions at layout: 304.00 x 304.00
setting window size to 305 x 305
new dimensions at layout: 304.80 x 304.80
setting window size to 306 x 306
new dimensions at layout: 305.60 x 305.60
setting window size to 307 x 307
new dimensions at layout: 306.40 x 306.40
setting window size to 308 x 308
new dimensions at layout: 308.00 x 308.00
setting window size to 309 x 309
new dimensions at layout: 308.80 x 308.80
setting window size to 310 x 310
new dimensions at layout: 309.60 x 309.60

Here we can see that at each size increase, we keep getting further away from the target (-0.2, -0.4, -0.6) for a few steps, and then we snap back to the right size.

At first I thought the issue might be the OS not accepting certain sizes, but after the tests, I think this looks quite suspicious on Ebitengine's side.

Anything else you feel useful to add?

I wasn't sure that having SetWindowSize() and Layout() sizes match would even be possible, but after more detailed testing, I think it should be possible, this looks more like an internal scaling calculation mistake than an OS limitation.

For context, having this work correctly is useful for setting perfect windowed sizes on pixel art games.

hajimehoshi commented 5 months ago

I wasn't sure that having SetWindowSize() and Layout() sizes match would even be possible, but after more detailed testing, I think it should be possible, this looks more like an internal scaling calculation mistake than an OS limitation.

Do you have an idea how to fix this?

For context, having this work correctly is useful for setting perfect windowed sizes on pixel art games.

I'm not sure we can render something in a pixel-perfect way with 125% mode.

tinne26 commented 5 months ago

Do you have an idea how to fix this?

No, I'd have to go through the code to figure out if some floor or ceiling is being applied too early at some point or something like that.

I'm not sure we can render something in a pixel-perfect way with 125% mode.

Ignoring macOS and retina displays and all those apple things, yes, the device scaling is indifferent for rendering pixel perfect art. Notice that I'm not saying "render pixel art perfectly at an arbitrary scale", but "being able to set a window size compatible with our pixel art" (perfect multiple). This only depends on SetWindowSize() setting the requested size perfectly, which is what's not happening here.

hajimehoshi commented 2 months ago

Does this issue happen with LayoutF instead of Layout?

hajimehoshi commented 2 months ago

The suspicious logic is

hajimehoshi commented 2 months ago

and/or

https://github.com/hajimehoshi/ebiten/blob/3eda0dd3875bc33ede51779aa58ffce3e3e7d4f8/internal/ui/ui_glfw.go#L1200-L1248

hajimehoshi commented 2 months ago

We have to make a diagram or something to understand how the 'sizes' are converted... That's pretty compilicated. In the far future, we want to rewrite the GLFW part into Go and then the border line between GLFW and internal/ui will be blurred. I hope we would find a much clearer logic then.

venning commented 1 month ago

Adding my experience, based on a Discord conversation today with @tinne26:

I am on macOS 13.1. Layout() and LayoutF() receive incorrect screen dimensions when in fullscreen.

Laptop Monitor
---
14" MacBook Pro, 2021 (with a notch)
Actual resolution:    3024 x 1964 [source: https://support.apple.com/en-us/111902]
OS resolution:        1800 x 1169
Monitor().Size():     1800 x 1169 [+0 x +0]
Usable resolution:    1800 x 1125 [what applications can actually use below the notch]
Layout() resolution:  1799 x 1126 [-1 x +1]
LayoutF() resolution: 1799 x 1126 [-1 x +1]
DeviceScaleFactor():  2

External Monitor
---
Gigabyte M32U
Actual resolution:    3840 x 2160
OS resolution:        3008 x 1692
Monitor().Size():     3008 x 1692 [+0 x +0]
Usable resolution:    n/a
Layout() resolution:  3007 x 1692 [-1 x +0]
LayoutF() resolution: 3007 x 1692 [-1 x +0]
DeviceScaleFactor():  2

I use ebiten.Monitor().Size() to calculate canvas size, but that does require me to have a separate routine to account for the notch; I don't think that is a great long-term strategy since I'm not sure how all other monitors may be notched or otherwise have unusable space.

For completeness, I use displayplacer to manage my monitors: https://github.com/jakehilborn/displayplacer It reports both monitors as having "scaling: on".

Edited for clarity

hajimehoshi commented 1 month ago

Layout() resolution: 1799 x 1126 [-1 x +1] Layout() resolution: 3007 x 1692 [-1 x +0]

What was the result of LayoutF? The same?

venning commented 1 month ago

Yes, they receive the same parameters.