world.Note(world.ColourNameToRGB('blue')) displays 16711680, or 0xFF0000. Shouldn't this be 0x0000FF or 255, in RGB order, or am I missing something? -Tsunami
ColourNameToRGB
Posted by Tsunami on Sun 03 Jun 2007 06:40 PM — 12 posts, 43,118 views.
16711680 is the Lua colour code for blue (#0000FF). If you are using Lua as a script language, then that is the appropriate value returned. ColourNameToRGB just translates a word form of a colour to something that various functions can use.
I'm not sure where the 0xFF0000 came from. I just get the 16711680 when I run Note(ColourNameToRGB('blue'))
I'm not sure where the 0xFF0000 came from. I just get the 16711680 when I run Note(ColourNameToRGB('blue'))
Bah, nevermind... I figured it out. Lua is backwards, it's using a BGR format instead of RGB like everything else does. world.Note(world.ColourNameToRGB('red')) printed out 255, and world.Note(world.ColourNameToRGB('green')) yielded a result of 32768. The colours come out correct though, which is the important part. Unless you are using a script to modify colours or something.
I'm passing the information to Java, which is why it's annoying, to say the least. Is it only Lua that uses BGR? And why?
Yes, it is the only one. And I have no idea why... Every example of colours in Lua I found using Google. had it RGB, except for links back to MUSHclient.
Quote:
Lua is backwards, it's using a BGR format instead of RGB like everything else does.
Lua is backwards, it's using a BGR format instead of RGB like everything else does.
It is nothing to do with Lua. In C, it will be the same.
RGB is red/green/blue, right?
So, red is the lower-order byte (it comes first).
Green is next, and is multiplied by 256.
Blue is last, and is multiplied by 65536.
Languages like Lua, Java, C, Fortran, etc. etc. will all represent (as hex codes) the colours in that order, that is:
0xBBGGRR
However in HTML they rearranged things to be in "human" order, and write it as:
#RRGGBB.
The very first result I got when I Googled "rgb macro" is this page:
http://www.functionx.com/win32/Lesson12.htm
This explains quite well, that red is the low-order byte for a RGB colour, green is the middle-order byte, and blue is the high-order byte.
Thus an "all red" code would be: 0x0000FF
An "all green" code would be: 0x00FF00
An "all blue" code would be: 0xFF0000
You can also look at various page which describes how the Windows "RGB" macro works:
Again, you can see that red is in the low-order byte, green is shifted left by 8 bits, and blue is shifted left by 16 bits.
All this shows that it is nothing to do with Lua.
http://www.functionx.com/win32/Lesson12.htm
This explains quite well, that red is the low-order byte for a RGB colour, green is the middle-order byte, and blue is the high-order byte.
Thus an "all red" code would be: 0x0000FF
An "all green" code would be: 0x00FF00
An "all blue" code would be: 0xFF0000
You can also look at various page which describes how the Windows "RGB" macro works:
#define RGB(r, g ,b) ((DWORD) (((BYTE) (r) | \
((WORD) (g) << 8)) | \
(((DWORD) (BYTE) (b)) << 16)))
Again, you can see that red is in the low-order byte, green is shifted left by 8 bits, and blue is shifted left by 16 bits.
All this shows that it is nothing to do with Lua.
That does make a good deal of sense, since that's how I figured out what was going on. The ColourNameToRGB function return whatever is appropriate to the language calling it, right? The only complication that should come in is if you are passing colours back and forth between plugins which use different languages.
I don't think different languages would use different conventions. That would be extremely strange. R is the low byte, G is middle, B is high, end of story (according to the standard). The only problem I could see would be if you were passing these numbers to machines architectures with different endianness, but somehow I doubt that would be an issue with MUSHclient... :-)
Quote:
The ColourNameToRGB function return whatever is appropriate to the language calling it, right?
The ColourNameToRGB function return whatever is appropriate to the language calling it, right?
No, it returns a number along the lines of what I described. The language is irrelevant. Try this line of code and it will work in all languages, after adjusting for language syntax:
ColourNote (RGBColourToName (16711680), "", "test")
This displays "test" in blue. That exact example works in Lua and JScript, and you remove the brackets for VBscript:
ColourNote RGBColourToName (16711680), "", "test"
The point is, the number 16711680 is "blue", regardless of language. If you use the MUSHclient colour picker, it simply represents that number in different ways:
MXP (ie. HTML format): #0000FF
VBscript: &hFF0000
JScript: 0xFF0000
Lua: 16711680
The difference between VBscript and Jscript is just the way they represent hex numbers, and since Lua doesn't have a way of (simply) using hex literals, we have to use the decimal format.
You could represent it other ways too:
Octal: 77600000
Binary: 111111110000000000000000
Individual bytes: red: 0, green: 0, blue: 255
It is all the same number, it is just the way you look at it.
I thought that if you used ColourNameToRGB with VBscript or Jscript, it returned a hex value instead of decimal. Since Lua doesn't have hex as a default number format, it can't show hex. I hadn't read the helpfile which shows that it just returns the number in decimal for all of them. The part that I was getting confused with was allowing to have HTML colour codes allowed in as a colour name.
So the problem is really that the function outputs the code as the computer expects it, BGR, while the Java function expects human input, RGB. Ok, thanks! Just switched the high and low bits, and all is working as expected.