Yeah, i find that Lists tend to be a lot slower because then you need to use loops to iterate through the 4 elements of the piece, and while the interpreter might be slow, running a loop if definetaly slower than expanding it all the way out.  For example:

Pt-On(0,0
Pt-On(1,0
...
Pt-On(94,0
is always going to be faster than

For(F,0,95
Pt-On(F,0
End
because even though it might look like you are cutting down on parser time, the OS is still parsing Pt-On(F,0 96 times, and now you are both using the variable F, but also having to go through the loop 96 times.

As for controling the speed of the falling, i use this piece of nifty code:

C(C!=V)+1->C
Which when looped over and over, will make C loop from 1 to V-1 over and over.  When C=1 i move the piece down, and so changing V changes the speed at which the piece falls.  Or more accurately, V is the number of frames between drops of the piece.

For removing lines, I retrieve the Y values of the piece that just dropped (since those are the only ones that could possible clear lines) and i loop through them top to bottom.  I loop across the entire screen, and if every block is filled, i move onto the clear line set of code.  The clear line set of code copies lines from the line above, to the current line, and moves upward until there are no more blocks to be copied.  After the program does this for all 4 possible Y values, the code exits.

Generating block patterns is easy, I merely store all possible block patterns in the beginning of the program to 2 lists (the storing is a bit weird because i was trying to cut down on memory) and they are accessed with Random numbers.

This Tetris clone is not perfect, but the main loop is so minimal that i see very little ways for it to be sped up.  One way would to be to do as you suggested and only switch the pixels that change, although calculating which pixels is often going to take longer than just turning them off to begin with.  Right now the main loop consists of only this:

Turning on the piece
Incrementing the counter
Getting the Keypress
turning Off the piece (not always done
Moving the piece
Checking for collision

And as every single one of these pieces of code is needed, the only way i can see to make it faster is to improve on the methods used.  However, there might be an alternative method that i am overlooking, often times thinking out of the box can yield impressive results, with creative code Tetris in Ti Basic is definetaly one of the greatest challenge for a Basic programmer, as is many real time puzzle/action games

This is all really interesting. Learning lots.

@theUnnamed
Just a little tip is that BBCode doesn't work inside of the [code][/code] command, such as your subscript commands. Just thought I'd let ya know

In TI basic the varibles a-z and Theda are indexed using an array and the calculator doesn't have to do anything more then *(arry_ptr+var_name-'a') to retrieve the value. where as the resolution of a number is a far more complex task because It has to do a conversion form a char array to a float which If you've ever implemented that in c is not pretty and a rather complex loop even when optimized.

While it makes sense in theory, the TiOS is fairly weird, try these programs: (Note you need an 84)

StartTimer->A
For(F,0,9001
123+456
End
Output(1,1,CheckTimer(A)/F
StartTimer->A
For(F,0,9001
C+C
End
Output(1,1,CheckTimer(A)/F
This is my old code tester program, it tells you how many seconds it takes for any given piece of code to execute.  It is very useful for comparing two pieces of code.  It works by starting the timer, running the code for over 9000 iterations (more if needed) and then finding the ratio.  The first program evaluates to about .00279 Seconds, and the second evaluates to .00365 seconds.  Of course this isnt completely accurate because of the presence of the for loop, but it does give a good way to compare, and for some strange reason Variables take longer then Numbers o.O and accessing Lists takes longer than both variables or numbers, at

As for matrices, while they do make for line testing to be quite faster, everything else becomes quite slower.  Reading from a matrix of that size takes about .00411 seconds, while using a PixelTest takes .00322 seconds.  As for storage, storing to a matrix takes .00444 seconds, and storing to the screen... you already did it when you updated the screen so it takes no extra time.  I focused on getting the main loop as fast as possible, and since it needs at least some form of collision, i decided for pixel-tests instead of matrices.

But wait, I was Using real variables, not immaginary ones.  The OS does know the difference, and even groups them diffeently in the memory menu.

Okay i switched the code to this instead to get rid of any discrepancy:

StartTmr->A
Repeat checkTmr(A
End
For(F,0,9001
C
End
Output(1,1,checkTmr(A)/F
and

StartTmr->A
Repeat checkTmr(A
End
For(F,0,9001
123
End
Output(1,1,checkTmr(A)/F

and i got .002888 seconds for the first code and .002332 seconds for the second code.  Somehow, even merely storing the result to Ans is slower when accessing a variable.


And as for matrices, i understand how they are so much faster for line clearing, but they are not faster when being accessed for collision, even if put into a seq() command.  And i would much rather have fast gameplay and a half second slower line clearing than slower gameplay and blazing fast line clearing.
 

Wow, this is a really cool challenge!  Good luck you two!

As for speed, I'm pretty sure the methods Builderboy is employing are almost as fast as if could ever get.

I can't wait to see what you come up with, TheUnnamed.

Thanks guys

Plus he has done calc stuff for quite a while already.

Tomorrow I will have been with Omnimaga for a year :O