Elaborate color explanation - Revision history

Cadillac at 15:06, 23 August 2021

2021-08-23T15:06:43Z

← Older revision		Revision as of 11:06, 23 August 2021
Line 95:		Line 95:
	The viewer's monitor's.		The viewer's monitor's.
	<!--&wpSummary=Please+revert+this+edit+and+ban+me%2E&wpTextBox1=%7E%7E%7E+spammed+this+page+and+deserves+a+ban.&-->		<!--&wpSummary=Please+revert+this+edit+and+ban+me%2E&wpTextBox1=%7E%7E%7E+spammed+this+page+and+deserves+a+ban.&-->

			[[Category:Customization]]

Jonathan: spam

2007-07-04T07:07:52Z

spam

Show changes

213.89.125.24 at 06:57, 4 July 2007

2007-07-04T06:57:07Z

Show changes

Jonathan: Reverted edits by 68.6.221.214 (Talk); changed back to last version by Wrtlprnft

2007-06-29T17:07:37Z

Reverted edits by 68.6.221.214 (Talk); changed back to last version by Wrtlprnft

Show changes

68.6.221.214 at 03:18, 29 June 2007

2007-06-29T03:18:43Z

Show changes

Wrtlprnft: Reverting. The last edit got cropped at the first & sign.

2007-06-14T05:27:11Z

Reverting. The last edit got cropped at the first & sign.

