-
Notifications
You must be signed in to change notification settings - Fork 53
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
Add full color mode option #851
Conversation
xsebek
commented
Nov 11, 2022
- closes Sometimes colors don't work #815
What does "full color mode" mean, exactly? And why would we not want it to be the default? |
@byorgey I think it means showing "a full 24-bit truecolor".
Not all terminals support this. Presumably, Brick/Vty try to autodetect this, but sometimes it does not work for an unknown reason. I could allow setting any of the Vty colour values so that even the terminals limited to a lower colour range can experiment with this. Or maybe someone could have (not set) a TERM value which is interpreted by Vty as only having 8bit colours. |
OK, sounds good. But in what sense does this solve #815 ? |
It allows you to override the default on the application side, isolating the problem. Consider this scenario: A hypothetical player named Peter will try to play Swarm, but it will show no colours.
|
Sure, that all sounds great, and I am in favor of adding this flag. But in case (3) we still have exactly the same issue represented by #815. So I still don't see why adding this flag resolves #815. Unless the idea is "well, we did what we could and it's not worth worrying about a rare, transient, unreproducible issue". |
@byorgey well, I am actually doing more than I could - I just added more options to select 8/16/full colour to see which one we really need. It turns out that with 8/16bit colours you get something like this: I did this to better understand #815 and also to improve the player experience when dealing with any terminal colour issue. I feel this should be enough to close our issue, given the response upstream. 🙂 |
Co-authored-by: Brent Yorgey <byorgey@gmail.com>