Routines and Source Code

[axcho]

Here's a new topic. I want to share some of the uses of complex numbers for coordinates. It is applicable to string coordinates as well because string coordinates can store a point in a single number.

Let's say you are putting the vertical coordinate in the imaginary part, and the horizontal coordinate in the real part. Vertical coordinates increase from top to bottom and horizontal coordinates increase from left to right.

In the first situation, say you want to have a loop that goes in a variable direction, so you don't know which axes it will use (horizontal or vertical or both). It is easy when you store the coordinates in a single number.

[DarkerLine]

I've moved this to the Source Code topic, this is too complex to be just a 'trick'.

[Ray Kremer]

Sure. On the 85/86, complex numbers actually are expressed as ordered pairs.
i.e. -4+7i is (-4,7)

[DarkerLine]

Something I came up with to convert numbers to fractions (fairly unoptimized)

[BarrenSoul]

I am now an experienced user with is>( and ds<( (a whole 5 minutes practice :D) anyways I've noticed something not everone might know who's just starting to use it:

Do not do this!

DelVar B
DS<(B,1

a variable that has had DelVar [var] done to it will crash your program because it is considered undefined :)

[DarkerLine]

True, one of the reasons that I don't like using IS> and DS< anymore. Actually, I usually just say 0->B instead of DelVar B.

[leofox]

I have never found a use for IS and DS... so i don't use them

[DarkerLine]

They have their uses, but they are so rare that the commands are mostly useless. I'd have preferred the 73's SetMenu( command.

[Ray Kremer]

[BarrenSoul]

yeah but I use the 83, and my string program can make use of ds and is but it dosn't give a decent speed boost and I have to use lbl's :)

[DarkerLine]

why do you have to use labels? labels are bad.

[BarrenSoul]

sure is :)

[Ray Kremer]

[axcho]

I want to make sure this information doesn't get lost forever, since I spent quite a while writing it and it may be useful to some people.

2D Sprite Techniques in TI-83 BASIC
-------------------------------------------
Output()
--ASCII characters
--Blink characters
Text()
--ASCII characters
--Blink characters
--Textsprites
pxl-Change(), pxl-On(), pxl-Off
--Static Pixelsprites
--Variable Pixelsprites
Plot1(), Plot2(), Plot3()
--Plotsprites

So, I will start from the top.

The simplest way is to use Output() to draw an ASCII character at a specific location on the homescreen. The advantage of this is that it is fast, simple, and can be used in conjuction with a sub() command to efficiently choose a sprite to draw from a string of characters. It also can be used with strings to quickly display and scroll maps. The downside is that it is on the homescreen, and the sprites are limited to looking like ASCII characters.

A variation on this is to quickly alternate displaying between two or more characters, to combine the ASCII characters into something more interesting. This way there is an element of grayscale as well. There are, of course, many disadvantages to this, that it is on the homescreen, it is flickery, and it is slower. I have never seen this technique implemented before, but I think it could be useful in some cases.

A similar method to Output() is to use Text(), which is like Output() except on the graphscreen. This means that you can place the text on any pixel location, and the font is smaller. So both the previous methods apply here, except for the scrolling maps. Because the font size is smaller, though, your sprite selection is even more limited, and the higher resolution makes it effectively slower.

But there is a very good use for the Text() command. This is what I call Textsprites, a technique that I came upon at this topic: http://forums.unitedti.org/index.php?showtopic=2534 It involves displaying a string of characters with Text() in a For() loop. Usually the characters are drawn 1 pixel apart from left to right, so that only the first column of pixels is displayed. The columns are usually 5 pixels high, so this technique is useful for displaying 5x5 sprites. The great flexibility of this technique is that it, like all text commands, can be used in conjunction with a sub() command to easily select one sprite from a list. The main disadvantage is that it is a little slow, because it uses a For() loop. So this technique is especially useful in turn-based games, such as board games, card games, and strategy games. But the speed is not bad when compared with more flexible sprite techniques. Only when compared with plain ASCII characters does it seem slow.

Textsprites are also limited in their height of 5 pixels (though you could display larger textsprites by displaying from bottom to top as well as left to right), as well as the selection of characters. Some 5 pixel combinations are impossible using only the characters that are legal on a TI-83. They are, from top to bottom, 00101, 01011, 10110, and 11001. Others are annoying in that they take a very large horizontal space. There are two: 10100 (x root) and 11010 (squiggly x squared). Most other characters take 3 horizontal pixels and erase the 4th column of pixels. So if you want a grid of Textsprites, the most likely space you will need between each sprite is 1 blank pixel between rows, and 3 blank spaces between columns. Of course, if you manage to use only characters that are 2 pixels wide (plus 1 space) on the edges of your sprites, such as ( or [, then you can put the columns 2 pixels away instead of 3. I will put some Textsprites of mine at the end of this post.

The most common TI-BASIC sprite technique other than using ASCII characters is to use static pixelsprites. That is, using a bunch of pixel commands whose coordinates are hard-coded relative to the sprite's upper-left corner. It is pretty easy to write a program that converts an image into a string of BASIC commands that you can paste into your game. The advantage of this is that it is one of the fastest ways to get a bunch of pixels on the screen. The disadvantages have to do with flexibility. You cannot select a sprite to draw without using slow If statements, which reduces their utility in strategy games. They are probably most useful in arcade games, where there are only a few actors in the game. Usually these sprites use pxl-Change() commands so they may be erased and then drawn to a new location with the same set of instructions.

There are several ways to make displaying static pixelsprites faster. One way is to have a separate movement pixelsprite that erases part of the sprite from one end and adds to the other end to make the sprite move in one direction. You would need one of these for each direction that the sprite moves. This is only effective if the sprite moves a small number of pixels each step, though. If your graphics are tile-based, then you will have to use this next technique. The purpose of the next technique is to reduce the number pixels you have to display at a time. You do this by displaying them when the program loads, as the background. I did this in the game Treasure Hunter http://www.ticalc.org/archives/files/fileinfo/352/35242.html, which is basically a graphics demo for this method. The player and enemy sprites move on background tiles that look like grass, and they share pixels with the grass so they only have to display about half the pixels that they would normally! To design the sprites, first draw the whole sprite you want, and then pxl-Change() (otherwise known as XOR) the background tile on top of it. Then turn the resulting mush of pixels into a bunch of pixel commands that you can display on top of the background with pxl-Change() to recreate your sprite. This only works for tile-based sprites, though.

An alternative to static pixelsprites is variable pixelsprites. This trades off the speed of static pixelsprites for the greatest flexibility of all sprite techniques. Variable pixelsprites means reading data from a matrix, list, string, or other structure to determine which pixels to turn on or off. The easiest way is to just take a matrix and a couple of nested For() loops and use an If statement to see whether each matrix element is a 0 or 1, and then draw a pixel if it is a 1. However, this is both extremely inefficient and slow. Matrices store each element as an 11 byte real number, so they are overkill for a binary sprite. A much better way to do this is to use a string like in the example below. This both eliminates If statements and uses only one loop, besides taking less memory than a matrix. This example displays a random 5x5 sprite at a random location in a grid on the graphscreen. To make different sized sprites, you will have to change a few numbers in the code.

[DarkerLine]

Interesting possibility with plotsprites:

[alexrudd]

[axcho]

Other than what? I don't understand what you are referring to. I looked and the sentences you quoted were in my post. I don't see any typos either. Do you disagree with something I said there?

I meant that having ten If statements in a row to choose a static pixelsprite in a strategy game, for example, is less efficient than choosing a textsprite with a single line of code. It is generally faster and smaller to replace If statements with functions.

[Arcane Wizard]

I improved my menu routine..

"MENU TITLE,OPTION 1,OPTION 2,OPTION 3,OPTION 4,OPTION 5,OPTION 6,OPTION 7,OPTION 8,->Str0 //make sure to end the string with a ,
inString(Ans,",->X //get the length of the title
length(Str0->L //store the length of the string for later
Delvar A0->Ø //A will be a temp var for X and Ø will hold the position to draw the option at
Text(0,0,sub(Str0,1,X-1 //draw the title

While X<L //loop through all the options
X->A //remember current option offset (the "," before the current option) A+1 is the first character of the current optoin
Ans+inString(Str0,",",Ans+1->X //store the position of the next comma in X
Ø+7->Ø //next line
Text(Ans,10,sub(Str0,A+1,X-A-1 //draw option
End

7->X //starting position of the cursor
Repeat max(K={21,45,105 //untill 2nd, clear, or enter is pressed
getKey->K
If Ans:Text(X,0,"_ _ _ _ //erase the cursor if a key was pressed
X+7((Ans=34 and X<Ø)-(Ans=25 and X>7->X //move the cursor
Text(Ans,0,"> //draw the cursor
End

X/7 //return which option was chosen

[DarkerLine]

One small optimization:

[Arcane Wizard]

Hey, that's a cool one, fixed.

I don't really mind the flickering though, that's optional.