Another small filled circe sub (not as fast as fcirc)

[Dav]

I found an issue with my FC SUB.  Sometimes balls had stripes in them, when assigning cx/xy values that ended in .5, (like 100.5) and the radius didn't, (like 50).  (It didn't happen if the radius also ended in .5)

I think it's because I was not using integer for those values.  It was an easy fix - after declaring all three of those values as integers the balls will now always display without any artifacts no matter what values you give.

The program below shows the problem and fixed SUB (you may have to go fullscreen to see the stripes in the first set of balls.)

- Dav

Code: (Select All)

Screen _NewImage(1000, 800, 32)



'old one that shows stripes

fc.old 200.5, 200.5, 100, _RGB(255, 255, 255, 255), 0

fc.old 200.5, 400.5, 100, _RGB(255, 255, 255, 255), 1



'new one that shows normal

fc.new 400.5, 200.5, 100, _RGB(255, 255, 255, 255), 0

fc.new 400.5, 400.5, 100, _RGB(255, 255, 255, 255), 1



Sub fc.old (cx, cy, radius, clr~&, grad)

    If radius = 0 Then Exit Sub ' safety bail

    If grad = 1 Then

        red = _Red32(clr~&)

        grn = _Green32(clr~&)

        blu = _Blue32(clr~&)

        alpha = _Alpha32(clr~&)

    End If

    r2 = radius * radius

    For y = -radius To radius

        x = Sqr(r2 - y * y)

        ' If doing gradient

        If grad = 1 Then

            For i = -x To x

                dis = Sqr(i * i + y * y) / radius

                red2 = red * (1 - dis) + (red / 2) * dis

                grn2 = grn * (1 - dis) + (grn / 2) * dis

                blu2 = blu * (1 - dis) + (blu / 2) * dis

                clr2~& = _RGBA(red2, grn2, blu2, alpha)

                Line (cx + i, cy + y)-(cx + i, cy + y), clr2~&, BF

            Next

        Else

            Line (cx - x, cy + y)-(cx + x, cy + y), clr~&, BF

        End If

    Next

End Sub



Sub fc.new (cx As Integer, cy As Integer, radius As Integer, clr~&, grad)

    If radius = 0 Then Exit Sub ' safety bail

    If grad = 1 Then

        red = _Red32(clr~&)

        grn = _Green32(clr~&)

        blu = _Blue32(clr~&)

        alpha = _Alpha32(clr~&)

    End If

    r2 = radius * radius

    For y = -radius To radius

        x = Sqr(r2 - y * y)

        ' If doing gradient

        If grad = 1 Then

            For i = -x To x

                dis = Sqr(i * i + y * y) / radius

                red2 = red * (1 - dis) + (red / 2) * dis

                grn2 = grn * (1 - dis) + (grn / 2) * dis

                blu2 = blu * (1 - dis) + (blu / 2) * dis

                clr2~& = _RGBA(red2, grn2, blu2, alpha)

                Line (cx + i, cy + y)-(cx + i, cy + y), clr2~&, BF

            Next

        Else

            Line (cx - x, cy + y)-(cx + x, cy + y), clr~&, BF

        End If

    Next

End Sub

[Pete]

Hi Dav,

You might have seen my flat ellipse reference where problems resulted in early testing with SQR() until I changed the values in that equation to _INTEGER64. You may need to do the same with circle fill if you find any other values that throw a floating point error.

Pete

[Dav]

Hmm, I'll check it out.  Thanks, Pete.

- Dav  

 (I use to go by David, but someone stole my id)

[bplus]

Well I think any integer type would fix.

I always thought line converted inputs to integer, oh well another myth blown up!

Ha! at .5's only, like it can't decide which way to round!

[Pete]

It has to do with the floating point precision. _INTEGER64 provides enough precision to use in the flat ellipse SQR() method. INT() did not. Now the LINE function sounds interesting. Of course it has to pick an integer value, but this sounds like it calculates those values differently.

@Dav (I use to go by David, but someone stole my id) +1, funny. Dav id's not here, man!

Pete

[bplus]

You know those "gridded" balls that Dav show us reminded me of Luke telling us they were using a bankers way of rounding one time round up the next round down and repeat...

That would result in exactly those "gridded" balls from all the .5's

Re: Pete Long would be big enough to cover X or Y Squared from a screen coodinate. The extra bits needed for _Integer64 would waste time.
In fact make them all Long so you don't have to mix math Types in the revised FC is my advice.