Quote: "Are the RGB commands broken? The integer to Dword conversion is unavoidable, and I can't really think of a situation where another datatype would be used with that command."
There are more optimizations to do other than avoiding type casting. Take this for example,
rgb versus calculating the value manually:
red = 1
green = 2
blue = 3
time = perftimer()
for x = 1 to 10000000
color = blue || (green << 8) || (red << 16)
next x
time = perftimer() - time
print "Macro took "+str$(time)+"."
time = perftimer()
for x = 1 to 10000000
color = rgb(red, green, blue)
next x
time = perftimer() - time
print "Function took "+str$(time)+"."
wait key
On here it's faster to do it manually, although if I add in the alpha component it's actually slower. The actual idea is that putting the code in directly should be faster than calling a function to do the same thing. A macro would replace
rgb with the code itself. The same goes for
abs:
value = -5
time = perftimer()
for x = 1 to 10000000
if value < 0 then value = 0-value
next x
time = perftimer() - time
print "Macro took "+str$(time)+"."
time = perftimer()
for x = 1 to 10000000
value = abs(value)
next x
time = perftimer() - time
print "Function took "+str$(time)+"."
wait key
I wouldn't personally consider using a function for something that can be so easily done manually for more speed.
Quote: "It's not even really DBPs fault that the conversions are so slow, it's just how data types work."
Well I haven't really done a proper comparison, but it's pretty fast in C++ if that means anything.
