Omnimaga
Calculator Community => TI Calculators => TI-BASIC => Topic started by: Freyaday on February 25, 2011, 03:47:30 pm
-
My BASIC program Macro is a drawing tool. There are 8 drawing commands available, and the coordinates for each are recorded and stored, along with the command number, in a single element of LM. It's almost done, but it's missing a desperately needed feature: An undo button. I can't just do the opposite of the command that was just performed, because that could change pixels that weren't changed by the instruction being undone. The only way I can see to circumvent this situation would be to remove the last element of the list and call Read to redraw the whole thing, which would be an absolute pain. Can anyone think up a more efficient way to implement an undo feature?
-
My BASIC program Macro is a drawing tool. There are 8 drawing commands available, and the coordinates for each are recorded and stored, along with the command number, in a single element of LM. It's almost done, but it's missing a desperately needed feature: An undo button. I can't just do the opposite of the command that was just performed, because that could change pixels that weren't changed by the instruction being undone. The only way I can see to circumvent this situation would be to remove the last element of the list and call Read to redraw the whole thing, which would be an absolute pain. Can anyone think up a more efficient way to implement an undo feature?
In computer programs, what is usually done is to save all the things that are done and then undo them, but this is theory, I have no idea about the practical way of 'Undo' in Basic.
-
Before every action, you could store the screen to an OS Pic variable, and then using Undo would recall the pic var onto the screen, effectively "undoing" the last action :)
-
Before every action, you could store the screen to an OS Pic variable, and then using Undo would recall the pic var onto the screen, effectively "undoing" the last action :)
But that would only allow one undo. That's not enough. I want the ability to undo ad infinitum.
-
Before every action, you could store the screen to an OS Pic variable, and then using Undo would recall the pic var onto the screen, effectively "undoing" the last action :)
But that would only allow one undo. That's not enough. I want the ability to undo ad infinitum.
Then it'd requite saving infinite Pic Variables, but they are finite.
-
Then it'd requite saving infinite Pic Variables, but they are finite.
Hence the necessity of another method.
-
I basic that would be really, really hard. I'd say cap it to 5 undos or so and use Pic Variables. ;)
-
I think you could use the algorithm of a snake.
And what algorithm would that be?
-
the ability to undo ad infinitum.
Even photoshop doesn't have this :P
-
I'd be curious about where the RAM to store all of that information is. TI-BASIC doesn't give you access to a whole lot of memory with which to store data.
However, I made a CAD tool awhile back in BASIC and here's what I did:
Every time the user drew a point, the 3D spatial coordinates of that point would be stored in an array in sequential order. When the user needed to erase something, the program searched searched the list for a point close to the cursor and erased it. All elements after the deleted element were then placed in a temporary list and the lists then augmented together again to remove that element. The location on the screen that corresponded to the coordinates was simultaneously erased pixel by pixel. That way, the point would be erased until the next time the screen needed to be redrawn, at which the point would not show up because it was no longer present in the array.
-
It is only to store the last coordonates. To redraw everything, you must use picvars. Maybe an Axe subprogram could help you ?
-
Yeah one issue with multiple undos is that it would take loads of memory. Even some computer programs lets the user set a limit on undos, because otherwise they run out of RAM quick.
-
DJ, yeah. The only program I've ever seen advertise "unlimited undos" was HxD, which has a much easier task of it than most programs because of how densely you can store hex.
-
I'm with ztrumpet with this one, store a max of 3 or 4 picture variables and recall them when you want to undo. Quick, simple, and it works. Any other way is going to be really complicated, and probably not the fastest
-
the ability to undo ad infinitum.
Even photoshop doesn't have this :P
And this should stop me...why?
DJ, yeah. The only program I've ever seen advertise "unlimited undos" was HxD, which has a much easier task of it than most programs because of how densely you can store hex.
What does this program do and how does it undo?
And, technically, I only need 999 undoes. If the list has any more elements than that, something's seriously wrong with the calculator. Currently, I have a save and load feature that takes a pic and notes how many list elements there are when it saves, and then truncates the list and puts the pic back on the screen when it loads.
-
How long would it take to redraw the whole picture? That actually sounds like a fairly efficient solution, given that it's not difficult to "call READ." Why is it a pain?
Also I think HxD is a hex editor.
-
DJ, yeah. The only program I've ever seen advertise "unlimited undos" was HxD, which has a much easier task of it than most programs because of how densely you can store hex.
What does this program do and how does it undo?
It's a hex editor, so it probably stores what you write in a buffer that's kind of like a .txt file. You could do the same with Input, although TI-Strings are much less efficient than ASCII.
-
Read is a Basic program. Macro drawings run hundreds of commands long (not helped by the fact that three of the commands use up two list elements). It takes about half a minute (I've never timed it) to Fully draw a list, and 30 seconds per undo is unacceptable.
-
:o
Mind posting a screenie or some example code?
-
how about a compromise, you can have a single pic var for a quick undo of a single step, and from then on, you can redraw the screen for any further undos?
-
The problem is that the list can easily run thousands of bytes, and a compromise, while a great idea, would be a nightmare to implement. Add to that I'm already using Pic1....
-
There is always Pic2 :D
-
Or all of the pics from this: http://www.ticalc.org/archives/files/fileinfo/391/39138.html :P
-
*User sees all memory has gone from calc*"So that's where I downloaded the Internet!"
-
That many pics would require a lot of archiving/unarchiving or writing to Flash. The best way to undo, memory-wise, is if each undoes were like 1 digit of 1 byte each. But that's impossible in BASIC. In BASIC one list element is 9 bytes large. So basically 999 undoes creates a list close to over 9000 bytes large.
-
OVER9000! I leave no possibility uncodedfor in my nonmath programs. The unlikeliest bugs are the ones found the first, and generally are the worst *start programming rap here*
-
Hmm I am confused what you mean (besides the >9000), sorry. Could you rephrase? ???
-
You could actually optimize it, and kinda cheat it a little bit. If you have to go back one step, you have the picture, because you stored it right before the new step. But if you have to go back any farther, or hit any other redraws, you have the last element be run right after you store the picture.
-
I thought of that, but it could erase pixels that were drawn by multiple commamds. (Think Line(X1,Y1,X2,Y2,0))
@DJ_O I'm defensive in the extreme when it comes to programming (one of my programs only gives the user 4 tries to give valid input. There's a cap on the number of tries not to insult the user, but to avoid my error message being displayed wrong.)
-
In BASIC one list element is 9 bytes large. So basically 999 undoes creates a list close to over 9000 bytes large.
Actually, a 999-element list is 9003 bytes large. I lol'd the first time I noticed it was OVER 9000
-
I thought of that, but it could erase pixels that were drawn by multiple commamds. (Think Line(X1,Y1,X2,Y2,0))
@DJ_O I'm defensive in the extreme when it comes to programming (one of my programs only gives the user 4 tries to give valid input. There's a cap on the number of tries not to insult the user, but to avoid my error message being displayed wrong.)
Now I am confused even more :/ . In what way are you defensive? Do you want to make sure people won't look at the source code? Do you want the program to simply deny their access after they fail to type valid input? (Like how on certain forums, when you type your password wrong 4 times, it bans your account for a week)
-
Yea, those two posts in question are confusing to me as well.
In regards to wanting to have unlimited undo's in TI BASIC in a drawing program: it is possible to have many(unlimited might be a bit much), but it would either: A: take loads of memory, or B: have to be limited to commands that are not too complex.
Here is an idea of one solution (although simplified and not completely fleshed out).You could log each command and what variables said command took as input and store it in a string or list. It may be necessary to document what data a command is changing as well. Each command would have to have a separate undo algorithm that would restore whatever part of the screen the command affected. (for those commands that can logically be undone in such a way). When undo is called, the program would check to see what the last command issued was, recall the input, and then call the undo algorithm for that specific command.
The other possibility I see is to use a lot of picture files or lists as others have suggested. I'm sure their may be other ways, it will just take some thought. Good luck!
-
The way I read it, “defensive” seems to be intended to mean that the code is written to handle every conceivable case possible, so that it is very difficult for a bug or malfunction to occur no matter what the user does.
-
Yes.
-
Yes.
yes, to whom exactly? TravisE?
-
Yes.
-
Yes.
slightly spamish, but okay. But wait, was that yes to me, or.... And it's good to program like that, but I don't make that my absolute top priority.
-
I try to do that every time it's reasonably possible. My method is not to catch all possible errors, though. I try to simply make it so that the user can't possibly enter bad input to begin with.
-
That's exactly what I'm talking about.
-
That's exactly what I'm talking about.
Then don't just respond with yes... meh. Anyway, now that that's settled, and we all have good coding practice....
What are you going to choose for undos? You can't have infinite undos the way you are talking about. Not unless you save the state that happened right before the last update for every single update. (Which isn't possible) I'd go with my previous idea, but then again, I'm biased, and am not entirely sure how hard it would be to code.
-
I'd go with the compromise, but it just doesn't feel right to me somehow. About the most complicated logic in the program is the logic dealing with the preview feature for lines, and I'd like to keep it that way.
-
It's your program, so do whatever feels best.
-
I don't know about the feasibility about this, but what if you store the total number of times every pixel was drawn on, and turn the pixels off for only those that are undo-ed?
For example, consider
A***B
*****
*****
*****
C***D
Drawn lines: A-B, B-C, C-D, D-A. Now the total times drawn counter looks like this:
21112
01010
00200
01010
21112
Undoing it once would reduce the counters on the D-A line, namely change it to
11112
00010
00100
01000
21111
so two pixels would turn off.
How would you store a 64x96 matrix? Since hopefully you're using less than 1000 actions due to list size limits, 10 pictures would be enough to store as a binary counter.
Hopefully this works?
-
:o
Do you have one of the older 128 KB calcs? A 95x63* matrix would take up 53 KB of RAM. The newer reduced RAM calcs only have 48 KB to work with.
*TI-BASIC can't draw into the last row and column of the screen.
-
:o
Do you have one of the older 128 KB calcs? A 95x63* matrix would take up 53 KB of RAM. The newer reduced RAM calcs only have 48 KB to work with.
Actually due to limits placed on them by TI, all of the calcs usually have between 16000 and 21000 free RAM for basic programs. :o indeed. :)
-
Thankfully, I have one of the old calcs with 128KB mem. But a 95*63 Change counter is missing a crucial element: What commands changed that pixel.
-
I'm not sure I understand what you mean, but can't you just store the last commands as a number? For example, if the command to draw a line is assigned a value of 1, you could store the element 1 to a list, and when you undo the action, the program reads 1 and does the opposite (erases the line).
-
The tricky thing is that if you draw a line or a rectangle or whatever, you are going to overwrite something else, and by simply erasing it, you won't be undoing it
-
Exactly. Now we've come full circle.
-
Quick question, you said that this program has
three or four eight set in tools to use to draw right? What are they?
Edit:
Sorry if this has already been asked, if it has I missed it.
Edit:
The reason I'm asking is because I can see two, feasible, possibilities for a TI-BASIC undo button.
1. Each time you use a command you store the coordinates needed and the type of action it was (I personally would store the coordinates and then make the type of action a different decimal place for each one) and when you run out of elements, if you do, just archive the current one and overflow into a new list. Then when you use the undo button you simply clear the screen and redraw it by using the stored coordinates and commands. Slower, yes, but would probably be the best option if you want as many undoes as you can.
2. After each command you store the image to a different picture variable, then when the click undo it just clears the screen and recalls the previous saved image. This is probably the fastest but as people have said you're only limited to ten (unless you use the hacked picture variables but I'd advise against that for something like this).
There are other ways you can do it but they are way over kill and very convoluted. And also would be way harder to code.
-
Pt-On/Off/Change, Line(On/Off), Fast Circle, Horizontal, Vertical. And no, that question hasn't been asked yet.
-
Ah ok, Well then that actually makes the first option I gave a lot easier and potentially faster than I thought it would be.
-
Appearently, great minds think alike, because that's what I'm doing already. That compromise idea is starting to look pretty good now. I just have to figure out how to implement it.
-
It actually would be pretty simple to implement, especially if you're only going to make it a one list cap on the amount of content.
Edit:
Also depending on how you store your data, but it still should be easy.
Edit:
What Window settings are you using? (Xmin=0, Xmax94, Ymin=-62, Ymax=0?)
-
No, Y[0,62]. That way I can add it E-2 to the X coordinates.
-
What do you mean? Like I understand the y-value thing, just not the thing about the x-coordinates.
-
The formula I'm using is 100V+X+.01Y
-
BTW, for a 95x63 matrix, store it as 10 pictures, considering that you can restrict yourself where each entry has a integer maximum of 1000.
If I recall this costs somewhere around 7600 bytes.
Of course, if you don't expect the user to paint the same pixel hundreds of times, you can reduce the number of pictures.
Previous example rehashed:
Onscreen
OOOOO
*O*O*
**O**
*O*O*
OOOOO
In layer 1
*OOO*
*O*O*
*****
*O*O*
*OOO*
In layer 2
O***O
*****
**O**
*****
O***O
if a pixel is written over 3 times, then it will be in both layer 1 and layer 2; if 4 times, layer 4, etc.
-
The formula I'm using is 100V+X+.01Y
What formula is that? (By the way, it can be one byte smaller if you do VE2+X+.01Y.
-
The formula I'm using is 100V+X+.01Y
What formula is that? (By the way, it can be one byte smaller if you do VE2+X+.01Y.
And a byte smaller if you do VE2+X+sub(Y.
-
Oh ya...I forgot sub( can be used on numbers :P I'm always just used to using it on strings haha.
-
No problem. It's not always the best optimization to use sub(, since it's 2 bytes, but in an equation, it can work quite nicely.
-
So Idecided to make a basic routine for doing the undo process. I'll type it up when I get home, currently at school waiting for class to start. I don't know how you were compressing your data so I just created my own way.
Edit:
Here is the example I made.
ZStandard
104→Xmax
72→Ymax
ZInteger
ClrDraw
For(A,0,31
Horizontal A
End
"L1(A→u
{100621062,301030,10059.1,20359.1,30759.1,110027.1,120327.1,130727.1,201059.1,201027.1,56.2,156.2,107252.3→L1
For(A,1,dim(L1
iPart(E2fPart(u/E2→Z
iPart(E2fPart(u/E4→X
fPart(u→C
If .1=Ans
Then
iPart(10fPart(u/E5→B
iPart(u/E5
If not(Ans
Pt-On(X,Z,B
If 1=Ans
Pt-Off(X,Z,B
If 2=Ans
Pt-Change(X,Z
End
If .2=C
Then
If X
Horizontal Z
If not(X
Vertical Z
End
If .3=C
Circle(X,Z,iPart(E2fPart(u/E6)),{i
If not(C
Line(iPart(E2fPart(u/E8)),iPart(E2fPart(u/E6)),X,Z,iPart(u/E8
End
Every time in that code that you see a capital letter "E" it is the scientific notation "E" and "L1" means L1. Also, I'll go over how I compressed the data:
If a element does not have a decimal part it is a Line( command, .1 is a Pt-On/Off/Change command, .2 is a Vertical or Horizontal command, and .3 is a Cirlce( command.
For Line(:
-Nine total stored numbers.
--First one is for it is drawing (1) a line or erasing (0).
--The next eight are the X1, Y1, X2, and Y2 coordinates (in groups of two), respectfully.
For Pt-On/Off/Change:
-Six total stored numbers:
--First one says what kind of command it is (Pt-On (0), Pt-Off (1), or Pt-Change (2)).
--Second number says what kind of point (dot (1), square (2), or cross (3)) (Only used for Pt-On and Pt-Off).
--The next for are the X- and Y-coordinates (in groups of two), respectfully.
For Horizontal and Vertical:
-Three total stored numbers:
--First one says what command it is (Horizontal (1) or Vertical (0)).
--The next two are the coordinate used (one two digit number).
For Circle(:
-Six total stored numbers:
--The first is the radius of the circle to be made (one two digit number).
--The next four are the X- and Y-coordinates (in groups of two), respectfully.
So, if you put the zeros back in the list would look like this:
{100621062,000301030,010059.1,020359.1,030759.1,110027.1,120327.1,130727.1,201059.1,201027.1,056.2,156.2,107252.3}
Hopefully that all makes sense. Also, I'm sure there are some optimizations that could be made to that, I just made it real fast for the sake of an example so wasn't really trying to optimize.
-
*cough*Bump*cough*
-
Um, gee, I appreciate the effort, but I already have code. I have 3 vars, V,X,theta (because ClrDraw screws up Y). They're compressed into one list element at the end of the loop, and a single var, L, is used as a flag denoting which set of coords the program is on for LineOn/Off and Circle, and the First set of coords is stored in L1. V is the command number, in order from 1 to 8: Pt-On/Off/Change Line(On/Off) Circle Horizontal Vertical.
And that's the most documentation on this program ever.
-
Ah, well I made it because I was bored and you said you just had to think of a way to implement it so I figured what the hell. However I'm not going to lie, your description confuses the hell out of me :P Could you possibly post some code or try rephrasing or something? Glad you got code though.
-
What do you find confusing?
I have a character limit on my posts right now, which is why I'm not posting code at the moment.
-
You're whole process really.
There is a character limit? O.o
-
Weird, posts are limited to 50000 characters I think, which should be more than enough to post code. Otherwise you could simply use pastie.org or something.
-
The low char limit's just for me, 'cause I'm special. (I'm posting from my PSP.)
But seriously, unless I know what doesn't make sense, I can't fix it so that it does make sense.
-
Surely there's specific code responsible for each element of your program and you've identified which elements aren't working?
-
Oh, no. Everything's working fine. I'm trying to create an efficient undo feature to replace my current save/load system.
-
The low char limit's just for me, 'cause I'm special. (I'm posting from my PSP.)
But seriously, unless I know what doesn't make sense, I can't fix it so that it does make sense.
Oh ok, I see about the char limit.
Also when you can, could you check your forum inbox at http://www.omnimaga.org/index.php?action=pm ? Because I noticed some of your posts have questionable content (by Omnimaga T.O.S standards)
-
Ah ok, I thought it might be something like that but wasn't sure (about the character limit).
But like I said its really your whole description. I mean it's just confusing how you're storing variables and what does what. Not trying to sound rude, it just isn't clicking in my head. (That's why I asked for code possibly to see if I could figure it out that way.)
-
Oh, ok. I'll try to explain it better.
There are 4 variables:
V, which is the command number
X, the current X coord
theta, the current Y coord
L, a flag that indicates which pair of coords is being entered. It is used for all of the two coord commands
And L1, which stores the first pair of coords when a 2 coord command is being entered.
Elucidification:
coord=coordinate
-
So you're storing the command number and the coordinates all in different elements in a list? What does your compressed data look like? (Like what does the data for a Pt-On(32,54), Circle(55,55,10), and Line(0,0,54,34) look like?)
-
Pt-On(32,54) Circle(55,55,sqrt((65-55)^2+(55-55)^2)) Line(0,0,54,34) would be
{132.54, 655.55, 665.55, 400.00, 454.34}
-
Ah ok. I think I get it now. Just to make sure you know, you know that method does limit your number of undos to as low as 499 right?
-
Actually, If something is undone, it's list elements would be removed from the list. That means that I really do need infinite undoes. I was wrong when I typed that I only needed 999.
-
Why would you need to keep the command in the list if you undid it? I mean unless you're wanting to do a redo button too I don't see the point. Also, I can basically guarantee you won't get infinite undos in TI-BASIC, or really any calculator language since you're limited by memory. The only way to get more than 999 is to overflow into another list when you're done with the first.
-
Umm, why would I need a second list.
-
That's the only way you're going to bypass the 999 undo limit, unless you store to a string but then it will get really slow the bigger the string gets.
-
I thought strings were equally slow under all conditions, just like lists are.
-
Nope. Only if you access the end of a large string.
-
Nope, lists are the same speed regardless where you are recalling from. However strings get slower and slower the further you get into them. So say you have a string with 5000 tokens in it, it will take significantly longer to recall tokens 4951-5000 as opposed to 1-50.
-
I didn't know that. I wonder why. On an on topic note, I'd really appreciate an explanation of your code in writing. It's hard for me to understand code, even my own, from scratch.
-
Because TI sucks...um...wait...no...I mean...nevermind, that's what I mean :P Seriously though, I'm not sure. I'm sure someone does though. Would be nice if it was uniform or just a lot faster.
And do you mean my code here (http://ourl.ca/9372/179545) for my display routine? If so, do you first understand the compression method? Because that would be a huge part of explaining the code.
-
The reason is because tokens can either be 1 or 2 bytes long. The only way to know how long they are is to go byte by byte through the entire String until you get to the character you want, which is the source of the slowdown D:
-
Oh ya...that's right. I remember Hot_Dog saying something about that in the Correlation sub-forum somewhere.
-
Actually, I meant the Braille on the wall next to me.:)
Yes, I am referring to your code posted there, Mr. Builderboy. And no, I can't get my brain to process any of the code. It keeps freaking out.
-
Ok, I'll explain it as best as I can. However I am really tired tonight so I will do it tomorrow after I've gotten some sleep.
-
Yes, I am referring to your code posted there, Mr. Builderboy.
Where did i post code? o.O
-
He means my code that I posted here (http://ourl.ca/9372/179545).
-
So the code in question is this:
ZStandard
104→Xmax
72→Ymax
ZInteger
ClrDraw
For(A,0,31
Horizontal A
End
"L1(A→u
{100621062,301030,10059.1,20359.1,30759.1,110027.1,120327.1,130727.1,201059.1,201027.1,56.2,156.2,107252.3→L1
For(A,1,dim(L1
iPart(E2fPart(u/E2→Z
iPart(E2fPart(u/E4→X
fPart(u→C
If .1=Ans
Then
iPart(10fPart(u/E5→B
iPart(u/E5
If not(Ans
Pt-On(X,Z,B
If 1=Ans
Pt-Off(X,Z,B
If 2=Ans
Pt-Change(X,Z
End
If .2=C
Then
If X
Horizontal Z
If not(X
Vertical Z
End
If .3=C
Circle(X,Z,iPart(E2fPart(u/E6)),{i
If not(C
Line(iPart(E2fPart(u/E8)),iPart(E2fPart(u/E6)),X,Z,iPart(u/E8
End
First I'll go over the compression.
Each element is checked for it's decimal point via fPart() because the type of command that is graphed is dependant on it.
0=fPart(\Number\): The data is for a Line() command.
.1=fPart(\Number\): The data is for a Pt-On()/Pt-Off()/Pt-Change() command.
.2=fPart(\Number\): The data is for a Horizontal/Vertical command.
.3=fPart(\Number\): The data is for a Circle() command.
123456789
|||||||||These two numbers are the second y-coordinates for the command.
|||||||These two numbers are the second x-coordinates for the command.
|||||These two numbers are the first y-coordinates for the command.
|||These two number are the first x-coordinates for the command.
|This number dictates if the command is turning on the line or turning it off (one if it is turning it on, zero if it is turning it off).
123456.1
|||||| |Tells the program that it is a Pt-On()/Pt-Off()/Pt-Change() command.
||||||These two numbers are the y-coordinate for the command.
||||These two numbers are the x-coordinate for the command.
||This number dictates if it is a dot, cross, or sqare point that is drawn (one for a dot,
||two for a square, three for a cross; doesn't matter what it is for Pt-Change() since
||it doesn't have a third argument).
|This number dictates if it is a Pt-On()/Pt-Off()/Pt-Change() (zero if it is Pt-On(), one if it is Pt-Off(), two if it is Pt-Change()).
123.2
||| |This number tells the program that it is a Horizontal/Vertical command.
|||These two numbers are the coordinate number.
|This number dictates whether it is a Horizontal or Vertical command (one for Horizontal, zero for Vertical).
123456.3
|||||| |This number tells the program that it is a Circle() command.
||||||These two numbers are the y-coordinate.
||||These two numbers are the x-coordinate.
||These two numbers are the radius.
Ok, not to start breaking down the code.
ZStandard
104→Xmax
72→Ymax
ZInteger
This just sets the window to Xmin=0,Xmax=94,Ymin=0, and Ymax=62.
ClrDraw
For(A,0,31
Horizontal A
End
Clears the graphscreen then fills the bottom half of the screen.
"L1(A→u
{100621062,301030,10059.1,20359.1,30759.1,110027.1,120327.1,130727.1,201059.1,201027.1,56.2,156.2,107252.3→L1
This stores the string "L1(A" to the equation variable u. Basically what it does is that each time that variable is called it will execute that "equation" each time. (Though now that I think about it that can probably be replaced with something else.)
The second line is just storing a test list to demonstrate what the program does.
Now we get into the belly of the code.
For(A,1,dim(L1
iPart(E2fPart(u/E2→Z
iPart(E2fPart(u/E4→X
fPart(u→C
This starts the loop that loops through the list. Then it stores the thousands and hundrends number to the X variable and the tens and ones numbers to the Z variable, because the Y variable can get erased. Then it stores the decimal point of the current list element to the C variable.
If .1=Ans
Then
iPart(10fPart(u/E5→B
iPart(u/E5
If not(Ans
Pt-On(X,Z,B
If 1=Ans
Pt-Off(X,Z,B
If 2=Ans
Pt-Change(X,Z
End
This is the code to display Pt-On()/Pt-Off()/Pt-Change() commands. First it stores what kind of point it is to the B variable then finds out which command it is. It then displays the correct command and type.
If .2=C
Then
If X
Horizontal Z
If not(X
Vertical Z
End
This is the code for displaying a Horizontal/Vertical command. Since only one coordinates is used we are able to use the X variable to determine which command it is and execute accordingly.
If .3=C
Circle(X,Z,iPart(E2fPart(u/E6)),{i
This code simply displays a circle. It uses the X and Z variables for the coordinates and then directly finds the the radius.
If not(C
Line(iPart(E2fPart(u/E8)),iPart(E2fPart(u/E6)),X,Z,iPart(u/E8
End
This code displays a line, or turns one off. It directly finds the first couple of coordinates and then uses the X and Y variables for the second set of coordinates. Then it just finds whether that first number was a one or zero and uses it to turn the line on or off.
The End is then the end of the For() loop.
That explain things better?
I'll also go over it all and try to optimize it some later.
-
Did that help, Freyaday?
Edit:
Can be optimized a little from just scanning over it.
ZStandard
104→Xmax
72→Ymax
ZInteger
ClrDraw
For(A,0,31
Horizontal A
End
{100621062,301030,10059.1,20359.1,30759.1,110027.1,120327.1,130727.1,201059.1,201027.1,56.2,156.2,107252.3→L1
For(A,1,dim(L1
L1(A→D
iPart(E2fPart(D/E2→Z
iPart(E2fPart(D/E4→X
fPart(D→C
If .1=Ans
Then
iPart(10fPart(D/E5→B
iPart(D/E5
If not(Ans
Pt-On(X,Z,B
If 1=Ans
Pt-Off(X,Z,B
If 2=Ans
Pt-Change(X,Z
End
If .2=C
Then
If X
Horizontal Z
If not(X
Vertical Z
End
If .3=C
Circle(X,Z,iPart(E2fPart(D/E6)),{i
If not(C
Line(iPart(E2fPart(D/E8)),iPart(E2fPart(D/E6)),X,Z,iPart(D/E8
End
-
Bump.
-
I see, I see! Why this method in particular, like what are its advantages and such? How did you come up with this? I'm not trying to be rude or anything, I'm just curious.
-
Well it seems to be relatively fast from the test I did, though I haven't done a list with a lot of stuff so I don't know how long it would take to redraw a list with a hundred elements. But this method also guarantees full use of the 999 list elements (assuming there is enough room in the memory for it).
-
The [re]drawing looks pretty sweet, right? But how does this insure 999 commands exactly? And how'd you come up with this?
-
What do you mean does it look sweet? And it guarantees it because each command only takes up one element and since each list has 999 elements that's how many undos you have. The only reason you'd have less than 999 is if you had low memory and the list won't fit.