← Older revision		Revision as of 01:27, 14 June 2007
Line 2:		Line 2:

	== Player color entry ==		== Player color entry ==
	Normally, when entered in the player setup menu, colors are RGB triplets in the range 0..15. Players have found that they can get multi-color walls that are brighter than the cycle by manually setting COLOR_		Normally, when entered in the player setup menu, colors are RGB triplets in the range 0..15. Players have found that they can get multi-color walls that are brighter than the cycle by manually setting COLOR_<R, G, or B>_<player number> out of that range, using the console or by editing the configuration files. These settings are 32-bit signed integers with range -2147483648..2147483647.

			== Short color ==
			When a color is absorbed from the configuration items and stored in a player it is truncated to three 16-bit unsigned integers with range 0..65535. There is no benefit to choosing a color outside of that range in the configuration item. -65536 simply becomes 0, just like 65536 and 131072. -65535 and 65537 become 1, etc. I call this the short color after the short data type in C.

			== Float color ==
			The short color is then converted to 32-bit IEEE 754 floating-point, where 0..1 is the normal range. How that happens exactly depends on whether a team game is being played, but in both cases colors can be clamped to 0..15 beforehand. That has been added mainly because overflows could result in drastic deviations from the team color. '''''FIXME:''' is this entirely true and what is the config item? I only have old code.''

			=== Without teams ===
			The float color is simply the short color divided by 15.

			=== With teams ===
			In a team game the short color is combined with the team color which is another short color. It appears to be built around a balancing constant, an RGB triplet which specifies how much of the player's color is used instead of the team's. Its value is R=2 G=1 B=2. The calculation is:
			: O<sub>R</sub> = (B<sub>R</sub>P<sub>R</sub> + B<sub>S</sub>T<sub>R</sub>) / (15B<sub>S</sub> + 15B<sub>R</sub>)
			: O<sub>G</sub> = (B<sub>G</sub>P<sub>G</sub> + B<sub>S</sub>T<sub>G</sub>) / (15B<sub>S</sub> + 15B<sub>G</sub>)
			: O<sub>B</sub> = (B<sub>B</sub>P<sub>B</sub> + B<sub>S</sub>T<sub>B</sub>) / (15B<sub>S</sub> + 15B<sub>B</sub>)
			O is the output color, B is the balancing constant, P is the player color and T is the team color. Element S is the sum R+G+B=5. It could be a separate value, and it is, but both its name and its value suggest it is a sum.

			==== Standard team colors ====
			For your information, here is a table of the hardcoded team colors.
			{\|
			! Name !! R !! G !! B
			\|-
			\| Team blue \|\| 4 \|\| 8 \|\| 15
			\|-
			\| Team gold \|\| 15 \|\| 15 \|\| 4
			\|-
			\| Team red \|\| 15 \|\| 4 \|\| 4
			\|-
			\| Team green \|\| 4 \|\| 15 \|\| 4
			\|-
			\| Team violet \|\| 15 \|\| 4 \|\| 15
			\|-
			\| Team ugly \|\| 4 \|\| 15 \|\| 15
			\|-
			\| Team white \|\| 15 \|\| 15 \|\| 15
			\|-
			\| Team black \|\| 7 \|\| 7 \|\| 7
			\|}
			Note that if at least 50% of all players on a team have "Name Team after Player" set (bots and the leader are an implicit no, but are not excluded), the team will be given the leader's color and name. The leader in team naming/coloring context is the human who has been on his team for the longest time, or bot if there is none. See also [[Code hacks#Hardcoded teams]].

			== Floor color avoidance ==
			Armagetron has a mechanism that prevents colors from coming too close to the floor color. When a color is too close, it will be brightened until it's no longer close to the floor color or approaches white.

			We start off with several variables and a constant:
			; C : The color.
			; F : The floor color.
			; f : Some value specifying the degree of avoidance.
			; S : Sum of C's values, recalculated at the start of every loop.
			; s : Always 1/45.
			I admit choosing names which only differ in case isn't very good, but they're partly based on names used in the game.

			To enter the loop, the following condition must be true: (C<sub>R</sub> < 0.95 AND C<sub>G</sub> < 0.95 AND C<sub>B</sub> < 0.95) AND ((\|F<sub>R</sub> - C<sub>R</sub>f\| + \|F<sub>G</sub> - C<sub>G</sub>f\| + \|F<sub>B</sub> - C<sub>B</sub>f\| < 0.5) OR (\|C<sub>R</sub>f\| + \|C<sub>G</sub>f\| + \|C<sub>B</sub>f\| < 0.5)). The loop is:
			: S = C<sub>R</sub> + C<sub>G</sub> + C<sub>B</sub>
			: (The game only adds a component if it is < 0.99, but that is implied by the loop condition of < 0.95.)
			: If S < 0.02
			:: C<sub>R</sub> = C<sub>R</sub> + s
			:: C<sub>G</sub> = C<sub>G</sub> + s
			:: C<sub>B</sub> = C<sub>B</sub> + s
			: Else (S ≥ 0.02)
			:: C<sub>R</sub> = C<sub>R</sub> + sC<sub>R</sub>/S
			:: C<sub>G</sub> = C<sub>G</sub> + sC<sub>G</sub>/S
			:: C<sub>B</sub> = C<sub>B</sub> + sC<sub>B</sub>/S
			: C<sub>R</sub> = min(C<sub>R</sub>, 1)
			: C<sub>G</sub> = min(C<sub>G</sub>, 1)
			: C<sub>B</sub> = min(C<sub>B</sub>, 1)
			: If the aforementioned condition is still true, enter the loop again.
			C is the resulting color.

			== Text color ==
			The text color is the floating-point color, multiplied with 255 and converted to an 8-bit unsigned integer (0..255) by rounding toward zero and clamping in case of overflow. This is then put in a 0x color code.

			== Cycle color ==
			The cycle color is the floating-point color, passed through the floor color avoidance with f=1. This color will then be multiplied with 255, and converted to an 8-bit unsigned integer (0..255) by rounding toward zero and wrapping in case of overflow. The resulting color is then blended behind the cycle texture:
			* T<sub>R</sub> = (T<sub>A</sub>T<sub>R</sub> + (255 - T<sub>A</sub>)C<sub>R</sub>) / 256
			* T<sub>G</sub> = (T<sub>A</sub>T<sub>G</sub> + (255 - T<sub>A</sub>)C<sub>G</sub>) / 256
			* T<sub>B</sub> = (T<sub>A</sub>T<sub>B</sub> + (255 - T<sub>A</sub>)C<sub>B</sub>) / 256
			* T<sub>A</sub> = 255
			T is the texture color, and A is the alpha channel.

			== Wall color ==
			The wall color is the floating-point color, passed through the floor color avoidance with f=0.5. This color will be multiplied with 0.7..1 for every wall, depending on lighting. It is then passed to OpenGL which clamps it to 0..1, and multiplies the wall texture with it.

			== Multi-color tricks ==
			There are several ways to get multiple colors.
			* Due to different overflow behaviors, it is possible to have different cycle and wall colors. The cycle color wraps around, but the wall color will only get brighter in a limited way.
			* Because the wall color is lit before it is clamped, walls placed in different directions can have different colors when there's a slight overflow.

			It should be noted that this behavior is technically a bug and unsupported. It is merely tolerated.

			== Color space ==
			The viewer's monitor's.

