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

The ability to disable the recently added hidpi window resizing feature #1118

Closed
dev-inigmas opened this issue Dec 21, 2020 · 6 comments · Fixed by #1131
Closed

The ability to disable the recently added hidpi window resizing feature #1118

dev-inigmas opened this issue Dec 21, 2020 · 6 comments · Fixed by #1131
Labels
A-Rendering Drawing game state to the screen C-Enhancement A new feature

Comments

@dev-inigmas
Copy link

What problem does this solve or what need does it fill?

When the user of a game sets the "Windowed Resolution" to 1920x1080, they always mean physical pixels. Not being able to do this often results in rendering artifacts and definitely results in recording issues when using software like OBS.

Adjusting a Game to work with 4k resolutions is no different than getting a game to work between 800x600 and 1920x1080 resolutions. I myself, already had a Bevy project that I was recording/streaming the development of, that successfully scaled from 640x360 up to 4k and beyond.

Because I can't tell Bevy to use physical pixels when creating the Window, the new hidpi support is a breaking change that prevents developers and users from being able to control the created Window size.

Describe the solution would you like?

Add some sort of option to WindowDescriptor allowing me to specify whether I want to use Physical, or DPI scaled pixels for determining the window's size.

Describe the alternative(s) you've considered?

Alternatives include, allowing me to override the "scaling factor" so I can set it to 1.0, effectively disabling window scaling that way.

Additional context

My previous work in Bevy 0.2 having implemented resolution-aware rendering:

https://youtu.be/0vOHM2RZ508?t=6598

I have more recent records I could probably upload. But from that timestamp there's a pretty clear example of what I got going.

Here's a relevant article concerning another Game Engine that demonstrate the many pitfalls of scaling games; especially pixel art games: https://alvarber.gitlab.io/pixel-perfection-in-godot.html

@TheRawMeatball
Copy link
Member

Downstream issue: #1116

@cart
Copy link
Member

cart commented Dec 21, 2020

First: I watched your video awhile back and enjoyed it. Nice work :)

I agree that this should be configurable (and that the problem you're pointing out is real).

I don't think adjusting sprite scale based on resolution is a one-size-fits-all solution (and I'm guessing thats not what you're saying). In an increasingly hi-dpi world, resolution has way less bearing on DPI than it used to (ex: 4k phone vs 4k monitor). OS-reported scale factors are the best solution we have so far to fill in the gaps. Some games/apps will want to key off of that data. Some games/apps would prefer to ignore it (or use their own heuristic, like window height in physical pixels).

When the user of a game sets the "Windowed Resolution" to 1920x1080, they always mean physical pixels

I think I might agree with this. But I might argue that when a developer sets the windowed resolution to 1920x1080, in general they probably mean logical pixels. Otherwise apps would appear "tiny" and be potentially unusable on 4k displays.

@DJMcNab
Copy link
Member

DJMcNab commented Dec 21, 2020

As another data point, in windowed mode spelunky 2 (released september 2020) uses logical pixels when you set the resolution.

Which is not to say that we shouldn't support non-hidpi modes. But it's certainly not an every game always uses physical pixels.

@dev-inigmas
Copy link
Author

My response may have gone a little long. I just want to let you guys know that I very much like Bevy and I respect you all for your efforts on this project. Thank you.

First: I watched your video awhile back and enjoyed it. Nice work :)

Thanks. I took a mental health break a while back. The world was getting too nutty. Decided to just play video games with the fam for a while. Though I do want to get back into developing games with Bevy.

I don't think adjusting sprite scale based on resolution is a one-size-fits-all solution

I agree. So, please give developers the option to handle hidpi displays as is appropriate for their games.

In an increasingly hi-dpi world, resolution has way less bearing on DPI than it used to (ex: 4k phone vs 4k monitor)

It's been a while, but from what I recall of my last Android project; phone apps don't have adjustable window sizes. I need the option to set the window size to physical pixels for my PC game.

OS-reported scale factors are the best solution we have so far to fill in the gaps.

For PC games, I disagree. But it's okay for us to disagree. I'm not asking you to remove window scaling from the engine. I'm asking for easy access to turn it off so that I, the developer of my own games, can make my own choices and do what is right for my game.

Some games/apps will want to key off of that data. Some games/apps would prefer to ignore it (or use their own heuristic, like window height in physical pixels).

I think we agree here. 👍

But I might argue that when a developer sets the windowed resolution to 1920x1080, in general they probably mean logical pixels.

It's not my fault if some developers don't understand how pixels, scaling, DPI, etc... work for their chosen platform; or if they can't/won't write code that checks for these things and adapts their game's setup accordingly. I just want the option to choose for myself how to handle them. I'm not trying to take away tools that someone else may find useful.

This is the exact sort of issue that makes me not want to use most game engines to begin with. I see that this sensible default is there. Thank you. Can I override it now please? :)

As another data point, in windowed mode spelunky 2 (released september 2020) uses logical pixels when you set the resolution.

As a gamer and a streamer: I would consider changing the window size to anything other what I asked for to be a bug. And based on the discussions in here: https://steamcommunity.com/app/418530/discussions/5/2930112548444678728/ their user community is also confused about how windowed resolution works in Spelunky 2.

image

But it's certainly not an every game always uses physical pixels.

100% of rendered computer games (as opposed to terminal games and the like), are eventually rendered to Physical Pixels. I need the option to be able to accurately set the physical pixels rendered to the window so as to play nice with recorders like OBS, and not confuse users should I ever actually manage to ship anything. ;) - And I'm all about MVP; so the goal is to ship something to someone sooner rather than later.

The project in the video I sent doesn't use a pixel coordinate system, it uses a game unit coordinate system. It also correctly scales the art according to integer values. So in effect, my game has already setup it's own system of "logical pixels". This should not interfere with my ability to set the window size according to physical pixels.

Thanks again.

@cart
Copy link
Member

cart commented Dec 21, 2020

Sounds like we are all in agreement that supporting both modes is a good idea. I think the big open question is "what should the default be". I'd rather table that discussion for now. Let's add support for both, then collect feedback.

@dev-inigmas
Copy link
Author

Personally, I'm fine with the default being that the window scales. I think that it's useful for getting simple examples working and displaying well on hidpi machines without having to think too hard about it.

I just think it's bad for game projects that are far enough along that you'd want to "ship" them (even just sharing with friends), or want to accurately record them to 720p/1080p video.

@memoryruins memoryruins added C-Enhancement A new feature A-Rendering Drawing game state to the screen labels Dec 22, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Rendering Drawing game state to the screen C-Enhancement A new feature
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants