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

Resolutions handling? (pun not intendent) #6

Closed
Vovkiv opened this issue Dec 30, 2022 · 0 comments
Closed

Resolutions handling? (pun not intendent) #6

Vovkiv opened this issue Dec 30, 2022 · 0 comments
Labels
possible feature Feature sounds promisin, but i'm not sure if it will be implemented

Comments

@Vovkiv
Copy link
Owner

Vovkiv commented Dec 30, 2022

At the moment, library simply use game width and height to scale to. So, if you use 1 resolution in your game, then you don't really need to do anything, but, if not... you kinda on your own, kid. If you, for example, want to support e.g 1920x1080 as 16:9 standard, 800x600 as 4:3 or even several resolutions for same aspect, e.g 1280x720, 1920x1080 then you need to manually craft list of resolutions, manually store somewhere, and manually decide what the nearest suitable resolution game can give as default.
So, i propose next:
Ditch rs.setGame() approach and use list with available resolutions, that you can fill with supported by you resolutions. Then, you load them with something like rs.setResolution(aspect, size) where aspect will correspond with aspect table, e.g {[1] = "4x3", [2] = "16x9"} and size with sub-table value with width and height. This will make selected resolution as current, and it will be used to scale to.
Also there will be tons of functions, to deal with list of resolutions, for example, to get list of all available 4:3 sizes, check if resolution is equal window/monitor size, so you could show user a message "This resolution is not match you monitor, continue anyway?" (tho, this sounds very annoying, so implementing this might sucks ass)
And, maybe very useful, include built-in timer, as games do: after changing resolution, lib will put 15 seconds timer and return old settings if options was not confirmed. But i also doubt that this will make into library, because i'm not sure how to approach this without love.update (since library now updates in love.resize)... maybe add separate function as rs.updateTimer(dt)? it sounds really ugly to put 2 update functions for something that could be done at 1...

@Vovkiv Vovkiv added the possible feature Feature sounds promisin, but i'm not sure if it will be implemented label Dec 30, 2022
@Vovkiv Vovkiv closed this as completed Apr 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
possible feature Feature sounds promisin, but i'm not sure if it will be implemented
Projects
None yet
Development

No branches or pull requests

1 participant