Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
How to handle higher resolution screens? #3
I guess I'll be the first asking a question here :D
I haven't really utilized the web target until recently and I noticed an issue on higher resolution screens where my viewport is twice the size that I actually set. I first noticed it on a macbook pro, but I was able to reproduce it with the chrome device emulator.
This is how the game is intended to look:
And this is how it is displaying on higher resolution displays:
So my question is, how do I go about making it look like that first image on higher resolution displays?
Here's the source in case it's helpful: https://bitbucket.org/hexdie/onebuttonjam16/src
Thanks @hexdie, good question.
This stuff in particular needs to be documented with some more examples, but essentially the way it works is that there are some coordinate spaces that exist:
When you specify
On a high-DPI screen, or a screen with a content scaling factor (in Apple terms, retina) what you get is a scalar that exists with the device coordinates.
device != pixels
So when you have a scaling factor, the literal pixels that end up on the screen aren't in device coordinates anymore, they're scaled: 960 * 2x , 640 * 2x. This means you'll get maybe a quarter of your view, on a macbook with 2x scaling factor.
in luxe, coordinates are in renderable pixels,
This leaves you with a few choices on what to do.
Scale the world up, or scale the camera to show you the world scaled up.
The third coordinate space
There is a third space, which is the world you're creating. Making games means deciding this, how big is the space that you see on screen?
It can be convenient to treat this in the window space coordinates, but this will obviously change if the window size changes - different resolutions will have a different size world. This has always been a problem for games, unless you don't allow resizing, and hardcode the window size. What you're actually doing is...
Separate the coordinate spaces, and define a fixed size for your world. All this means is saying: When you look at the world at any given time, how many world units are displayed?
Let's take for example a simple tile based game, that has 5 tiles vertically on screen. If the world coordinates said one tile is 1 unit, then your world size is 5 on the y axis, in relation to the screen. A lot of pixel art games that scale up use this approach by picking a fixed resolution to work in - then drawing it bigger.
Making sense of the three combined
This leaves you with basically one actual choice/question: What coordinates/units am I using for my world, and how can I convey the world correctly on screen?
If you wanted to handle the resizing or setting sprites sizes, you'd need to keep in mind that luxe only speaks in the raw pixel sizes. If you use the device size, and need to convert back, you divide by
If you need to convert from the screen/camera space to the world space, you use the
Always consider the coordinate space you're dealing with.
Hopefully that helps clarify what's happening. When you set the window size, you're telling the window device size a fixed device size. If you use
If you use a numeric position or size in the game, you're using world coordinates, like sprite.size = [these are in world units].
Your world units might match the device size at 1x scale, but when non 1x scale comes along, you see more of it, because the world units are not fixed.
Let me know if that clarifies things.