Jump to content
  • Advertisement
Sign in to follow this  
johnnyBravo

rgb values of a colour, storing them in one integer?

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi I remember a while ago about there being a way to store the rgb values of a colour into one integer, does anyone know how this is done? Like what is divided or added to do this?....or am i mistaken? And also do images eg bmp/jpeg only use rgb values, as in pro paint programs they seem to have other extra variables, which i can't think of right now. As I want to try make my own image compression format...just for fun. thx

Share this post


Link to post
Share on other sites
Advertisement
example 1 (better)


struct color{
unsigned char r;
unsigned char g;
unsigned char b;
unsigned char a;
};



example 2


typedef unsigned long color;

#define GET_RED(c) ((c>>0) &0xff)
#define GET_GREEN(c) ((c>>8) &0xff)
#define GET_BLUE(c) ((c>>16)&0xff)
#define GET_ALPHA(c) ((c>>24)&0xff)

#define COLOR(r,g,b,a) ((r<<0)|(g<<8)|(b<<16)|(a<<24))




You can also revert the order (ABGR instead of RGBA)

Share this post


Link to post
Share on other sites
when you start storing color values in an integer you have to worry about endianess. The number 0xff00ff00 is stored differently in unix vs windows. So you need to take that into account unless you just go with the hexidecimal numbers like I did above. If you try using a union or casting a struct, or if you do some bit shifting you will have to do endian stuff. Me, I don't do any color manipulation in my program so I just use hexidecimal literals and don't worry about it.

Share this post


Link to post
Share on other sites
Quote:
Original post by Glak
when you start storing color values in an integer you have to worry about endianess. The number 0xff00ff00 is stored differently in unix vs windows. So you need to take that into account unless you just go with the hexidecimal numbers like I did above. If you try using a union or casting a struct, or if you do some bit shifting you will have to do endian stuff. Me, I don't do any color manipulation in my program so I just use hexidecimal literals and don't worry about it.


This is true. This is also why I prefer the struct/array solution. It's faster, clear and you have not to 'swap' your bytes.

Share this post


Link to post
Share on other sites
well eventually you are going to want to pass the struct to a renderer, and that is when you have to worry about endian issues. The order of variables in the struct will have to be reversed on a computer with different endianess. Or you could use those htonl and ntohl functions to convert back and forth.

Share this post


Link to post
Share on other sites
Quote:
Original post by Glak
well eventually you are going to want to pass the struct to a renderer, and that is when you have to worry about endian issues. The order of variables in the struct will have to be reversed on a computer with different endianess. Or you could use those htonl and ntohl functions to convert back and forth.

Revert order of the variables? Sure? With integers ok...

Share this post


Link to post
Share on other sites
Quote:
Original post by Glak
when you start storing color values in an integer you have to worry about endianess. The number 0xff00ff00 is stored differently in unix vs windows.


Endianness is dependant on the hardware, not software.

Quote:
Original post by Glak
well eventually you are going to want to pass the struct to a renderer, and that is when you have to worry about endian issues. The order of variables in the struct will have to be reversed on a computer with different endianess. Or you could use those htonl and ntohl functions to convert back and forth.


Huh?

color->r will be the same on all hardware, regardless of endianness.

Share this post


Link to post
Share on other sites
Quote:
Original post by LewsTherin
Quote:
Original post by Glak
when you start storing color values in an integer you have to worry about endianess. The number 0xff00ff00 is stored differently in unix vs windows.


Endianness is dependant on the hardware, not software.

Quote:
Original post by Glak
well eventually you are going to want to pass the struct to a renderer, and that is when you have to worry about endian issues. The order of variables in the struct will have to be reversed on a computer with different endianess. Or you could use those htonl and ntohl functions to convert back and forth.


Huh?

color->r will be the same on all hardware, regardless of endianness.
Of course it will. What were you guys thinking? If you access the color components through byte members of a struct then there will be NO endian issues. End of story.

However, if you access the color components through the integer using bit-shifting etc, then you DO have endian issues.

Share this post


Link to post
Share on other sites
We have made everyone some confusion!!! [smile]

In practice big/little endianess is dependant on the hardware (processor) achitecture ( ie x86 little endian, Mac big endian ).

We do not need special considerations in the case of little/big endianness with some esceptions:

if we are going to cast 'this to that' we must consider the difference.

if we are writing a (binary) file we must specify the file type or use a conversion function to convert the data read (this is the most common case).

See also this nice article on GameDev

from the article we can write as test

bool IsLittleEndian(){
static char test[] = { 1, 0 };
return (( *(short*)test )&0xff) != 0;
}

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!