Make contrast of all player colors the same

[slrtbtfs]

This game currently suffers the problem that some player colors appear much darker to the human eye than others. Especially when using a projector the dark blue player is especially hard to recognize. This is both an accessibility problem and creates unfairness since some players are more well hidden than others.

This PR improves the issue by generating the player colors using the HSLuv color space. This causes all colors to appear roughly at the same brightness to humans.

Before:

After:

[slrtbtfs]

the diff is a bit inflated due to automated formatting, sorry about that

[slrtbtfs]

the diff is a bit inflated due to automated formatting, sorry about that

cleaned up the diff now for easier merging and review

[Draradech]

I'm a bit torn about this. I agree there are problems with the dark blue and violet player visibility. However, at least for me, it is much harder to tell which dot is which player in the hsluv case.

I also very much like the rainbow effect of the player list. I get what you are trying to do with the color distribution, and agree that it is the better solution if optimizing for different colors for low player counts. I still prefer the original solution for aesthetic reasons. (I also think it has a bug as is, for 6 players the resulting multiplier is 4, so player 4 has offset 3 * 360 / 6 * 4 = 720 -> same color as player 1).

I would still merge this if you make it a config option and remove the distribution changes.

config.c is a bit janky, but easy enough to work with. Make it default to 1, nobody is checking new options with default 0. I just need a way back for people who prefer the old colors (or may even need them for e.g. hardware controllers).

[slrtbtfs]

Thanks for the Feedback!

I'm a bit torn about this. I agree there are problems with the dark blue and violet player visibility. However, at least for me, it is much harder to tell which dot is which player in the hsluv case.

Yes, that is indeed not ideal.

I also very much like the rainbow effect of the player list. I get what you are trying to do with the color distribution, and agree that it is the better solution if optimizing for different colors for low player counts. I still prefer the original solution for aesthetic reasons. (I also think it has a bug as is, for 6 players the resulting multiplier is 4, so player 4 has offset 3 * 360 / 6 * 4 = 720 -> same color as player 1).

Oops, thanks for pointing out the math error. I agree that the rainbow is nice and it might be better to keep it.

I would still merge this if you make it a config option and remove the distribution changes.

config.c is a bit janky, but easy enough to work with. Make it default to 1, nobody is checking new options with default 0. I just need a way back for people who prefer the old colors (or may even need them for e.g. hardware controllers).

I don't really like the idea of making it an optional config option, since the goal of the PR was to solve the contrast problems for all players. I also agree that the current state of the PR might be not good enough as a default.

---

As an alternative, I'd propose to ditch the automatic color generation and instead hard code a list of 12 hand curated colors (more players aren't possible anyway).

That list should fulfill the following requirements:

• All colors should have sufficient and similar contrast to the background
• The first six colors should be a rainbow
• The colors should be reasonably well distinguishable. On the colors that are used for high player counts one way to reach this might be to not only vary hue, but also saturation and also include such colors as gray.

If you like that idea I can work on an PR for it.