Method or Madness ;-))

[B+]

Rick, just to be clear I am comparing algorithms, NOT built-in fill circle which of course would be lightning fast! (which is why I don't think I need to know about Windows API calls. I don't know, I could be wrong.)

JJ, after some research, my graphics card is AMD Radeon HD 6319, CPU is AMD E-300 APU 1.3 GHz
How does this info help? I have junk, right?

So why are Ricks' SB times "kick ass" compared to mine but my SdlBasic 4342 ms runs rings around the 11222 ms time he gets?

eh, just another freaky thing with my system (that had it's hard drive replaced with a smaller one when I updated to Windows 10).

[ScriptBasic]

Here is a filled circle drawing example (512) with alpha channel support using Script BASIC and SDL.

   

Code: [Select]

    ' ScriptBasic GFX - Alpha Circles
     
    IMPORT gfx.inc
     
    scrn = gfx::Window(640, 480, "ScriptBasic GFX - Alpha Circles")
    ' Random Value Arrays
    RANDOMIZE(gfx::Time())
    FOR i = 0 TO 512
      rx[i] = RND() % 640
      ry[i] = 60 + RND() % 480 - 80
      rz[i] = RND() % 64
      rr[i] = RND() AND  255
      rg[i] = RND() AND  255
      rb[i] = RND() AND  255
      af = rx[i] / 640
      ra[i] = INT(255 * af)
    NEXT
     
    ts = gfx::Time()
    FOR i = 0 TO 512
      gfx::filledCircleRGBA scrn, rx[i], ry[i], rz[i], rr[i], rg[i], rb[i], ra[i]
    NEXT
    te = gfx::Time()
    gfx::stringColor scrn, 20, 15, "Time: " & FORMAT("%.4f",(te-ts)/1000) & " Seconds." & CHR(0), 0xffffffff
    gfx::Update
    WHILE gfx::KeyName(1) <> "+escape"
    WEND
    gfx::Close
     

[jj2007]

JJ, after some research, my graphics card is AMD Radeon HD 6319, CPU is AMD E-300 APU 1.3 GHz
How does this info help? I have junk, right?

No, you don't have junk. It's 399 points (mine) against 170 (yours), but that is OK.

But I really wonder what you are measuring. The time it takes to calculate a Bresenham circle? I doubt it, because even with these values, you need to tell the graphics card what to do with it, via the line command. And that command might be a lot slower than the math...

To illustrate the problem, here a snippet that prints 360x the sinus and cosinus, in double precision. That is more than enough to get a precise 300 pixel circle. The second loop is identical, except that it doesn't print the values, i.e. you get the pure calculation time. And it does the second loop 10,000 times. Check yourself how much time it needs on your PC.

include \masm32\MasmBasic\MasmBasic.inc      ; download
  SetGlobals REAL8 px, py, REAL10 pi180=0.01745329251994329577
  Init
  For_ ecx=0 To 359
      push ecx
      fld pi180
      fimul stack
      fsincos
      fstp py
      fstp px
      Print Str$(ecx), Str$("\t%Cf  \t", py), Str$("%Cf\n", px)
      pop eax
  Next
  NanoTimer()
  push 9999
  .Repeat
      xor ecx, ecx
      .Repeat
            push ecx
            fld pi180
            fimul stack
            fsincos
            fstp py
            fstp px
            ; no Print Str$(ecx), Str$("\t%f\t", py), Str$("%f\n", px)
            pop eax
            inc ecx
      .Until ecx>=360
      dec stack
  .Until Sign?
  pop edx
  Inkey Str$("10000 calculations took %i ms", NanoTimer(ms))
EndOfCode

[B+]

Hi John, I am alpha envious! very nice circles!

Hi JJ, Oh! I think I see what you are saying about graphics taking longer than calculations.
So minimize the number of lines being drawn... and get best times. So it's not about eliminating the Sqr Calc's, Bresenham (for SmallBASIC) is doing something better with line drawing, maybe?, that doesn't work (as well as starting with a filled square) for SdlBasic.