Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: theUnnamed on April 13, 2010, 09:42:31 pm
-
I'm going to write tetris in entirely TI basic for the 84+ and possibly the 83+ if I can work out the timing of it. Ultimately I'm rewriting a program I made a while back I had it almost complete but I lost the code when my calculator was stolen this time I'm going to finish it.
I challenge someone to finish writing it before me. And just so we're all on a level playing field it must be able finish one block drop and move to the next in less then a second unless it has to eliminate a row and be at least 16 blocks across. I have gotten 99% of the way there in the past and I had to split It into 4 programs to work it into memory. A launcher that unarchived and archive the other 3, a setup program and a clean up program only the setup and 1 of the 3 others fit in memory at the same time when you had all the variable information and nothing else could be in memory while it run. Needless to say it toke up a lot of space. trust me It takes every trick in the book to make it work. call it the ultimate TI Basic challenge.
-
Sure i'll take you up on this :)
-
Nice to see you want to work on that game :)
Good luck ^^
-
I don't think I would be up to this. Good Luck!
-
i'd be up for it in axe [not part of the challengr, but oh well :p]
-
I think I'm going to modify the competition slightly for fairness. I'm going to build a piece of code that sets up the board layout (meaning the visual background that never changes like the sides of the tetris board and the next block box) and post I all contestants will start building code then.
This will not only give a completely level playing field as far as code complexity is concerned. It will also give people some time to think about how to implement it thus taking away some of my advantage of already having run into most of the problems. This program really takes a lot of thinking out side the box even though it seems simple the amount of memory you have to work with coupled with the time restraint of it having to be responsive and not take a long time to index itself so it can implement a simpler inner loop makes it more difficult then it first seems.
I hope to have the board setup program up by Friday
-
I'm curious to see who wins. :) Good luck you guys.
Edit:
i'd be up for it in axe [not part of the challengr, but oh well :p]
Tetris in Axe would be pretty cool. It'd be interesting to see how it would turn out.
-
This would be interesting :)
I don't think I'll do it. If I pick this project up too, I'll never finish TLM -_-;;
-
Idk for myself either because I never really got into puzzle game creation nor complex games like Tetris, so I would probably epic fail at it, especially that all the tricks I know about TI-BASIC are mostly rudimentary stuff x.x
-
You're also welcome to try your hand at coding Trominoes (http://ourl.ca/4329). :)
(http://img87.imageshack.us/img87/5865/trominoes.png)
/shameless self-promotion
-
I would say that's a different engine but much of the code could be reused.
-
That could maybe be another idea actually. There are a lot of Tetris clones in BASIC and ASM (I think Nitacku did one with BASIC and one with xLIB and they're quite good) so maybe something slightly different?
-
Woot so i already have the entire engine finished, what was the dimnensions that you required? Traditional 10 wide and about 15 hight?
-
Are you making the Tetris game or what Zera posted?
-
Tetris, its a fun coding challenge, to exercise the brain and keep my basic skills up to par :)
-
Woot so i already have the entire engine finished, what was the dimnensions that you required? Traditional 10 wide and about 15 hight?
I'm doing is as a 16 wide by 32 high board because that's what looks about right to me on the screen. How much time did you have to devote to this. I have only had like 15 min to work because of high school. I honestly didn't expect anyone to do it this fast.
So here's the question does your program use anything that doesn't come on the calculator when it was sold because that's what I meant by in TI basic (no faster OS or interpreters allowed) and how quick does it run? and finally how did you code it. here's my interface designs 2x2 pixels to tetris block
-
Builderboy is god of TI-Basic, while Calc84maniac is god of asm. ;D
Anyways, I also am curious of the speed and design for both theUnnamed and Builderboy's tetris. I can't seem to think of a fast way to do it top of my head :(
-
/me bows down to the "gods" :P
Nice, Builderboy.
And ya, school can really put a halt on things especially depending what classes and such. I'm sorry to hear you've only had about fifteen minutes.
-
/me wonders when the games will be available for download.
-
Alrighty, i was away for yesterday so i couldn't upload as soon as i wanted, but im on now ^^ I spent about 4-5 hours on this on Tuesday before it was all finished up. It helped that i have make tetris clones for BBCBasic and in Java, so i know the basic way that i like to code it. I used 3x3 blocks to build the Tetris pieces, as the Pt-On alternate arguments provide fast and easy ways to turn on and off 3x3 boxes. I didnt add anything fancy like highscores or things like that, after all its only a demo :P
I have attached the screenshot, which is running on an 84SE (anything else will probably be too slow to be playable) and the source file, which is only about 1500 bytes.
Controls:
Arrow Keys to move piece
[Down] to move piece down
[2nd] to rotate
[Mode] to Quit
[Del] to Drop
-
Wow, nice! The speed seems reasonable. Does it get faster as you play the game?
One thing though, is that I don't like how there's a blank line right next to the border. Wouldn't it be better of there were no gaps between the blocks and the border line? Just my thought...
btw, I like how the block solidifies when it hits bottom^^
It would be cool if we can add items. that would be awesome O.o
Oh, and looking at the key, I think [Alpha] is a better key for the drop than [Del]. You might make a mistake and press [mode] and accidentally quit the game.
-
Hah, yeah i did that on purpose :P It does get a lot faster as the game progresses, and now hat you mention it, i think i'll upload a screenshot of full speed so you can see what it looks like, as its running at about 1/5 the speed right now i think.
Haha and what items are in tetris? o.O Never heard of any :P
-
You haven't heard of the bomb?
:O
-
Alrighty, i was away for yesterday so i couldn't upload as soon as i wanted, but im on now ^^ I spent about 4-5 hours on this on Tuesday before it was all finished up. It helped that i have make tetris clones for BBCBasic and in Java, so i know the basic way that i like to code it. I used 3x3 blocks to build the Tetris pieces, as the Pt-On alternate arguments provide fast and easy ways to turn on and off 3x3 boxes. I didnt add anything fancy like highscores or things like that, after all its only a demo :P
I have attached the screenshot, which is running on an 84SE (anything else will probably be too slow to be playable) and the source file, which is only about 1500 bytes.
Controls:
Arrow Keys to move piece
[Down] to move piece down
[2nd] to rotate
[Mode] to Quit
[Del] to Drop
hmm.. I should toss this on my 83+SE, see how much faster it is on it, since the 83+SE is just a touch faster than the 84+SE.
-
Woot, uploaded a new screenshot that runs at full speed.
-
wow pretty nice. the falling speed is as fast as LV10 on the old Windows 3.1 Tetris. Pretty reasonable if you ask me. It would be very playable on regular 83+ but maybe a bit too easy. At the SE speed it's definitively almost as fast as a real Tetris game. Very nice job on this :)
-
Ok I guess I continue my development of my tetris Unfortunately life decided to chop up the coding time I expected to have I like you tetris design. and what augments of point-on give u 3x3 block manipulation? I didn't no such a thing existed
-
Yeah, its not very well documented. Try this
Pt-On(0,0,2
or
Pt-On(0,0,3
and you can get a block and a plus :)
-
That's really neat That's better way then line(0,0,1,1
-
Or if you just want the black block do Pt-On(0,0,2:Pt-On(0,0 instead of Pt-On(0,0,2:Pt-On(0,0,3 :P
-
looking at your code It is far more brute force than my design which tries to minimize interpreter parse time by employing lists as much as possible. I also keep an index of the board in a matrix in the background which is what takes up the most memory because i found that it was very slow to test the pixels on the screen. I found a nifty way of making line elimination detection really fast. and my original version made an effort to reduce flicker of the blocks by pre-calculating the shift and only changing the pixels that absolutely had to be changed. As you can tell my design is far more complicated then yours. I guess I got so wrapped up in optimization that I neglected to take the simple approach. I don't understand is how you are doing a few things:
controlling the speed of block falls
removing lines
generating block patterns
-
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
-
I do realize that Iterating a loop takes time but I do not think you realize how for loop iteration is done in TI-basic or how much faster variable resolution is then number resolution. 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. additionally for loop end values,increments and a pointer to the line immediately following the for( statement is cashed on the stack making the incrementing and checking of for loop conditions a trivial amount of time because no interpretation is ever done if you need proof of this fact try this:
:1->X
:0
:For(X,1,100,X
:Ans+1
:End
:Ansif the interpreter reinterpreted this loop each time conditions were checked the loop would run only 8 times but instead it runs 100. therefore it must cashe the value of the inc as of the time the loop starts and use that. This also explains the weird discrepancy in behavior of the for and while loops but I digress.
here is my strategy for detecting coalitions, row eliminations and full row detection a matrix of size board width+2 by board height+1 this seems like a crazy waste of memory but makes collision detection, row detection and row moving faster.
first step is the pregame setup
you set up your matrix like this (for your 10X16 board)
1,0,0,0,0,0,0,0,0,0,0,1
1,0,0,0,0,0,0,0,0,0,0,1
1,0,0,0,0,0,0,0,0,0,0,1
1,0,0,0,0,0,0,0,0,0,0,1
1,0,0,0,0,0,0,0,0,0,0,1
1,0,0,0,0,0,0,0,0,0,0,1
1,0,0,0,0,0,0,0,0,0,0,1
1,0,0,0,0,0,0,0,0,0,0,1
1,0,0,0,0,0,0,0,0,0,0,1
1,0,0,0,0,0,0,0,0,0,0,1
1,0,0,0,0,0,0,0,0,0,0,1
1,0,0,0,0,0,0,0,0,0,0,1
1,0,0,0,0,0,0,0,0,0,0,1
1,0,0,0,0,0,0,0,0,0,0,1
1,0,0,0,0,0,0,0,0,0,0,1
1,1,1,1,1,1,1,1,1,1,1,1
now checking for a collision become a single short line (assume L1 to be x coordinates and L2 to be y coordinates)
0=sum(seq([B](L[sub]1[/sub](i),L[sub]2[/sub](i)),i,1,4there is no argument that this will woln't execute faster then your check condition because it runs far faster (like half the time if i remember correct)
once the final placement of the block is determined do this:
:For(I,1,4
:L1(i->X
:L2->Y
:1->[B](Y,X
:[B](Y,X-1->A
:[B](Y,X+1
:Ans+A+1->[B](Y,X+Ans
:Ans->[B](Y,X-A
:End
:clrlist L3
:For(Y,min(L2),max(L2
:If 12=[B](Y,1
:Then
:Y->L3(1+dim(L3
:mRow(0,[B],Y
:1->[B](Y,1
:Ans->[B](Y,30
:End
:End
L3 now contains the rows that must be eliminated and they be have been reset to [1,0,0,0,0,0,0,0,0,0,0,1]
you can then use row the row swap command to move the line down. then you update the screen but I forget how I did that quickly right now so I'll get back to you when I remember.
YOU CANNOT TURN THE MATRIX to make the index order constant with that of the pixel drawing proceedure or you lose the fast row elimination.
-
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 :)
-
@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 :)
I realize this now
-
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.
-
in the older version of the OS (by older I mean really old) I got better performance with the matrix method.
also your testing procedure is flawed you forget that variables can store complex numbers so your "access time" difference is not dew to the difference in access time but dew to the fact that it has to do a complex number addition instead of an real number addition. which in fact takes longer because its doing 2 floating point adds which on the z80 are the slow step of that line of code.
I have no Idea how to test this and I currently am using a N-spire emulation for my 84 so I can not truly accurately test this because the emulator runs on an OS that is not nearly as constant in runtime as the real 84+ is also you should try changing the top line to
:starttmr->A
:While not(checkTmr(A
:End[and the last line to
:CheckTmr(A+1)/Fthis allows for a more consistent start time within the clock cycle.
and yes matrix access is slower...
in a loop because of parse time of the index but when in a seq( command it's just as fast if not faster because the interpreter only parses it once and then executes the entire seq( statement.
-
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.
-
To check the difference, does it takes more processing time, though?
Also I am not too sure if speed tests done on a TI-Nspire can really be taken for granted, since this calc, in 84+ mode, doesn't even emulate the original speed correctly. Some stuff will be slower and other stuff faster and it varies from an OS to another. OS 2.0, for instance, is considerably faster with ASM.
-
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.
-
i agree with builderboy on the last one. Most Tetris clones on ticalc are too slow to be any fun and challenging, this one should be as fast as possible during falling pieces. We don't mind if line erasing is slower.
-
Wow, this is a really cool challenge! Good luck you two! :D
As for speed, I'm pretty sure the methods Builderboy is employing are almost as fast as if could ever get. ;D
I can't wait to see what you come up with, TheUnnamed. :)
-
As for speed, I'm pretty sure the methods Builderboy is employing are almost as fast as if could ever get. ;D
True, I personally have no doubts for his skills. Just having seen his previous work in the TI community is enough to convince me his optimizing skills are practically as good as Weregoose's, in overall. Plus he has done calc stuff for quite a while already.
-
Thanks guys :)
Plus he has done calc stuff for quite a while already.
Tomorrow I will have been with Omnimaga for a year :O
-
Nice. :)
Builderboy, I just tried your version, and it works Very well! Great job! Tetris in TI Basic is really hard to make look so good, and you've done a wonderful job! ;D
When I play, I always use Up for Rotate, so in your code I changed it so there are some 2=abs(K-23 where there was K=21. ;D
I think you should make the pieces contact the walls also, and instead of moving the walls, I'd make them 2 pixels thick, so it touches and you can pxlTest. :D
Overall, Wonderful job! This is an incredible program! ;D
-
Thanks guys :)
Plus he has done calc stuff for quite a while already.
Tomorrow I will have been with Omnimaga for a year :O
yeah but didn't you join TI|BD like around the same time Omnimaga shutted down? (early 2008) Plus IIRC you were invited to TI|BD, meaning you alerady had releases there or were alerady programming for calcs before.
-
I think you should make the pieces contact the walls also, and instead of moving the walls, I'd make them 2 pixels thick, so it touches and you can pxlTest.
Hmmmm? The walls are tested using Pxl-Tests, I just moved them to give a more styalized design, although it doesnt seem like it is catching on ;D The pixel that is being tested is in the center of any given block, so walls are tested just like pieces. I'm thinking that i should add lines in the spaces now, though :P
And yeah DJ i have been programing for a lot longer than I have been on Omnimaga, i was just celebrating a glorious day ^^ Hmmm the release of Vortex on TiCalc is dated to about 2 years ago, and i believe i got into programing in the beginning of the year, so i have been in the community for about 2 and a half years :)
-
That reminds me I should really give this game, your old Portal clones as well as a few others like Tetris a try. I tried trapped but gave up cuz I couldn't solve most puzzles :( (I suck at those games. For the 15th level of Portal for the PC, i had to rely on an online walkthrough to figure out how to get past the 00:37 part of this video x.x after trying to figure out for 2 hours.
-
Heh, yeah thinking with Portals can be very tricky :) especially for people who aren't as good at puzzle games.
-
I think you should make the pieces contact the walls also, and instead of moving the walls, I'd make them 2 pixels thick, so it touches and you can pxlTest.
Hmmmm? The walls are tested using Pxl-Tests, I just moved them to give a more styalized design, although it doesnt seem like it is catching on ;D The pixel that is being tested is in the center of any given block, so walls are tested just like pieces. I'm thinking that i should add lines in the spaces now, though :P
Right now it's like this:
Line, Space, Blocks
I think it would look better as:
Line,Line,Blocks
This lets you pxlTest and lets the wall come all the way in. ;D
-
Ah, gotcha. Well it already uses PixelTests for the walls, but the graphical change would be nice i think :)
-
I agree ^^ I am curious how good it would look like
-
Ya, it looks good either way though, but the gap is a bit odd :P Great work :)
By the way, Happy-One-Year-on-Omnimaga-a-Day-Ahead-of-the-Actual-date! :P
-
The unfortunately down side of builder boy leaving me in the dust is that I was using the competition as motivation and cause he finished so fast I no longer have as much motivation.
I also must note to builder boy that your codes wall time (actual execution time) is in fact not the ultimate determinate of programs quality this case as long as your code can respond and change everything in <1/60 of a second it doesn't matter how quick you do things with in that so the real challenge is to make an appearance of faster running not a straight up faster running piece of code. if it's impossible to do a full render do as close as you can and clean up next frame. that is the key to making the game look better.
we are look at run times in the 1/1000 of a second range. One must realize that you can do quite a bit in 1/60 of a second.
there is a definite place for interlacing and the like.
-
Mhmm sorry I couldn't understand perfectly what you are saying, Could you rephrase a bit? Sorry english is not my native language.
-
So you live in Quebec then?
EDIT: Stupid question. Should've seen your profile ::)
-
My point was that we are messing with a difference of <.001 seconds when the only responsiveness that is important is that of updating the screen in <.01666 of a second so though builder boy's programs wall time is low wall time is not always the most important. And actually after a review of the data that builder boy has supplied and a few of my own test (inaccurate as they may be) I think builder boy's got me beat on this one his code runs fast enough that all of this is irrelevant. I just now have been able to get the code over to my calculator and it runs faster than I think mine could. It just goes to show me and everyone else the simplest solution is often the best. Although I think I have a couple of small improvements on his code but I won't post them because I'm not at all sure they are actually any faster.
-
I usually optimize for speed in BASIC when I want the highest speed possible but it really depends of people and programs as well as what people are aiming for.
@Willrand yeah Quebec. A bunch of the forum users actually speak french as native language or speak it a lot (altough they mostly live in Europe)
-
I usually optimize for speed in BASIC when I want the highest speed possible but it really depends of people and programs as well as what people are aiming for.
Normally I do that too, although I also sometimes optimize for size. :D
-
Yeah the issue is that often in BASIC you need every picosecond you can save because every single token seems to slow things down x.x.
In ASM you will add a bunch of code and it will still run relatively fast.
-
Well don't let this discourage you from working on games. If anything let it be a learning experience :) There is always more we can learn about the TiOS, even I don't know all the tricks.
-
But sometimes it gets so bad that you want to run back to axe parser and put a blanket over your head....
Once on the 86 I tried a simple grayscale method. I found that clrdraw actually takes less time than zooming, and got a flickery gray! However, you had to repeat it over and over as, when it got to the goto and lbl, it would have a noticable pause.
I would've killed for 86 xlib that day.
EDIT: I meant it takes more time than zooming
-
But sometimes it gets so bad that you want to run back to axe parser and put a blanket over your head....
Once on the 86 I tried a simple grayscale method. I found that clrdraw actually takes less time than zooming, and got a flickery gray! However, you had to repeat it over and over as, when it got to the goto and lbl, it would have a noticable pause.
I would've killed for 86 xlib that day.
oh never use Lbl/goto for loops. Use While/repeat/for() with End so you dont have the pause thing
On the 83+ with xlib you can have decent looking grayscale and on the SE with Omnicalc too (see Reuben Quest)
-
problem is, I had an 86.That's why I said I'd kill for xlib. If you don't know what that means (local colloquealism) basically it means I really wanted it.
Actually, at that point I didn't know how to use the for( function. :P Now i can't try it since that calc is dead.
I got really good grayscale with disp once, but it left annoying strings of flickering characters above it.
-
Yeah I know, I was just saying about the 83+ ^^
I wish the 86 had sometime like xLIB or Axe Parser and that the calc was more popular. It has a lot of RAM and is user friendly. The BASIC language on it is 1.5x slower than the TI-85 x.x so it can't achieve very complex games :(
-
it is also very old, older than the 83+ but newer than the 83 I believe.
However, I'll bet he was right in the description about it being overclocked. No calc had that speed in TI-Basic Naturally. after all, that was the time when overclocking was popular.
Pics take up a little more space too, but not a whole lot more. On the 86 they're 1024 Bytes.
The real issue I had with the 86 was no archive space. Using just ram meant you could only have about 5 pics before your program got rather unwieldly.
-
yeah I still wish TI marketted the 86 better and made a 86+ or 86+SE. It was awesome and not that hard to use. Some people before argued that the 89 was a TI-86 when I said I wish there was a 86+, but the 89 is not a z80, has less user-friendly usage due to the many options and different TI-BASIC language. It's just not the same calc
-
I like the 89 It fixes a lot of things that were wrong with the TI basic language. For example something I found yesterday matâ–¶list() and listâ–¶mat() functionality was fixed to A) make sense and B) be useful.
Although I don't like having a difference between end statements for if while and for I liked the single end statement It allow for some useful exploits of the interpreter.
It is much different from 84 basic though
Edit: I think you should disregard this cause I think I'm getting my calculators confused
-
I liked the EndIf, EndWhile, etc, actually. Altough it can end up confusing for someone used to just one instruction, it made it much easier IMHO to spot loops, conditions and other stuff that were not closed (had a missing End instruction). With just End, you have to count each While/if/repeat/etc. then count down everytime you see "End" and you can easily mess up in complex code with like 6 or 7 nested loops/if
-
I see the benefit but because of it you can't play games like this:
:1->X
:goto START
:lbl LABEL
:pause "LABEL
:End
:lbl START
:pause "start
:If x=12
:Then
:pause "X=12
:Return
:End
:while X<11
:Pause "WHILE
:x+1->x
:If remainder(x,2
:goto LABEL
:Pause "While BOTTOM
:End
:For(b,1,2
:goto LABEL
because For( behaves differently from While when exiting you can do some really crazy things
In practice this trick is extremely hard to pull off but you can do things like inline recursion and complex stack insanity rather quickly without the use of extra programs.
Normally doing this is like playing with fire but it's occasionally useful.
-
is that the Goto trick with End to not have memory leaks that is discussed on TI-BASIC Developer? I guess maybe that's a disadvantage of EndIf/EndWhile, then x.x. I never used this trick, though, since the last time I ever used a Lbl/Goto command in a TI-83 Plus BASIC game was in The Reign Of Legends 3, which I worked on from December 3rd 2003 to June 11th 2004. Afterward none of my game contained Lbl/Goto again and I did not know about that trick because TIBD did not exist until late 2006, at a time where I hardly coded anymore.
-
this is something of my own meandering. Although other people have probably figured it out. I'm sure builder boy and weregoose have figured out this trick and possibly used it once or twice. It has limited application outside of complicated implicit stacks and even then it's far easier to use sub routines. The applications for which it gains you anything are not easy to determine at all. I used it once (other then messing around with it to confuse people) in a program that shaded an arbitrary area.
-
yeah I heard it wasn't very practical in many cases. I guess it can come useful for people who love to use Lbl/goto a lot and understands such code better. I understand that several nested While/repeat can become confusing about where each ends x.x
I could show the code for Illusiat 13 menu and I am fairly certain some people may get confused
-
I believe there is a Thread about that method in the Useful Routines section :) It is indeed a very very tricky and cool way to do subs, and jumping around the program. What can be considered a glitch is also an exploit! ;)
-
yeah I heard it wasn't very practical in many cases. I guess it can come useful for people who love to use Lbl/goto a lot and understands such code better. I understand that several nested While/repeat can become confusing about where each ends x.x
I could show the code for Illusiat 13 menu and I am fairly certain some people may get confused
With the hnefatafl AI, there was like 7 stacked If...Then/While/For that it was hard to keep track of all the ends. :P
And this routine does seem very useful. Especially if you want to decrease the number of programs for the ease of transfer (I'm now considering to use for Hnefatafl since I want to make it all into one program, but there are many recurring codes so I might do this thing)
-
To you I say good luck my friend and be careful.
-
Yes, but the coding would have to be extremely accurate. I have tried it once, my tetris game "fell apart" I think it's best with matrices.