+- QB64 Phoenix Edition (https://qb64phoenix.com/forum)
+-- Forum: QB64 Rising (https://qb64phoenix.com/forum/forumdisplay.php?fid=1)
+--- Forum: Code and Stuff (https://qb64phoenix.com/forum/forumdisplay.php?fid=3)
+---- Forum: Programs (https://qb64phoenix.com/forum/forumdisplay.php?fid=7)
+---- Thread: Another small filled circe sub (not as fast as fcirc) (/showthread.php?tid=2989)
RE: Another small filled circe sub (not as fast as fcirc) - Dav - 09-05-2024
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
RE: Another small filled circe sub (not as fast as fcirc) - Pete - 09-05-2024
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
RE: Another small filled circe sub (not as fast as fcirc) - Dav - 09-05-2024
Hmm, I'll check it out. Thanks, Pete.
- Dav
(I use to go by David, but someone stole my id)
RE: Another small filled circe sub (not as fast as fcirc) - bplus - 09-05-2024
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!
RE: Another small filled circe sub (not as fast as fcirc) - Pete - 09-06-2024
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
RE: Another small filled circe sub (not as fast as fcirc) - bplus - 09-06-2024
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.