>> File Info Page <<

Taking up only 200 bytes, this draws circles about ten times faster than the TI-BASIC Circle( command, and even works with pixel-based values for more accuracy. It can be included and called as a function from any BASIC program or game; source code is in the readme. Preformatted for optional use with Doors CS.

I believe Kllrnohj made this as well.

He did it. Kllrnohj did it in C.

uh...the readme.txt file is bad, please reupload it

does your version work the same way as mine, by taking a 3 value long list in ans?

I figured someone would do this, as mine was huge for what it did (the cost of doing it in C) - i considered doing it myself (making it all ASM, so its smaller), but never got around to it

What do you mean the readme is bad? Is it corrupted? Mine works using A,B,R as the parameters.

yes, i mean it is corrupted



I doubt readme.txt is a mpeg, and neither gedit nor nano will display it (gedit says "invalid encoding" and nano gives me garbage)

however, i can view it using cat, but thats a hassle.... (and also reveals problems with the text, it appears you copy/pasted the source code, which doesn't work as the '->' symbol can't be represented in ASCII)

as for the proggy, i think mine can be drawn partially offscreen, why can't yours? also, why the choice of A,B,R over a list ans? TI-BASIC has few enough vars as it is, why take away 3 of them? (3 common ones at that)

Ohh, I know why you can't open it. It's unicode. not ascii.

plain text (.txt) files must be ASCII (while there are encoded .txt files, such as yours, they aren't well supported and they create problems). Choose another format if you want it to be unicode

so here it is in a properly encoded .rtf file (which allows unicode encoding)

http://www.kllrnohj.com/cemetech/misc/readme.rtf

I thought this was in ASM, but i now realize that it is in basic . Thats cool .

Thanks Harq. I've had this and a bunch of other proggies hanging around on my computer for a while; I might as well publish them as well.

10x faster than built in? please. I know you are trying to create exitement about the program, but that is a straight up lie that isn't even in the same universe as the truth

i just tried it out, and timed it, and it is barely faster than the built in circle( routing on an 84+SE. A bench of the two methods repeated 10 times put the circl() at 12 seconds and Kerm's routine at 9 seconds. Not even 1.4 times faster much less 10 times faster (both circle methods produced the same circle)

so change the file info page, change the description, change the readme, and say that it is 1.4x faster than the built in or however you want to word it, but you have to change that.

Actually, I timed filling the screen with radius-6 circles. The OS took 122 seconds, and mine took 13 seconds. Hence the 10x thing.

Post the code you used to time that

122 seconds?! Seems a little ridiculous...

This was about a month ago, when I first wrote the program. Seems to me those were the times, although I suppose they might be wrong. Let me retry the test when I get a chance.

doing this


Code:


and


Code:


gave the results of the built in at 33 seconds and Kerm's at 28 seconds, which gives Kerm's proggy a 1.2x faster speed. I'm still not finding anything close to 2x faster, much less 10x....

See, the thing is that I tested it with a very small radius, which of course artificially lowers the time. The TI-OS takes the same time to draw regardless of size, and this routine takes exponentially more time as radius increases.

Which calculators are you testing this on? Perhaps the 84 has an improved Circle feature...

I tested it on an 83+ regular. How about you, Kllrnohj?

ah, so you cheated, is that what you are saying?

repeating the bench with a radius of 3 gave circle( 32 seconds and Kerm's 6 seconds, but it is a deliberetly misleading number, so you still need to change your description

EDIT: I already said I am doing this on an 84+SE