Support Immutable Color
See original GitHub issueWe are running into an issue where a static Color stored in the Colors map is being changed - so that the shared Color used across the game changes also. (i.e “BLACK” was changed to no longer be black)
While we’ve fixed the cause of this, it isn’t possible currently to make a Color object that enforces this. The r
g
b
values are public, which means there is no easy way to subclass Color to make an “UnchangeableColor” class. There are hundreds of direct references to these public variables in the libGDX codebase.
Here’s what i’d propose:
- Replace the
public float r, g, b, a
with getters and setters. - Create an unchangeable Color class that is only set in the constructor and use it for colors like “BLACK” and “RED” which should never be accidentally changed, and optionally for any unchangable colors that a game wants to add to the Colors map.
Thoughts?
Issue Analytics
- State:
- Created 8 years ago
- Comments:20 (18 by maintainers)
Top Results From Across the Web
immutable-color - npm
Immutable color manipulator. Latest version: 0.1.6, last published: 6 years ago. Start using immutable-color in your project by running `npm ...
Read more >Brand Guidelines - Immutable X
Immutable, Immutable X and Immutable Games Studio brand guidelines. ... The weighted palette shows the desired distribution of colour across the brand.
Read more >Setting Colors
Color objects are like String objects: they are immutable. That is, once a Color object has been created, it can not be changed....
Read more >The 22 Immutable Laws of Branding: Part 9 of 12
A brand should use a color that is the opposite of its major competitor. Make a brand distinctive with color. There are 5...
Read more >NSColor | Apple Developer Documentation
Color objects are immutable and thread-safe. ... is a programmer error to access color components of a color space that the NSColor object...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I apologize for bringing this up again, but I’ve had a similar design problem in my game engine and here’s how I solved it:
I still was able to use the Color class everywhere - and also added methods to accept a ColorInterface when it made sense. In some places I had ColorInterface (like the background color of the window) because it wasn’t a place that was going to have heavy modifications to the color.
Not sure if this is of any help, but there it is!
Seems like basic getters/setters are inlined by the JIT on Android as of Gingerbread (2.3). ART I would imagine might even do this AOT.
http://stackoverflow.com/questions/4912695/what-optimizations-can-i-expect-from-dalvik-and-the-android-toolchain/4930538#4930538