Quake3World

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 :
What do these values mean also, and are they in any mean related to what I'm trying to do? Thanks!

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.

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

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

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

what a cunt of a program

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.

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

obsidian wrote: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?

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.