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

responsive: compute console font size from screen size #161

Merged
merged 1 commit into from Mar 9, 2019

Conversation

Projects
None yet
2 participants
@illwieckz
Copy link
Member

illwieckz commented Feb 16, 2019

This is a PR similar to Unvanquished/Unvanquished#1106 and UnvanquishedAssets/unvanquished_src.dpkdir#6

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.

A cl_consoleFontScaling is available for people who wants to disable console font scaling. Making this enabled by default ensures people have a readable console on hiDPI screens.

@slipher

This comment has been minimized.

Copy link
Contributor

slipher commented Feb 16, 2019

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.

@illwieckz

This comment has been minimized.

Copy link
Member Author

illwieckz commented Feb 16, 2019

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:

unvanquished responsive

But in 1080p it looks somewhat like that:

unvanquished responsive

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):

unvanquished responsive

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).

@illwieckz

This comment has been minimized.

Copy link
Member Author

illwieckz commented Feb 16, 2019

This is how console looked before:

unvanquished responsive

unvanquished responsive

This is how it looks now:

XGA:
unvanquished responsive XGA

HD1080 (FullHD):
unvanquished responsive HD1080

UHD (~4K):
unvanquished responsive UHD

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 cl_consoleFontSize (using seta and entirely restarting the engine).

@slipher

This comment has been minimized.

Copy link
Contributor

slipher commented Feb 17, 2019

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:

  • Console font can be resized without restarting the entire program.
  • Pixel-based console font size can be specified.

Maybe you could make positive values of the cvar mean an absolute number of pixels and negative ones be relative or something.

@illwieckz

This comment has been minimized.

Copy link
Member Author

illwieckz commented Feb 17, 2019

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 cl_consoleFontScaling people with advanced need can switch off. Once cl_consoleFontScaling would be set to off, cl_consoleFontSize becomes a pixel-based console font size people can specify this way.

There is already:

  • cl_consoleFont
  • cl_consoleFontSize
  • cl_consoleFontKerning

I think it would be good to add this cvar :

  • cl_consoleFontScaling

And that it would be better to set it to true so the behavior can be expected (i.e. we can expect how things are rendered on someone else's screen).


About this:

Console font can be resized without restarting the entire program.

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 vid_restart. I've only managed to get that value read by setting it with seta and quitting the engine and restarting it.

If it's possible, we must at least make this change applied on vid_restart. That may be another PR since it's another issue and since that issue preexists.

@illwieckz

This comment has been minimized.

Copy link
Member Author

illwieckz commented Mar 3, 2019

So, I added a new cvar named cl_consoleFontScaling that can be set to 0 to disable console font scaling. By default console font is scaled to make sure the console is properly readable on hiDPI screens.

For some unknown reason, cl_consoleFontScaling cvar suffers from the same problem cl_consoleFontSize does: it requires the engine to be entirely shut down and started again to get this cvar applied, vid_restart is not enough. That other issue is out of scope of this PR.

responsive: compute console font size from screen size
- compute console font size from screen size
- add a new cl_consoleFontScaling cvar that can be disabled
  to not scale console font size

@illwieckz illwieckz force-pushed the illwieckz:responsive branch from e61e64d to ef4565c Mar 9, 2019

@illwieckz illwieckz merged commit ef4565c into DaemonEngine:master Mar 9, 2019

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.