I have this color: &h404040FF
if i print it i get - 1077952767 and the roku understands it if i spec that instead of the hex color.
but I can’t seem to find a hex/decimal/whatever conversion to get from:
this 1077952767
back to this:&h404040FF
thanks
Select from UINT for the dropdown, enter your decimal value, and click convert.
Thank you destruk, but i need to do it in my channel, so i need a formula, i’m just not finding the right one on the inter-tubes
On firmware 6.1 or later you can use StrI to format hexadecimal.
color = &h404040FF
? “&h” + UCase(StrI(color, 16))
“RokuKC” wrote:
On firmware 6.1 or later you can use StrI to format hexadecimal.color = &h404040FF
? “&h” + UCase(StrI(color, 16))
Thank you! I had found SrtI, but didn’t realize I could dump the whole color in there.
Ok so here are two colors:
varr.background = &h404040FF
? varr.background = 1077952767
color = 1077952767
? “&h” + UCase(StrI(color, 16)) = &h404040FF
however:
varr.blue = &h0889f7FF
? varr.blue = 143259647
color = 143259647
? “&h” + UCase(StrI(color, 16)) = &h889F7FF
which is only 5 digits for the color not 6 which results in a rather different color, a light yellow not a bright blue.
Whatsup here? the leading zero in the original blue hex spec? how to resolve this?
Thanks
Another case:
varr.red = &h911820FF
? varr.red = -1860689665
color = -1860689665
? “&h” + UCase(StrI(color, 16)) = &h-6EE7DF01
I seem to be missing something important here.
“squirreltown” wrote:
Another case:
varr.red = &h911820FF
? varr.red = -1860689665
color = -1860689665
? “&h” + UCase(StrI(color, 16)) = &h-6EE7DF01I seem to be missing something important here.
Yes, I see you are right and the color spec string would need to be left-padded with "0"s.
But if the hex conversion is treating it as signed, that is a problem… I did not realize it worked that way. 
At this point it is rather too hacky:
? “&h” + UCase((“000” + StrI(color >> 16, 16)).Right(4) + (“000” + StrI(color AND &hFFFF, 16)).Right(4))
But perhaps that would work. Sigh.
That seems to work, I tried it with the red and blue colors that failed before and they returned correctly.
So thank you, I would not have figured it out.
I looked up Integer Bitshift Operators and a dull haze surrounded everything so I stopped reading it.
As far as the hacky part goes, i won’t tell anyone if you don’t.
“squirreltown” wrote:
That seems to work, I tried it with the red and blue colors that failed before and they returned correctly.
So thank you, I would not have figured it out.
I looked up Integer Bitshift Operators and a dull haze surrounded everything so I stopped reading it.
As far as the hacky part goes, i won’t tell anyone if you don’t.
Just out of curiosity, why do you want to do this? In general, it seems like the hex color codes are easier to understand (just r,g,b,a components). The decimal representation has little to no value to a human…
These are some older functions that were found on other sites or were written by EnTerr ( Whom we have not heard from lately. Hope you are well sir ). They may offer a solution on previous versions as well
Function RGBtoHexString( a_r As Integer, a_g As Integer, a_b As Integer ) As String
l_rgb = LeftShift( a_r and &hFF, 16 ) or LeftShift( a_g and &hFF, 8 ) or a_b and &hFF
return IntegerToHexString ( l_rgb )
End Function
Function IntegerToHexString( a_number As Integer ) As String
l_hexDigits = ["0","1","2","3","4","5","6","7","8","9","A","B","C","D","E","F"]
l_hexString = ""
for l_i = 5 to 0 step -1
l_hexString = l_hexString + l_hexDigits[ RightShift( a_number, l_i * 4 ) and &hF ]
end for
return l_hexString + "FF"
End Function
Function RightShift( a_number As Integer, a_shift As Integer ) As Integer
if a_number > 0 then a_number = Int( a_number / ( 2 ^ a_shift ) )
return a_number
End Function
Function LeftShift( a_number As Integer, a_shift As Integer ) As Integer
if a_number > 0
for l_i = 1 to a_shift
l_number = a_number and &h40000000
a_number = ( a_number and &h3FFFFFFF ) * 2
if l_number then a_number = a_number or &h80000000
end for
end if
return a_number
End Function
Function HexToInteger( a_hex As String ) As Integer
l_bArr = CreateObject( "roByteArray" )
l_bArr.FromHexString( a_hex )
l_int = 0
for each l_byte in l_bArr : l_int = 256 * l_int + l_byte : end for
return l_int
End Function
Function RGBA_to_hex( a_R As Integer, a_G As Integer, a_B As Integer, a_A As Integer ) As String
l_b = createObject( "roByteArray" )
l_b[0] = a_R 'if >255, assignment trims it (as if "and &hFF")
l_b[1] = a_G
l_b[2] = a_B
l_b[3] = a_A
return l_b.toHexString()
End function
Function RGBA_to_int(R, G, B, A) As Integer
return &h1000000 * R + &h10000 * G + &h100 * B + A
End Function
“Rek” wrote:
Just out of curiosity, why do you want to do this? In general, it seems like the hex color codes are easier to understand (just r,g,b,a components). The decimal representation has little to no value to a human…
The Roku doesn’t seem to actually use the hex values, it converts them to decimal. So if you save a color as a variable, it saves it as a decimal value. I built a standard HSL color picker dialog box, with 3 sliders etc. The first thing it does is grab the current color of whatever you are changing, and i needed it in hex so I could convert to RGB.
NML - thank you for those, I already use some of them - a lot.
That’s not quite correct. All integers are stored internally as 32 bit binary values. Hex and decimal are just two human-readable ways to represent these binary values. You may be confused because when you PRINT an integer variable, it converts it to decimal and prints that value. But internally it’s always binary.
If you want to convert an integer value to rgb, I think the easiest way is something like this:
r = (value >> 24) AND 255
g = (value >> 16) AND 255
b = (value >> :smiling_face_with_sunglasses: AND 255
a = value AND 255
But I may not understand exactly what you’re trying to do.
–Mark
Wouldn’t it just be easier to save the color values as an AA, which your color picker can read and write? If the color value is only used by your color picker, why does it care what format it’s stored in? That might be a better implementation for the legacy Rokus which don’t support bit-shift operations:
color = {r: 235, g: 16, b: 16, a: 255}
Then if you really need to supply an integer value to a BrightScript function, you can get it from:
colorValue = ((color.r * 256 + color.g) * 256 + color.b) * 256) + color.a
“RokuMarkn” wrote:
If you want to convert an integer value to rgb, I think the easiest way is something like this:–Mark
Thank you, yes that works and is indeed a more elegant solution than what RokuKC came up with yesterday, but in either case, I don’t have a clue what bit-shifting is or does, so the answer to “why don’'t you do it this way?” is that i didn’t know you could. I’m looking for the first solution that works, whether I understand it or not, but I have to know it exists, and there certainly is no IntegertoRGB() function in the BS reference.
belltown - In hindsight it may make sense to do it that way ( although not now since i have Marks solution), and had I thought of it I might have done it that way, but I would rather have just one variable to keep track of.
“RokuMarkn” wrote:
r = (value >> 24) AND 255 g = (value >> 16) AND 255 b = (value >> :smiling_face_with_sunglasses: AND 255 a = value AND 255
RokuMarkn solution is the canon for firmwares with right bit-shift operator (>>). Here is an alternative that works on firmware 3 too:
function deRGBA(rgba):
ba = createObject("roByteArray")
for _ = 1 to 4:
ba.unshift(rgba and 255)
rgba = (rgba and -256) / 256
end for
return ba
end function
It gives you a byte array with components in [R, G, B, A] order. Examples:
BrightScript Debugger> ? deRGBA(&h0889f7FF).toHexString()
0889F7FF
BrightScript Debugger> ? deRGBA(&h911820FF).toHexString()
911820FF
BrightScript Debugger> ? deRGBA(&h0889f7FF)
8
137
247
255
BrightScript Debugger> ? deRGBA(&h911820FF)
145
24
32
255
Going off on a tangent: doing bit shifts with float division is incredibly finicky. I face-planted writing the short function above - twice. At first **rgba = int(rgba / 256)** (or fix(), no matter) seemed perfectly innocuous way to shift right one byte. The insidious part is that it works… most of the time. Except when you luck out with example like
BrightScript Debugger> ? &h0889f7ff / 256, &h0889f7
559608 559607 'first was expected to be 559607.xxxx
and realize it’s not int() nor fix() to blame but there was loss of precision because 4-byte-floats division was used. “Oh i know,” i thought - “i will force double division”. Young grasshopper, you have yet to master the kung-fu of BrightScript:
BrightScript Debugger> ? &h0889f7ff / 256d, int(&h0889f7ff / 256d), fix(&h0889f7ff / 256d)
559607.99609375 559608 559608 'last two totally should have been 559607
(Solving the mystery of the second failure left as exercise for the reader 
)
“NewManLiving” wrote:
These are some older functions that were found on other sites or were written by EnTerr ( Whom we have not heard from lately. Hope you are well sir ).
“There’s no need to fear, Underdog is here!” *
I was pre-occupied by personal reasons for couple of months. Today i looked up** myself in the forum and ran into this thread.
(*) i have watched 0 episodes of that show (temporal cause) but can’t resist the word-play temptation
(**) don’t try this at home, kids - every time you look yourself up, Dog kills a kitten! 
“EnTerr” wrote:
(**) don’t try this at home, kids - every time you look yourself up, Dog kills a kitten!
Well we certainly won’t be doing that, will we.
Is the reason those last two weren’t properly “fixed” have to do with perfectly accurate binary representation being impossible for some decimals?
