Unit colors that match the player color #429
Labels
Comments
lmoureaux
added a commit
to lmoureaux/freeciv21
that referenced
this issue
Jul 8, 2022
We need a method to make sprites depend on the player color (see longturn#429). After some research, it seems that a standard technique involves shifting pixels in the image that have a specific hue. This is a quite simple method with very few free parameters; one could imagine changing the saturation and lightness as well to create "darker" or "more gray" nations. Create a class that encapsulates all of this so it's easy to change later. It generates colorized sprites on the fly (might create flicker as this is an expensive operation...) and caches them for later use. The sprites are only meant to be freed at tileset unload, so there is no way to clear the cache. See longturn#429.
lmoureaux
added a commit
to lmoureaux/freeciv21
that referenced
this issue
Jul 8, 2022
Allow tilesets to specify a new configuration key, "replaced_hue", that specifies the HSL hue that will be replaced by the hue of the player color in unit sprites. A single hue is used for the whole tileset to facilitate the implementation. The feature is disabled by default for backward compatibility and none of the shipped tilesets uses it. Closes longturn#429.
|
Demo of the WIP implementation in #1095 |
lmoureaux
added a commit
to lmoureaux/freeciv21
that referenced
this issue
Jul 9, 2022
We need a method to make sprites depend on the player color (see longturn#429). After some research, it seems that a standard technique involves shifting pixels in the image that have a specific hue. This is a quite simple method with very few free parameters; one could imagine changing the saturation and lightness as well to create "darker" or "more gray" nations. Create a class that encapsulates all of this so it's easy to change later. It generates colorized sprites on the fly (might create flicker as this is an expensive operation...) and caches them for later use. The sprites are only meant to be freed at tileset unload, so there is no way to clear the cache. See longturn#429.
lmoureaux
added a commit
to lmoureaux/freeciv21
that referenced
this issue
Jul 9, 2022
Allow tilesets to specify a new configuration key, "replaced_hue", that specifies the HSL hue that will be replaced by the hue of the player color in unit sprites. A single hue is used for the whole tileset to facilitate the implementation. The feature is disabled by default for backward compatibility and none of the shipped tilesets uses it. Closes longturn#429.
lmoureaux
added a commit
to lmoureaux/freeciv21
that referenced
this issue
Jul 9, 2022
As already done for units. See longturn#429, longturn#1095.
lmoureaux
added a commit
that referenced
this issue
Jul 9, 2022
We need a method to make sprites depend on the player color (see #429). After some research, it seems that a standard technique involves shifting pixels in the image that have a specific hue. This is a quite simple method with very few free parameters; one could imagine changing the saturation and lightness as well to create "darker" or "more gray" nations. Create a class that encapsulates all of this so it's easy to change later. It generates colorized sprites on the fly (might create flicker as this is an expensive operation...) and caches them for later use. The sprites are only meant to be freed at tileset unload, so there is no way to clear the cache. See #429.
lmoureaux
added a commit
to lmoureaux/freeciv21
that referenced
this issue
Jul 9, 2022
As already done for units. See longturn#429, longturn#1095.
lmoureaux
added a commit
to lmoureaux/freeciv21
that referenced
this issue
Jul 9, 2022
As already done for units. See longturn#429, longturn#1095.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It would be nice if we could replace some color in unit sprites by the player color. This would make opposing armies more distinct from each other, adding graphical depth to the game. Same for city colors.
I'm not sure how this is usually done to allow shading etc, so some research will be needed.
The text was updated successfully, but these errors were encountered: