Add constants for commonly used colors

[Geometror]

This PR aims to improve readability by introducing constants for the most used/basic colors (red, green, blue, white, black, transparent white and transparent black).

• Replace Color(1.0, 1.0, 1.0, 1.0), Color(1.0, 1.0, 1.0), Color(1, 1, 1) and Color(1, 1, 1, 1) with Color::WHITE
• Replace Color(0.0, 0.0, 0.0, 1.0), Color(0.0, 0.0, 0.0), Color(0, 0, 0) and Color(0, 0, 0, 1) with Color::BLACK
• Replace Color(1.0, 1.0, 1.0, 0.0) and Color(1, 1, 1, 0) with Color::TRANSPARENT_WHITE
• Replace Color(0.0, 0.0, 0.0, 0.0) and Color(0, 0, 0, 0) with Color::TRANSPARENT_BLACK
• Replace Color(1.0, 0.0, 0.0, 1.0), Color(1.0, 0.0, 0.0), Color(1, 0, 0) and Color(1, 0, 0, 1) with Color::RED
• Replace Color(0.0, 1.0, 0.0, 1.0), Color(0.0, 1.0, 0.0), Color(0, 1, 0) and Color(0, 1, 0, 1) with Color::GREEN
• Replace Color(0.0, 0.0, 1.0, 1.0), Color(0.0, 0.0, 1.0), Color(0, 0, 1) and Color(0, 0, 1, 1) with Color::BLUE

[Calinou]

I agree on principle, but shouldn't we make named colors accessible from C++ instead? We already have a set of over 200 named colors accessible via constants in GDScript.

Also, it might be worth adding named colors for "transparent black" (Color(0, 0, 0, 0)) and "transparent white" (Color(1, 1, 1, 0)).

[Geometror]

I actually forgot that there are already named colors (and they are accesible from C++).
However, Color::get_named_color("WHITE") is significantly longer than Color::white() and the access is not as fast since the compiler can optimize the second method. so it basically acts like a true constant. In this regard this might be still relevant.

EDIT: Adding "transparent black" and "transparent white" would definitely make sense, there are over 120 occurrences of Color(0, 0, 0, 0) and Color(1, 1, 1, 0) together.

[Calinou]

However, Color::get_named_color("WHITE") is significantly longer than Color::white() and the access is not as fast since the compiler can optimize the second method. so it basically acts like a true constant. In this regard this might be still relevant.

Could we make those actual constants with some C++ macro/template magic? I agree we should avoid strings here (even StringNames, as they don't have autocompletion and are prone to typos).

[AaronRecord]

Why are they methods instead of just constexprs?

[Geometror]

@LightningAA Unfortunately, just using constexpr wouldn't work. As Color is not an integral type defining constants can be problematic (due to the way C++ handles this). I initially used methods for this as that is considered to be a safe way to avoid linker errors.

However, as I wasn't happy with it too, I changed it to the approach used by SFML (static const declaration and initialization in the implementation file). See the updated top comment for details.

[aaronfranke]

Why have Color::TRANSPARENT_WHITE when you can have Color(Color::WHITE, 0)? It's even slightly fewer characters long (22 instead of 24). #36379

[aaronfranke]

The latter could be Color::WHITE, but also I don't think it actually improves readability in this case, so I think keeping the numbers makes more sense.

[KoBeWi]

Suggested change

	clear_color = Color::BLACK; //in overdraw mode, BG should always be black
	clear_color = Color::BLACK; // In overdraw mode, BG should always be black.

You could fix the comment if you are editing this.

[KoBeWi]

The PR makes sense, but the list of colors is to be assessed. White color is by far the most commonly used one, but e.g. blue seems to be used 8 times. Although it's a primary color, so maybe makes sense to have it anyway, idk.

Also I support the idea that transparent colors can be simply achieved with Color(Color::WHITE, 0) instead of having their own constants (it's actually shorter to write).