Ok you know how people make snake and are able to make that line of dots follow each other and move based on which direction lets imagine there's no snake just a single dot…. I want to understand how you program that single dot or little box maybe 3x3 to move around the screen based on the getkeys of the arrow keys can someone please give me code and explain! thanks

Ok, here we go.

```
Clrdaw
AxesOff
ZFrac1/3
0 -> A
0 -> B
Repeat K=45
Pt-Off(A,B,2
A+C -> A
B+D -> B
Pt-On(A,B,2
getkey -> K
If K=24:Then
-1 -> C
0 -> D
End
If K=26:Then
1 -> C
0 -> D
End
If K=25:Then
0 -> C
1 -> D
End
If K=34:Then
0 -> C
-1 -> D
End
End
Clrdraw
ZStandard
AxesOn
Return
```

Change the direction of the dot with the arrow keys

Quit by pressing clear (Clear returns a getkey value of 45)

The code is pretty straightforward, but basically the code adds the value of C to A and D to B every time through the loop. A and B are the coordinates of the point. Since I only use values of 0,1, and -1, the box will only shift over by one "unit" in one direction at a time. If you wanted to add diagonal movement, you would have non-zero values (could be any combination of 1s and -1s) to both C and D at the same time.

Note: the above code is far from optimized. It can be improved in many ways, particularly with piecewise statements. Just look for the page on piecewise on this site if you're interested, but make sure you have a valid and strong understanding of the If statements first.

If you are trying to optimize this code and need some help, I do have an optimized version which I will gladly post. I posted the non-optimized version because it is easier to understand.

I hope this helpful.

—Wolfgang

This is a huge help what is the difference between pt- on and pt - off and what do they do exactly?

And why do you include Z frac 1/3?

Pt-On turns on a point on the screen.

Pt-Off turns off a point on the screen

the syntax for each command looks like this:

