Anyone has any clue why the INT command is slowish? I made a program that draws 256 circles per loop, with three random commands (for the colors). Thinking that RGB didn't support decimals, I decided to use INT(). However, I got 1.5 images per second. I thought this wasn't that bad considering the three RANDOM commands, but when I removed the INT commands to see if RGB supported decimals, not only the program still worked, but now I can no longer count the frames per second I get.

EXPORT CIRCLE()
BEGIN
DIMGROB_P(G1,320,240,RGB(0,0,0));
WHILE 1 DO
FOR A FROM 1 TO 255 DO
ARC_P(G1,160,120,A,RGB(255*RANDOM,255*RANDOM,255*RANDOM));
END;
BLIT_P(G0,G1);
END;
END;
Not that I am complaining, but I was wondering why the INT command had more of an impact on speed than RANDOM, considering on the 84+ it was the opposite?

My guess would be that it is an OS-related issue and that it isn't properly utilizing the hardware.

Oh ok I was used to TI's int() command, which removes the decimal part from a number to create an integer. TI calcs also got IPart but I forgot the difference between Int() and IPart().

Also thanks for the RANDOM advice.

Well, Int is the mathematically defined function by n=Int(x) where n <= x < n+1 and n is an integer. IPart is the computer scientists' definition that just takes off the decimal part. You could write IPart(x) = x/|x| * Int(|x|).;

"ERR: Division by zero" is something you could see with that code you wrote. A workaround is to replace x/|x| with sign(x), or to make a special case when x=0.

Now that I know that I don't need to remove decimals for graphic commands and that INT is not the right command to use (and is slow), I decided to modify the program shown in this Critor video to compare the speed:

Here is your program video:

Now I get about 15 FPS!