# Simple Color Problems

This topic is 5149 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I seem to be having some problems controlling the colors of my vertices. The problem is this: OpenGL as far as a can remember from my old days of programming, requires that the color values range from 0 to 1, with 1 being the equivalent of 255 in the old way of defining the value of a color (that is 8bit Red, 8bit Green, 8bit Blue, 8bit Alpha). Anyway, the problem is that both the GameDev tutorial and the BREW stuff automatically get all happy about their integer to fixed point converter, which in this case is totally useless, as it means that only 9 distinct colors are actually possible. Now, if I decide to make my colors into floating point values and then pass them into GL as fixed point values, it seems to just assume that any value other than 0, is in fact 1, which puts me back at the initial problem. Has anyone else encountered this problem? And more importantly, has anyone been able to utilize the full color spectrum that should be available?

##### Share on other sites
i've definitely been able to use the full color spectrum. AFAIK there's a way to specify that you'd like to use fixed point values 0-255 instead of the 0-1 values. i have no idea what you mean by:

Quote:
 the problem is that both the GameDev tutorial and the BREW stuff automatically get all happy about their integer to fixed point converter

why not just remove whatever is preventing you from passing values from 0-1? are you accidentally doing integer division instead of float division? step through in a debugger and make sure that the values being passes to opengl are actually the right ones and go from there.

-me

##### Share on other sites
Alright, I seem to have solved the problem, at least to some extent.

If you make an additional conversion macro like such:

#define ITOFP2(x) ((x)<<8)

and use this to convert your RGB values, assuming that the values range from 0 to 255 with 255 being full saturation.

This ends up working quite well, but it assumes a few things that seem very strange, first it assumes that GL is taking the values from 0 to 255 rather than 0 to 1, which I guess is the case.

Although more perturbing is the fact that it is only moving 8 places, suggesting a possible problem with the assumption that BREW uses 16.16 fixed point values.

##### Share on other sites
Thanks for the suggestion about checking the values Palidine, the debugger will definitely tell me what the hell is happing here.

##### Share on other sites
Nevermind my previous babble. The problem is that GL by default wants the values as 0-1, but I seem to have had some problems with my floating point conversion macro, and so by making a new integer conversion macro that uses 2^8 instead of 2^16, I have simple made my integers into fractions.

255*2^8 = 2^16 (approximately)

##### Share on other sites
You could also just use unsigned bytes to use the 0-255 approach, if that's easier for you (and specify GL_UNSIGNED_BYTE when calling glColorPointer).

##### Share on other sites
Really?

I thought that all the values passed to OpenGL ES functions had to be GL_FIXED.

I know that with a PC you could pass UNSIGNED, but I thought that was one of the key points to ES

##### Share on other sites
Not at all. Fixed just takes the place of float in Common light implementations. Integer types are still supported, though there are a few changes. For example, you can't pass an array of unsigned ints to glDrawElements, but you can pass unsigned bytes or unsigned shorts.

1. 1
Rutin
31
2. 2
3. 3
4. 4
5. 5

• 13
• 17
• 11
• 10
• 14
• ### Forum Statistics

• Total Topics
632962
• Total Posts
3009506
• ### Who's Online (See full list)

There are no registered users currently online

×