Roku Developer Program

[Rek]

"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...

[NewManLiving]

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

[squirreltown]

"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.

[RokuMarkn]

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 >> 😎 AND 255
a = value AND 255

But I may not understand exactly what you're trying to do.

--Mark

[belltown]

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

[squirreltown]

"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.

[EnTerr]

"RokuMarkn" wrote:

r = (value >> 24) AND 255
g = (value >> 16) AND 255
b = (value >> 😎 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 8-) )

[EnTerr]

"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!

[squirreltown]

"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.

[Komag]

Is the reason those last two weren't properly "fixed" have to do with perfectly accurate binary representation being impossible for some decimals?