Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
responsive: compute console font size from screen size #161
This is to resize the console font size according to screen size so low resolutions don't have huge chars and high resolutions don't have tiny chars.
It's a bit odd to have the font size change when the window is resized. Not many applications do that (though come to think of it, the old UI system with the 640x480 coordinate system might be one). Maybe we could consider the total monitor dimensions instead of the window dimensions (but not sure this number can be reliably obtained). If we assume everyone just uses full screen all the time, it doesn't really matter I guess.
The problem is that to get things properly displayed, and to provide consistent ui, and consistent interaction, things have to be at the same place whatever the resolution/size.
Look at Unvanquished 0.51.1 on 4K:
But in 1080p it looks somewhat like that:
See how the utilisability is absolutely not the same, minimap is super-tiny, the buildable indicator on the left is just very small and feels very far, and the build menu is just hardly usable. In fact, the main problem is not that things are tiny, the main problem is that your mouse path to reach things or your eye path to read things are never the same between two resolutions.
On 1080p I have to mouse down to reach the rocket pod in build menu, on 4K I have to mouse up, that's very annoying. And in fact on 1080p each buildable in build menu has its own gesture to get it, on 4K it's « almost the same gesture but with an accurate aim to get the one next to the other », and it's requiring more attention, so it slows down player and tire them quicker. Basically 4K players get handicap.
And things being two tiny is a problem btw, I always miss what people are saying while playing on 4K.
Now this is how looks Unvanquished on 4K (I just notice now that I forgot to scale one text):
This is not an app, it's a game, it's all about interaction.
I discovered the need for this work when I bought my 4K screen and I found that I had to relearn all my ui gestures in Unvanquished but I did not had to relearn them in Xonotic (that properly scales).
This is how console looked before:
This is how it looks now:
People with very large screens can still leverage their big screen to display more stuff in console by setting a smaller font size by tweaking
Of course you are right about the librocket UI needing to scale (4K circle menu is hilarious!). And the fonts within will need to scale together with the other elements. But the console is an independent system which does not suffer from the same issues, being merely a rectangular grid of characters.
I am not enthused about the fact that following the proposed change, it is impossible to configure the console font to a size that is independent of the window size. I want at least one of the following to be true:
Maybe you could make positive values of the cvar mean an absolute number of pixels and negative ones be relative or something.
I agree with the fact we must give people the ability to not scale the console, even if I think we also must provide a way to scale it. I personnaly think that scaling must be the default option because it ensures things are readable in an expected way in any way. By doing that we know that people can't get weird results unless there is a bug and we know what they must have so we can know if there is a bug or not. We have to assume people may have an hiDPI screen and to give something usable out of the box in such case.
But I agree that having the ability to disable console scaling to not have manually reduce the scale to get the default size is very OK, and it's also better than the only alternative offered by the current code. With such option it's only required to switch things from on to off without having to think more about it. We can define a cvar named like
There is already:
I think it would be good to add this cvar :
And that it would be better to set it to
I would like to see that, because for some time I really thoughts that there was a bug in dæmon since I was seeing no changes while tweaking it, even after a
If it's possible, we must at least make this change applied on
referenced this pull request
Feb 17, 2019
So, I added a new cvar named
For some unknown reason,