Another small filled circe sub (not as fast as fcirc) - Printable Version +- 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) - bplus - 08-30-2024 Re: Petr No, it doesn't work for anyone because two lines are being drawn over the same spot. That's fine for non transparent colors but not for transparent colors. I have noticed something with these timed tests, the first one is so horrendous in time that it messes up the over all total so we are putting fcirc at disadvantage calling it first in these tests. To test this idea, I swicthed the right FC3 sub with fcirc in order so it is called first and now fcirc comes out the consistent winner: Code: (Select All) _Title "FC3 versus fcirc reverse order" ' b+ 2024-08-30 RE: Another small filled circe sub (not as fast as fcirc) - bplus - 08-30-2024 (08-30-2024, 02:35 PM)Petr Wrote: Bplus, color has data type unsigned long. You use the long data type in FC (variable clr&). Maybe that's why it doesn't work for you with transparent colors. Oh crap! everyone is using & not ~& for the color in the subs! Sorry @Petr, I missed that from the start of Dav's experiments! +1 to Petr BTW @Dav If you don't care about transparency then YES! there are faster ways to fill a circle, an extra line is nothing compared to an extra decision in a loop! RE: Another small filled circe sub (not as fast as fcirc) - Petr - 08-30-2024 I messed around with it and the transparency now works in both cases. For CircleFill I had to remove the BF parameter on the first LINE command. Code: (Select All)
A BEEP is to announce that FC3 has completed a circle, a SOUND is to announce that Fcirc has completed a circle. Testing doesn't work here, it was about transparency. RE: Another small filled circe sub (not as fast as fcirc) - bplus - 08-30-2024 OK here is the FC3 sub that you guys are not getting right: (update: Petr got it right but then put in Beep and Sleep?) Code: (Select All) Sub FC3 (cx, cy, r, clr~&) Don't use y2 and the extra decision in the loop. I just updated the sub for _Unsigned long color! Now to run these tests all over again! RE: Another small filled circe sub (not as fast as fcirc) - Dav - 08-30-2024 Sorry I messed up the SUB's, guys. When I make a mess, it's usually big. No, I'm not a politician. - Dav RE: Another small filled circe sub (not as fast as fcirc) - Petr - 08-30-2024 BPlus wrote: Petr got it right but then put in Beep and Sleep? Yes, I put beep and sleep in there to see for myself that the result is transparent. Now in both cases. RE: Another small filled circe sub (not as fast as fcirc) - Pete - 08-30-2024 Just a couple of things to point out, that I believe to be correct. 1) There should be no need to use INT() if we simply DIM x As Integer. Making the x variable an integer instead of a default single is faster. The system will convert the value automatically to an integer this way. 2) I assigned the variables to use in the SQR() calculation in the flat ellipse project as _Integer64. I discovered working with SQR() that this was required to avoid incorrect renderings with certain ellipse size numbers. 201 comes to mind. 3) Cobalt had mentioned that: " _SHL\_SHR are even faster if dealing with powers of 2." Well, I took a look at _SHL(y, 1) but unless I'm not familiar enough with bit flipping, this simply does not equal y ^2 or y * y. Also beyond 256 we have an issue, so I don't see making use of it. Am I wrong? Also thanks to Steve for trying out what I previously referred to as using a hash table lookup method. I know array processing is a bit sluggish in QB64, for whatever reason, so it was interesting to see that precalculated input using arrays is about a push, perhaps a hair faster. Couple this with the baggage and it is just not practical unless you are interested in filling a billion circles and don't have a second to waste. Pete RE: Another small filled circe sub (not as fast as fcirc) - bplus - 08-30-2024 +1 @Pete no need Int() is good point! why am missing all this? because I was modding off Dav. That's my excuse and I am sticking to it! -1 for me for that crap! @Dav it's good we are testing filled circle and not resting on past laurels. RE: Another small filled circe sub (not as fast as fcirc) - Petr - 08-30-2024 I see that in CircleFill I can leave the BF parameter at the first LINE statement. That's right. Steve always posts perfectly tuned treasures. And thanks to all of you for forcing me to let go of the IDE again. Guys, I have so much work, this is a holiday for me. RE: Another small filled circe sub (not as fast as fcirc) - Dav - 08-30-2024 This is a perfect example why it's good to have more eyes on your code to catch errors you overlook. - Dav |