Quake3 - vec4_t - colors

[owen_a]

Hey,

I'm trying to change the colours when I'm adding text to the menu screen. All I seem to have is "colour_red" in the UI. However, I'm trying to get colours Green and Grey, possibly blue. How would I go about adding these colours? I've done a little search in the code for "vec4_t" and came to this line defined under the Main_MenuDraw :

Code: Select all

vec4_t			color = {0.5, 0, 0, 1};

What do these values mean also, and are they in any mean related to what I'm trying to do? Thanks!

[tehSandwich]

I am in no way a programmer but I can tell that those four floats(?) are RGBA values. First is Red, second is Green, third is Blue and the last one is the Alpha value or the opacity.

[Eraser]

tehSandwich is correct. They are RGBA values. In your paint program, you're used to working with values ranging from 0 to 255. Here you use normalized values, which means that they range from 0.0 to 1.0
So a fully opaque bright red (which you'd define as 255, 0, 0, 255 in your paint program) is 1, 0, 0, 1.
Mix in a slight bit of blue and you'd get (for example) 1, 0, 0.5, 1
In your paint program that would be 255, 0, 127, 255

[MKJ]

i think alpha always goes in decimals, at least that's the standard.
but apart from that; what eraser said.

[Eraser]

In Paint.NET the alpha value is expressed in ints ranging from 0 - 255 as well

[MKJ]

what a cunt of a program

[obsidian]

Alpha for most image formats are stored as an additional 8-bits, so 256 values with a range between 0-255.

For example:
TGA offers 24-bit RGB with 8-bits per channel (8-bits/channel * 3 channels RGB = 24-bits), plus an optional alpha channel when stored as TGA-32 (8-bits/channel * 4 channels RGBA = 32-bits).



Quake 3's normalized values converts the channel values by dividing it by the total number of values (256). A 50% opacity would have an alpha value of 127 (halfway up the scale between 0-255).

So the proper math for this is: (127+1)/256=0.5

If you're wondering about why I'm incrementing: 0-255 is the range of values, but including the number zero, we have a total number of values of 256.

There is a bug in GtkRadiant where the colour values aren't properly being converted by the colour picker, so choosing a 50% value would result in a normalized value of 0.49609... or 0.50196... because of some dodgy math and failing to increment.

[owen_a]

Ah, I see now. Thanks for the help guys!

[Kaz]

There is a bug in GtkRadiant where the colour values aren't properly being converted by the colour picker, so choosing a 50% value would result in a normalized value of 0.49609... or 0.50196... because of some dodgy math and failing to increment.

Is that on the issue list somewhere?

[obsidian]

I reported it back when we were working on mfn's old ZeroRadiant branch. I haven't tested it against GtkRadiant 1.6.3, so it's not on TTimo's issue tracker yet.

https://github.com/mfn/GtkRadiant/issues/71

There's a bunch of stuff on mfn's branch that I've been meaning to revisit.