$FF0000FF <> RGBA(255, 0, 0, 255) .... why?

[Lebostein]

I don't undderstand that difference. RGBA should return a quad and not negative number?

Code: Select all

Debug $FF0000FF ; 4278190335
Debug RGBA(255, 0, 0, 255) ; -16776961

[User_Russian]

Code: Select all

Color1.l=$FF0000FF
Color2.i=$FF0000FF
Debug Color1 ; -16776961
Debug Color2 ; 4278190335
Debug RGBA(255, 0, 0, 255) ; -16776961

[Lebostein]

https://www.purebasic.com/documentation ... /rgba.html
return should not be long or integer. The manual says quad. Should not be negative.

[mestnyi]

The problem I think is in the return type. [.i .l]
He also tormented me a lot.
Oops I'm late it turns out

[Lebostein]

The problem I think is in the return type. [.i .l]
He also tormented me a lot.
Oops I'm late it turns out

No:

Code: Select all

color.q = RGBA(255,0,0,255)
Debug color ; -16776961

[Lebostein]

It seems the manual is wrong? It seems the return of RGBA is a 32 long

[Mesa]

Debug returns an integer
RGBA() returns a quad.

Code: Select all

Debug $F0000FF ; 4278190335 = 00000000FF0000FF => Because it IS AN INTEGER

Debug RGBA(255, 0, 0, 255) ; -16776961 = FFFFFFFFFF0000FF=> Because it IS A QUAD

Define rgb.q=RGBA(255, 0, 0, 255)
Debug rgb ;  -16776961
;ShowMemoryViewer(@rgb, 8)
Debug LSet(Hex(rgb, #PB_Quad), 16, "-"); FFFFFFFFFF0000FF

rgb = rgb  & $FFFFFFFF ; set high dw to 0
Debug rgb ;  4278190335 <<<=======                   
Debug LSet(Hex(rgb, #PB_Quad), 16, "-");FF0000FF--------
; ShowMemoryViewer(@rgb, 8)

Debug (RGBA(255, 0, 0, 255)  & $FFFFFFFF) ; -16776961 => something wrong with debug ?

M.

[SMaag]

Code: Select all

Q= $FF0000FF ; 4278190335
col= RGBA(255, 0, 0, 255) ; -16776961

Debug Q
Debug col

Q is set directly as quad value -> it's positive

col is converted inside RGBA form a Long to a Quad! That's a difference!

Because PureBasic do not support unsinged long, the long is negative and this negative long is converted to Quad.
Converting a negative Long to Quad will result in a negative Quad.

That is correct and not a bug.

[Mesa]

And remember how we make a negative number in binary:
https://en.wikipedia.org/wiki/Signed_nu ... sentations

[Lebostein]

can anone explain that irritating first line in the manual?
Color.q = RGBA(Red, Green, Blue, Alpha)
Why ist it needed to store the 32-Bit result in a quad?

Code: Select all

Define cl.l
Define cq.q
For r = 0 To 255
  For g = 0 To 255
    For b = 0 To 255
      For a = 0 To 255
        cl = RGBA(r,g,b,a)
        cq = RGBA(r,g,b,a)
        If cl <> cq
          MessageRequester("Error", "Error")
          End
        EndIf
      Next
    Next
  Next
Next

[SMaag]

Purebasic returns always a Quad as Color Value. That is a decision Fred made!

But you don't have to use a Quad. If you want, you can use a Long.
I always use Long for Color values.

If you know how a x86/x64 returns values you can see it makes no difference.

on 32Bit x86 the two Registers EAX/EDX are used to return a 64Bit Quad.
If you use a Quad-Color in your program, EAX and EDX is copied to your var.
If you use a Long, only EAX is copied to your var.

on x64 all values up to 64Bit are returned in RAX.

Now let's check what happens if we want to return a Color as Quad.
There is an ASM Command to convert an unsigned long to quad.
Because PB do not support unsigned long. PB always uses signed long to quad.
If you use a Long Color in the x64 program, only the EDX part will be copied to your var!

That's the reason!

Yes it seems crazy but it is correct!

[pfnuesu]

Did you see the remarks in the manual?

Result varies from 0 to 4 294 967 295 shades. It is therefore advisable to use a 'quad', (Result.q) and set unused bytes to zero.

So as per the manual:

Code: Select all

Q       = $FF0000FF                      ; 4278190335 
color.q = RGBA(255,0,0,255) & $FFFFFFFF  ; 4278190335
col     = RGBA(255, 0, 0, 255)           ;  -16776961

Debug q
Debug color 
Debug col

[mk-soft]

...

Code: Select all

col.l = RGBA(255,0,0,255)
Debug col
Debug StrU(col, #PB_Long)