32bit Random Color Macro

[MrSwiss]

Hi all,

I've never really liked: RGB(Rnd() * 255, Rnd() * 255, Rnd() * 255) to obtain a random 32bit Color.
Therefore, I've done a NEW RndColor32 Macro (actually a #Define [single Line Macro]).
Additional explanations, like reasons and result, are below the test-code:

Code: Select all

' 32bit_Random_Color.bas, by MrSwiss - 2016-08-09
'
' play with different settings: w and h only! 640/480 | 800/600 | 1024/768
Const As Long w = 1280, h = 800, cd = 32    ' 16 x 10 = 160 squares per run
' const's to pre-calculate parameters, used in main code (based on: w and h)
Const As Long wm = w - 1, hm = h - 1
Const As Long st = w \ 80, sq = h \ 80

#Define RndColor32		( CULng( Rnd() * (&hFFFFFFFF - &hFF000000) + &hFF000000 ) )

ScreenRes w, h, cd  ' define window size and color depth
Randomize(Timer, 3) ' Mersenne Twister (-lang "FB" default), seed for Rnd()

Do
    ScreenLock
    For j As Long = 0 To hm Step st     ' top --> bottom loop (outer loop)
        For i As Long = 0 To wm Step st ' left --> right loop (inner loop)
            Line (i+1, j+1)-Step(sq, sq), RndColor32, BF
        Next
    Next
    ScreenUnLock

    Sleep 199       ' 200 - 1 mS run time (approx.)
Loop Until InKey() = Chr(255, 107)	' [X] click 

' using above RndColor32 Macro to obtain random color (full RGB() range)
' -----------------------------------------------------------------------
' The common way: RGB(rnd() * 255, rnd() * 255, rnd() * 255), which looks
' pretty awkward, compared to a single macro call RndColor32.
' Which is used and converted once (to ULong), instead of 3 times Rnd()
' and 3 explicit conversions, in the RGB() Macro (to UByte)!
' This means: more speed too!

[vdecampo]

Doesn't this work?

Code: Select all

Randomize
Dim As UInteger rclr = &hFFFFFF*Rnd

-Vince

[MrSwiss]

@vdecompo,

not certain, because it doesn't assure the minimum RGBA() of &hFF000000 ... (alpha set to 'opaque').
Secondly, Color is: either ULong or UInteger<32>, always (any compiler version, 32/64).

UInteger wastes 4 Bytes (every instance) on FBC 64! (For no benefit at all.)

[vdecampo]

@vdecompo,

not certain, because it doesn't assure the minimum RGBA() of &hFF000000 ... (alpha set to 'opaque').
Secondly, Color is: either ULong or UInteger<32>, always (any compiler version, 32/64).

UInteger wastes 4 Bytes (every instance) on FBC 64! (For no benefit at all.)

Code: Select all

Randomize
Dim As ULong rclr = &hFFFFFF*Rnd or &hFF000000

-Vince

[MrSwiss]

Dim As ULong rclr = &hFFFFFF*Rnd or &hFF000000

That works (but once only), not useful in Loop's ... Macro is more versatile, in this respect.

[dodicat]

long for 64 bit
integer for 32 bit

So, it would be safe to say always use long.(4 bytes in each compiler)
However, integer still remains the faster option for computations.

Code: Select all

dim as long x
dim as integer y
x=2
y=2
var limit=10000000
var n=0
dim as double t

t=timer
for n =0 to limit
    x=x^2-2^x-2
next n 
print timer-t ,x 
sleep 50


t=timer
for n =0 to limit
    y= y^2-2^y-2
next n 
print timer-t,y 
sleep 

[MrSwiss]

So, it would be safe to say always use long.(4 bytes in each compiler)
However, integer still remains the faster option for computations.

This may be true for computations, but not for Color = 32bit always.
Secondly, the 'forcing to ULong' comes last, in the sequence ...

[dodicat]

Even for color, the 64 bit defaults to uinteger.
The speeds, I admit are closer, but uinteger has the edge.

Code: Select all

screen 19,32
var clr=rgb(0,200,0)
#print typeof(clr)
print sizeof(clr)
print "wait, looping"

dim as uinteger clr1=rgb(0,200,0)
dim as ulong clr2=rgb(0,200,0)

dim as double t
do
t=timer
for n as integer=0 to 100000
circle(200,200),100,clr,,,,f
next n
locate 4,1
print timer-t,"uinteger"

sleep 50
t=timer
for n as long=0 to 100000
circle(200,200),100,clr2,,,,f
next n
print timer-t,"ulong"
loop until len(inkey)
sleep 

[MrSwiss]

... uinteger has the edge.

Yes, by a factor that can easily be forgotten (I don't do a 100'000 computations in the Macro).
Loop-Counters are a different matter (if they have a respectable size). Otherwise above applies too.

[dodicat]

Yea, well Mr Swiss.
I suppose it's because I don't really like the 64 bit fbc.

It is completely C and thus bound by Gcc.

My favourite is the 32 bit GAS.

[MrSwiss]

I suppose it's because I don't really like the 64 bit fbc.
It is completely C and thus bound by Gcc. My favourite is the 32 bit GAS.

Yes, dodicat, the likes/dislikes are personal, I guess.

I prefer FBC 64, on a 64bit system (irrespective of GAS/GCC) ...
However, I want code, that compiles with both Compilers (without any change).