Pt-On(x,y

Pt-Off(x,y

x represents the x-coordinate of the point.

y represents the y-coordinate of the point.

You can use a number, like this:

Pt-On(0,0

or

Pt-On(5,3

or

Pt-Off(0,0

or

Pt-Off(5,3

etc.

You can also use variables, like in the code I posted.

There is also an optional argument which you can add to the end:

Pt-On(A,B,2

Pt-On(A,B,3

2 draws a 3x3 box, like in the program I posted.

3 draws a 3x3 "+"

1 turns on a single point.

You do not have include 1 on the end to turn on a single point, or "dot" (aka pixel), on the screen. 1 is the default value, so if you don't include a value, a single point will be turned on:

Pt-On(A,B

is the same as

Pt-On(A,B,1

Keep in mind that you can also use this optional third argument for the Pt-Off command.

Now, here's the thing:

Where the point turns on (or off) is dependent on what your WINDOW SETTINGS are.

The standard settings (which are restored using ZStandard) are:

-10 -> Xmin

10 -> Xmax

-10 -> Ymin

10 -> Ymax

Th only trouble with these values is that the coordinates of most of the pixels will have a long string of decimals attached, which is very bad for programming. If you used these settings, you'd have to add very not nice numbers each time instead of 1.

This is where ZFrac1/3 comes in. ZFrac1/3 makes the settings look like this:

-47/3 -> Xmin

47/3 -> Xmax

-31/3 -> Ymin

31/3 -> Ymax

The reason is this: The screen is 95 pixels across, and 63 pixels wide.

If you were to make the settings look like this…

-47 -> Xmin

47 -> Xmax

-31 -> Ymin

31 -> Ymax

…then the difference in value between one pixel, or point, and the next would be 1, not a fast string of decimals. This is very convenient. Remember when I said that the screen is 95 pixels wide by 63 pixels tall? Ok, well, with the directly above settings (which can be accessed with the ZInteger command), there are 47 points on each side of the screen, and there is also one point in the center (it has a value of 0). 47+47+1=95.

Boom.

Ok, now back to ZFrac1/3.

The reason I use ZFrac1/3 is because we used 2 in the Pt-On/Off command, thus drawing a 3x3 box. Notice the correlation: 3.

So, for every three pixels, one of them will have an integer value. The other two will be measured in 3rds, or .666 and .333 (2/3 and 1/3)

Since we shift the box over by its length (3) or height (also 3) each time, we use ZFrac1/3 in order to do this by simply adding or subtracting 1 from the coordinates.

Sorry if this explanation was a bit mediocre and disorganized; I am typing this from an iPod touch, which makes it difficult to think and use proper grammar, or at least is does for me.

It is also exceedingly difficult/annoying for me to type from an iPod touch, so…if my wording seems rushed or anything, I apologize.

See the pages on friendly graphing windows and the pt-on/off commands for what is likely to be a much better explanation. :D

—Wolfgang

dude! thank-you this all makes sense and i made my own program using all this stuff you make a dot move all directions including diagonal! I have another question. how can i make a level using square boxes as building and ahve it so i can't go through it?

Use multiple Pxl-Test commands to see if the object to the x direction is a box.

Sunrise 3 Progress: 30%

Size: around 20 KB, not including the save lists and in-game RAM.

I actually made a game based around that principal. The code is long, but I'll post it as soon as possible.

—Wolfgang

Ok this is going to sound like a dumb question….

but how do i program it so i asks for a name , and alpha lock is already on so they don't have to turn it on?

That isn't a dumb question. I think you have to use a short assembly code, which is available on the assembly page of this website. I'm not sure if there is a way to do this in TI-BASIC. In fact, I am pretty sure there isn't.

In terms of inputting a name, do something like this:

`:Input "NAME ",Str1`

Make sure to include a space after the "E" in "NAME", because otherwise their input will be squished together with the word "NAME" and that doesn't look good. You can also put a ":" before the space, but as this isn't necessary and it makes your program a tiny bit bigger, I wouldn't bother.

—Wolfgang

If you want to ensure that the user can only use letters, you can do this:

```
Asm(prgmALCK
Input "NAME:",Str1
Asm(prgmAULCK
```

prgmALCK will turn on the alpha lock that cannot be turned off (easily), so prgmAULCK will undo that.

prgmALCK is AsmPrgm3ED1FD7712C9

prgmAULCK is AsmPrgm3E01FD7712C9

If you want to make to make it lowercase lock instead, you can change the D1 in prgmALCK to B1 to get AsmPrgm3EB1FD7712C9

47%? Take a look and try to imagine how cool 100% will be. This has won zContest 2011 and made news on TICalc. This compromise between Assembly and BASIC parses like BASIC and is fast like assembly. Grammer 2

I am having trouble with a new method that I am trying out for snake. Instead of my usual method of changing direction, which is a combination of two If Then statements, each containing 1 piecewise statement and a simple variable storing statement, I am trying out 2 cubic equations. In the trace mode, I can clearly see that the solutions are exact (integers) but when I run the program, I get a domain error for a pixel test command unless I use the int( command which I have never had to do with this prOgram before. Also, when the snake goes down, it calculates the change in y to be -1.000000000001 or something like that, even though the solutions should be exact…I'm not sure what's going on.

—Wolfgang

That's simply rounding error by the calculator; it arises with specific number computations.

Which part of the behavior is the error? The domain error in Pxl-test, the -1.00000001, or the integer on the graph screen? Is there an easy way to take care of this other than using int or round?

—Wolfgang

The calculator gets some minute error in its computation that adds a tiny decimal part to your number. Since you cannot draw to a fractional part of a pixel, the calc throws an error. I cannot think of an easier way to do this, unfortunately :/

47%? Take a look and try to imagine how cool 100% will be. This has won zContest 2011 and made news on TICalc. This compromise between Assembly and BASIC parses like BASIC and is fast like assembly. Grammer 2

Thank you for your explanation. I have decided to scrap the Cubic equation idea, because it is requires several additional commands to fix the bugs that arise with it. Also, the equations themselves are fairly large. Instead, I have decided to refine my original methods with more piecewise. Here is my original:

```
If D and (N=24 or N=26
Then
(N=26)-(N=24 ->C
0 ->D
End
If C and (N=34 or N=25
Then
(N=25)-(N=34 ->D
0->C
End
```

Note that "N" is actually the Finance Variable.

I tried optimizing the code, by removing any If statements, but now it's just huge because I have to reference the Finance Variable so many times.

```
C(C≠0 and (N=24 or N=26) or not(N=25 or N=34))+(C=0)((N=26)-(N=24 ->C
D(D≠0 and (N=34 or N=25) or not(N=26 or N=24))+(D=0)((N=25)-(N=34 ->D
```

Does anyone know how I could optimize these (either my two pure piecewise statements or my original code)?

I can't seem to figure anything out.

—Wolfgang

I would just stick with using something like this:

```
(N=26)-(N=24→C
(N=25)-(N=34→D
```

When you were doing

**If C and (N=34 or N=25**, I can only assume you were using the

**IF C and**in an attempt to save time, but the piecewise functions will take the same time no matter what. The above code should be faster and smaller than the other two.

47%? Take a look and try to imagine how cool 100% will be. This has won zContest 2011 and made news on TICalc. This compromise between Assembly and BASIC parses like BASIC and is fast like assembly. Grammer 2

You might also want to wrap an If conditional around that:

:If N=34 or 2>abs(N-25:Then

:(N=26)-(N=24→C

:(N=25)-(N=34→D

:End

I like what you did there. This prevents, I believe, the glitch of losing from hiting another button, such as the pause button.

It does not however, correct the issue of losing by, for example, hitting that down arrow when you're going up.

—Wolfgang

Xeda: Unfortunately, I cannot use piecewise statements that simple. Your solution was exactly the foundation of my more complicated piecewise statements, but I can't leave them that simple for several reasons:

If you hit any other button (including 2nd, which is the pause button) you automatically lose

If, for example, you are going right and you hit the left arrow key, you lose

My more complicated piecewise statements address these issues.

—Wolfgang

I really could use some help simplifying this:

C(C≠0 and (N=24 or N=26) or not(N=25 or N=34))+(C=0)((N=26)-(N=24 ->C

D(D≠0 and (N=34 or N=25) or not(N=26 or N=24))+(D=0)((N=25)-(N=34 ->D

—Wolfgang