66.45.252.82: Replacing page with 'Information about how player colors are processed exactly by Armagetron is scarce. The purpose of this article is to change that. I assumed certain data types, but I think Arma...'

2007-06-14T04:29:46Z

Replacing page with 'Information about how player colors are processed exactly by Armagetron is scarce. The purpose of this article is to change that. I assumed certain data types, but I think Arma...'

← Older revision		Revision as of 00:29, 14 June 2007
Line 2:		Line 2:

	== Player color entry ==		== Player color entry ==
	Normally, when entered in the player setup menu, colors are RGB triplets in the range 0..15. Players have found that they can get multi-color walls that are brighter than the cycle by manually setting COLOR_~~<R, G, or B>_<player number> out of that range, using the console or by editing the configuration files. These settings are 32-bit signed integers with range -2147483648..2147483647.~~		Normally, when entered in the player setup menu, colors are RGB triplets in the range 0..15. Players have found that they can get multi-color walls that are brighter than the cycle by manually setting COLOR_

	~~== Short color ==~~
	When a color is absorbed from the configuration items and stored in a player it is truncated to three 16-bit unsigned integers with range 0..65535. There is no benefit to choosing a color outside of that range in the configuration item. -65536 simply becomes 0, just like 65536 and 131072. -65535 and 65537 become 1, etc. I call this the short color after the short data type in C.

	~~== Float color ==~~
	The short color is then converted to 32-bit IEEE 754 floating-point, where 0..1 is the normal range. How that happens exactly depends on whether a team game is being played, but in both cases colors can be clamped to 0..15 beforehand. That has been added mainly because overflows could result in drastic deviations from the team color. '''''FIXME:''' is this entirely true and what is the config item? I only have old code.''

	~~=== Without teams ===~~
	~~The float color is simply the short color divided by 15.~~

	~~=== With teams ===~~
	In a team game the short color is combined with the team color which is another short color. It appears to be built around a balancing constant, an RGB triplet which specifies how much of the player's color is used instead of the team's. Its value is R=2 G=1 B=2. The calculation is:
	~~: O<sub>R</sub> = (B<sub>R</sub>P<sub>R</sub> + B<sub>S</sub>T<sub>R</sub>) / (15B<sub>S</sub> + 15B<sub>R</sub>)~~
	~~: O<sub>G</sub> = (B<sub>G</sub>P<sub>G</sub> + B<sub>S</sub>T<sub>G</sub>) / (15B<sub>S</sub> + 15B<sub>G</sub>)~~
	~~: O<sub>B</sub> = (B<sub>B</sub>P<sub>B</sub> + B<sub>S</sub>T<sub>B</sub>) / (15B<sub>S</sub> + 15B<sub>B</sub>)~~
	O is the output color, B is the balancing constant, P is the player color and T is the team color. Element S is the sum R+G+B=5. It could be a separate value, and it is, but both its name and its value suggest it is a sum.

	~~==== Standard team colors ====~~
	~~For your information, here is a table of the hardcoded team colors.~~
	{\|
	~~! Name !! R !! G !! B~~
	\|-
	~~\| Team blue \|\| 4 \|\| 8 \|\| 15~~
	\|-
	~~\| Team gold \|\| 15 \|\| 15 \|\| 4~~
	\|-
	~~\| Team red \|\| 15 \|\| 4 \|\| 4~~
	\|-
	~~\| Team green \|\| 4 \|\| 15 \|\| 4~~
	\|-
	~~\| Team violet \|\| 15 \|\| 4 \|\| 15~~
	\|-
	~~\| Team ugly \|\| 4 \|\| 15 \|\| 15~~
	\|-
	~~\| Team white \|\| 15 \|\| 15 \|\| 15~~
	\|-
	~~\| Team black \|\| 7 \|\| 7 \|\| 7~~
	\|}
	Note that if at least 50% of all players on a team have "Name Team after Player" set (bots and the leader are an implicit no, but are not excluded), the team will be given the leader's color and name. The leader in team naming/coloring context is the human who has been on his team for the longest time, or bot if there is none. See also [[Code hacks#Hardcoded teams]].

	~~== Floor color avoidance ==~~
	Armagetron has a mechanism that prevents colors from coming too close to the floor color. When a color is too close, it will be brightened until it's no longer close to the floor color or approaches white.

	~~We start off with several variables and a constant:~~
	~~; C : The color.~~
	~~; F : The floor color.~~
	~~; f : Some value specifying the degree of avoidance.~~
	~~; S : Sum of C's values, recalculated at the start of every loop.~~
	~~; s : Always 1/45.~~
	~~I admit choosing names which only differ in case isn't very good, but they're partly based on names used in the game.~~

	To enter the loop, the following condition must be true: (C<sub>R</sub> < 0.95 AND C<sub>G</sub> < 0.95 AND C<sub>B</sub> < 0.95) AND ((\|F<sub>R</sub> - C<sub>R</sub>f\| + \|F<sub>G</sub> - C<sub>G</sub>f\| + \|F<sub>B</sub> - C<sub>B</sub>f\| < 0.5) OR (\|C<sub>R</sub>f\| + \|C<sub>G</sub>f\| + \|C<sub>B</sub>f\| < 0.5)). The loop is:
	~~: S = C<sub>R</sub> + C<sub>G</sub> + C<sub>B</sub>~~
	~~: (The game only adds a component if it is < 0.99, but that is implied by the loop condition of < 0.95.)~~
	~~: If S < 0.02~~
	~~:: C<sub>R</sub> = C<sub>R</sub> + s~~
	~~:: C<sub>G</sub> = C<sub>G</sub> + s~~
	~~:: C<sub>B</sub> = C<sub>B</sub> + s~~
	~~: Else (S ≥ 0.02)~~
	~~:: C<sub>R</sub> = C<sub>R</sub> + sC<sub>R</sub>/S~~
	~~:: C<sub>G</sub> = C<sub>G</sub> + sC<sub>G</sub>/S~~
	~~:: C<sub>B</sub> = C<sub>B</sub> + sC<sub>B</sub>/S~~
	~~: C<sub>R</sub> = min(C<sub>R</sub>, 1)~~
	~~: C<sub>G</sub> = min(C<sub>G</sub>, 1)~~
	~~: C<sub>B</sub> = min(C<sub>B</sub>, 1)~~
	~~: If the aforementioned condition is still true, enter the loop again.~~
	~~C is the resulting color.~~

	~~== Text color ==~~
	The text color is the floating-point color, multiplied with 255 and converted to an 8-bit unsigned integer (0..255) by rounding toward zero and clamping in case of overflow. This is then put in a 0x color code.

	~~== Cycle color ==~~
	The cycle color is the floating-point color, passed through the floor color avoidance with f=1. This color will then be multiplied with 255, and converted to an 8-bit unsigned integer (0..255) by rounding toward zero and wrapping in case of overflow. The resulting color is then blended behind the cycle texture:
	* T<sub>R</sub> = (T<sub>A</sub>T<sub>R</sub> + (255 - T<sub>A</sub>)C<sub>R</sub>) / 256
	* T<sub>G</sub> = (T<sub>A</sub>T<sub>G</sub> + (255 - T<sub>A</sub>)C<sub>G</sub>) / 256
	* T<sub>B</sub> = (T<sub>A</sub>T<sub>B</sub> + (255 - T<sub>A</sub>)C<sub>B</sub>) / 256
	* T<sub>A</sub> = 255
	~~T is the texture color, and A is the alpha channel.~~

	~~== Wall color ==~~
	The wall color is the floating-point color, passed through the floor color avoidance with f=0.5. This color will be multiplied with 0.7..1 for every wall, depending on lighting. It is then passed to OpenGL which clamps it to 0..1, and multiplies the wall texture with it.

	~~== Multi-color tricks ==~~
	~~There are several ways to get multiple colors.~~
	* Due to different overflow behaviors, it is possible to have different cycle and wall colors. The cycle color wraps around, but the wall color will only get brighter in a limited way.
	* Because the wall color is lit before it is clamped, walls placed in different directions can have different colors when there's a slight overflow.

	~~It should be noted that this behavior is technically a bug and unsupported. It is merely tolerated.~~

	~~== Color space ==~~
	~~The viewer's monitor's.~~

Jonathan: Reverted edits by 211.160.179.81 (Talk); changed back to last version by Wrtlprnft

2007-05-10T08:50:57Z

Reverted edits by 211.160.179.81 (Talk); changed back to last version by Wrtlprnft

Show changes

211.160.179.81 at 05:06, 10 May 2007

2007-05-10T05:06:48Z

Show changes

Wrtlprnft: Reverted edits by 68.87.66.148 (Talk); changed back to last version by Jonathan

2007-05-04T16:09:36Z

Reverted edits by 68.87.66.148 (Talk); changed back to last version by Jonathan

Show changes