Some of you may have noticed or received bugs about it, the mobile display changed on monday.
It was a quick fix because Chrome 128 changed the way it behaved with CSS zoom property, and it was this experimental feature we used for mobile display. To quickly react on all broken displays, we used viewport width instead of zoom, so game display don't break for mobile players updating to Chrome 128.
It worked as a temporary fix, but it also add some drawbacks: everything is now scaled down, including the chat buttons, and the browser is responding slower.
New framework option
So we just added a new option in `game_interface_width`, called `autoscale`, than can be `true`, `false` or `'viewport'`
autoscale: true -> same as before monday update, it sets CSS zoom property on player panels, title bar, and game area
autoscale: false -> same as before monday update, it sets CSS zoom property on player panels, title bar, but NOT and game area. Some devs disabled it with `zoom: 1 !important`, now they can remove the hack and use this framework flag instead
autoscale: 'viewport' -> current display since monday update
https://imgur.com/a/EiQxVbG
_currently, the default autoscale value is 'viewport', but we plan to switch default to true later (maybe in one week?) _
What I expect of you active developers
To have the smoothest transition when we default autoscale to `true`, it would be good if games have been tested with it, and adapted if necessary.
Set it to true if you want previous behavior, and check if general display / animations are handled correctly. If it doesn't, you probably need to replace getBoundingRect().width by offsetWidth on your custom animations.
Set it to false if you used the `zoom: 1 !important` hack, and remove this hack
It should let you handle complaints on your games about the new display, as you can come back to how it was.
If you use autoscale => false, you'll probably think min is useless. It is still applied to player panels and title bar, so if you don't care, please set it to 490, so player panels will show on 2 columns.
It was a quick fix because Chrome 128 changed the way it behaved with CSS zoom property, and it was this experimental feature we used for mobile display. To quickly react on all broken displays, we used viewport width instead of zoom, so game display don't break for mobile players updating to Chrome 128.
It worked as a temporary fix, but it also add some drawbacks: everything is now scaled down, including the chat buttons, and the browser is responding slower.
New framework option
So we just added a new option in `game_interface_width`, called `autoscale`, than can be `true`, `false` or `'viewport'`
autoscale: true -> same as before monday update, it sets CSS zoom property on player panels, title bar, and game area
autoscale: false -> same as before monday update, it sets CSS zoom property on player panels, title bar, but NOT and game area. Some devs disabled it with `zoom: 1 !important`, now they can remove the hack and use this framework flag instead
autoscale: 'viewport' -> current display since monday update
https://imgur.com/a/EiQxVbG
_currently, the default autoscale value is 'viewport', but we plan to switch default to true later (maybe in one week?) _
What I expect of you active developers
To have the smoothest transition when we default autoscale to `true`, it would be good if games have been tested with it, and adapted if necessary.
Set it to true if you want previous behavior, and check if general display / animations are handled correctly. If it doesn't, you probably need to replace getBoundingRect().width by offsetWidth on your custom animations.
Set it to false if you used the `zoom: 1 !important` hack, and remove this hack
It should let you handle complaints on your games about the new display, as you can come back to how it was.
If you use autoscale => false, you'll probably think min is useless. It is still applied to player panels and title bar, so if you don't care, please set it to 490, so player panels will show on 2 columns.