Roku Developer Program

[dev42]

Exactly what do you mean by the color stops changing?
What color do you expect at 2147483647 + 1? If I had to guess *tries to find Calc... oh you RMB on the "start" button! that makes sense. ah, I see the Run command...* that would be &h7FFFFFFF + 1, right? And wouldn't that be an Alpha of 0?

But beyond all that, where are you getting this 2147483647? I thought you were converting from HSV.

BTW, you left out, "s = 0 then rgb = [v, v, v]" in your port. Dunno if that plays a factor in what you're trying to do, but figured I should mention it somewhere.

[dev42]

OK. Fine! It's Baby Blue. *grumbles*

I think I figured it out though... what should &h7FFFFFFF + 1 = ?

[spoiler=tricky computer math:1zasyl27]BrightScript Debugger> ? 2147483647
2147483647
BrightScript Debugger> ? 2147483647+1
2147483648
BrightScript Debugger> ? type(2147483647)
Double
BrightScript Debugger> ? type(2147483647-1)
Double
BrightScript Debugger> i% = 2147483647
BrightScript Debugger> ? i%
2147483647
BrightScript Debugger> ? int(2147483647)
2147483647
BrightScript Debugger> ? type(int(2147483647))
Integer
BrightScript Debugger> ? type(int(2147483647+1))
Integer[/spoiler:1zasyl27]
I've actually learned this before. Go figure.

BrightScript Debugger> i% = 2147483647 : ? i% + 1
[spoiler=only for the strong of heart:1zasyl27]BrightScript Debugger> ? i%+1
-2147483648

Hex for clarity... The "7" in &h7F... means "0111" in binary. The "0" is the bit that tells the sign. "0" = positive number, "1" = negative. Since BrightScript can't read your mind... it is assuming you want to use Doubles. You need Integers.

There are at least a couple ways to tell BrightScript you want Integers...[/spoiler:1zasyl27]

[dev42]

Not out of the woods yet...

BrightScript Debugger> ? int(2147483647+42)
2147483647 <<<===== Say, Whaaaaaaat?
BrightScript Debugger> ? int(2147483647)
2147483647
BrightScript Debugger> ? int(2147483647)+42
-2147483607 <<< this GOOD.
BrightScript Debugger> ? int(2147483647+42)
2147483647 <<< this BAD.
______________

Now on the LEFT I get a REDish gradient thing with a hard edge in the middle-ish due to the alpha cycling.

for hue = 0 to 360
	scr.DrawLine( 450,100+hue, 550,100+hue, int(2147483647)+hue)
	scr.DrawLine( 650,100+hue, 750,100+hue, int(2147483647)+(hue<<8))
end for

______________
So, the changes to the HSVtoRGB func that fixed this ( by pure luck! ) are the assigning the return value to Integer ( ... As Integer ) and the use of "%" at the end of the retval.

[Romans_I_XVI]

@dev42

Take a look at the second to last post on this thread.
viewtopic.php?f=34&t=84652&p=484454

Probably should have mentioned the earlier but couldn't remember where it was, plus I'm posting from my phone which is difficult (not home right now). RokuKC explains in depth the difference between a hex value and an integer.

Cheers

[dev42]

@Romans -

Thanks for that link! Awesome stuff there.

Now, is there still a problem? Because, to me at least, once the signed/unsigned issue is understood, it should become clear that, when talking about signed integers:
&hFFFFFFFF != 4294967295

&hFFFFFFFF == -1

still working on how the 64 bit Double gets clipped to the 32 bit Signed Integer.

Edit: Double is to Float as int is to char!
4294967295 == 0x41EFFFFFFFE00000 ==
01000001 11101111 11111111 11111111
11111111 11100000 00000000 00000000

but it is getting clipped... possibly taking the least significant 32 bits. ( chime in any time gurus! )
________________________

Wikipedia: 2's Complement

[EnTerr]

Dev42 - note that library int() function is (mis)defined as taking Float. If you pass Double, it will be down-converted to Float first - 4 bytes, one of which is exponent, so only ~3 bytes make it (25 bits or thereabout) - and only then to Int. You can make your own convertor Double->Int though (magic!) and explore:

BrightScript Debugger> toInt = function(x as Integer) as Integer: return x: end function
BrightScript Debugger> y = toInt(4294967295): ? y, type(y)
 2147483647            Integer
BrightScript Debugger> for x= 2#^31-3 to 2#^31+2: ? x, toInt(x): next
 2147483645             2147483645
 2147483646      2147483646
 2147483647      2147483647
 2147483648      2147483647
 2147483649      2147483647
 2147483650      2147483647

[EnTerr]

"Romans_I_XVI" wrote:
Glad you like it dev42 . How were you planning on implementing it though? I'm currently jumping through about 3 hoops. But it doesn't matter too much because I'm not running these functions often.

Hmm, the way you describe doing it is broken in principle. Not sure why/if you are getting the right results.

I start with that original HSVAtoRGBA function, which gives me a decimal. Then I have to pass it through this function.

It actually gives you a Double. There is no Decimal as such in B/S (Decimal is fairly rare type, i mostly know it in some DBs, also Java has BigDecimal).

function decToHex (dec as integer) as string

Here lies the problem. This function is declared to take Integer. So when you call it with a Double (from above) and that number is >2147483647#, it will get chopped to 2147483647 (MAXINT, 2^31-1). Which means when you call with R>=128, for any G, B, A you will be getting "7FFFFFFF" from that fn.

In my Brightscript I'm doing it like this.

 some_hex_color = val(decTohex(HSVAtoRGBA(hue,sat,100,255)),16)

Maybe calling it always with V=100, A=255 has saved your bacon so far, IDK. But check for colors with strong R, they should all be washing to cyan (?).

[squirreltown]

"EnTerr" wrote:
Maybe calling it always with V=100, A=255 has saved your bacon so far, IDK. But check for colors with strong R, they should all be washing to cyan (?).

Thats what I found, passing it pure red returned a really pale cyan. I already had another solution so i didnt pursue it though.

[dev42]

I haven't yet tried this with DrawObject and I'm not understanding the point of converting 2^32 to "decimal" and then use that as a color IF the HSVAtoRGBA() func is working as it should ...

The main tweak's to HSVAtoRGBA() are that it now uses Integers, Integer bit shifting which supposedly avoids the Double to Integer conversion issue, and returns an Integer. The function (latest ver) returned negative values and a spectrum from Red through all the hues back to Red... so, I was pleasantly content.

I did call out how fully I tested this. 😉

I'll dig deeper later.
__________________

"squirreltown" wrote:
Thats what I found, passing it pure red returned a really pale cyan. I already had another solution so i didn't pursue it though.

I did make mention of the "baby blue" :roll: ... and again, my changes to the HSV...() fixed it. No more "pale cyan". Could some kind soul test it out?

[Romans_I_XVI]

Sorry, the dectohex function I posted earlier is not the same as what I'm using, I forgot I removed that "As Integer" so it is not getting chopped off and I'm getting back the correct hex as a string, I just now tested it.