Can someone please explain to me the differences between while and goto. My program is quite long and things are getting a little laggy with all of the goto statements and I have heard that while loops don't cause as much lag. Possibly, can someone do a before and after example where they show a goto program and then the converted while program. Thanks!

How are you using Goto/Lbl in your program? If it's your main loop, switching it to Whiles will be quite easy, else *shrug* TI Freak is more advanced in the use of Whiles than I am.

While is a loop, it executes the commands within until a certain condition is not met. Goto jumps to any part of your prpgram, and while it can be used as a While loop, it is not recommended and may cause memory leaks.
Example:

Code:


This will repeat the commands between While X>14 and End until variable X is not greater than 14.

Well, my program is basically a game that has many sub menus. I have the main menu which asks if you want to play single player or multiplayer. In the single player, there are like 15 other sub menus within the code. I also have some lbls that are off to the side. One is a healing label and another is a fighting label.

I have a healing label within each menu which is a "round" and a fighting label which I call in between rounds. Just the more I add on to the code, the farther and farther away it gets from the fighting and healing lbls.

I've noticed a delay from round 1 compared to round 15. Round 1 usually heals or fights instantly, but round 15 takes a second or so to load.

It's not that Gotos inherently cause lag; it's that Goto'ing out of a For()/End, Them/End, While()/End, or Repeat()/End causes what's called a memory leak, because the calculator will continue to wait for the End that it's never going to see. Can you post a sample of your code so we can demonstrate the removal of the Gotos, or a way to reduce the lag without removing the Gotos?

Edit: Ah, and yes, Round 15 will be laggier because when you use a Goto, the TI-OS always starts at the beginning of the program and searches down until it finds the corresponding Lbl XX statement. The further into the program the Lbl is, the longer the Goto has to search.

Basically, anywhere you have something like:

Code:

This can be replaced with:

Code:


So, for example, if you have this number guessing game:

Code:
This could be turned into a while loop:

Code:
And this could even be bettered with a Repeat loop:

Code:

Ok, well here is a small example of a round, and the battle scene. Commentary is in parenthesis:
--------------------------------
:Lbl 39 ('Round 15')
:12→L (Minimum level, L stands for Low)
:15→H (Maximum level, H stands for High)
:28→X (The label that the program goes to if you win)
:Goto 99 (The battle scene)


:Lbl 99
:ClrHome
:randInt(L,H)→A
:2*A+12→E (Health)
:iPart(E)→E
:2*A+8→O (Attack)
:iPart(O)→O
:2*A+8→R (Defense)
:iPart(R)→R
:Lbl 92
:Menu("Battle Menu","Fight",97,"Run",95)
:Lbl 95
:ClrHome
:Disp "Got away safely"
:Pause

*****Also, the code below is used to goto the correct menu after running from a battle depending on the player's current position in the world.
I tried to use Goto X, but that won't work. Is there an easier way to do this?*****

:If X=12
:Goto 12
:If X=5
:Goto 5
:If X=15
:Goto 15
:If X=24
:Goto 24
:If X=25
:Goto 15
:If X=28
:Goto 28
:If X=37
:Goto 37
:Lbl 97 (If both the user and the enemy still has more than 1 hp, this is the loop that makes them both attack again)
:ClrHome

***Battle and fighting***

***Checks whether the user and the enemy is still alive)***

:Goto 97 (If both the user and the enemy still has more than 1 hp, this is the loop that makes them both attack again)

Merth, there is a small difference between the original Goto loop and the While loop you provided. The Goto loop is more like a do { ... } while() loop in C.
So, this code:

Code:

more accurately becomes:

Code:

does it not?

Yeah, you're right. That's why in my number guessing example I had to set a value to B before the while loop. Good call, though, as without the initial value, it would behave differently than expected.

Beta7, do the transformations that have been mentioned here make sense? One possible solution would be one massively-long While or Repeat loop, inside of which you could have 15 If:Then:End statements for your fifteen different levels. That would certainly more or less normalize the level loading time imho, at the expense of being harder to keep track of as a programmer.

You could also break them up into sub-programs.

I thought about mentioning that, but the idea of fifteen subprograms sounds a bit intractable. Maybe three subprograms each containing five of the levels?

That sounds like a good idea. Another program that I have been working on since August now is a text based Pokemon Red. It has no graphics, but still the program itself is taking up about 15,000 bytes. I am not really sure what to do now because of the large space. Things are starting to lag. Also, the user will run out of ram to do anything.

Is there a way I can run the program while it is archived? Mirage OS can do that, but is there an easier way, or should I just make a 2nd program?

when making large games like this, splitting the game up into sub programs is definitely a must.

Just the thing is, there are some difficulties with splitting the program. Some of the required labels(functions) are in the original program. How would I call those and then go back to the 2nd program?

You shouldn't be using MirageOS (although I'm biased); it's buggy and outdated. Grab my shell Doors CS 7 instead, which can do everything MOS can do and so, SO much more, including (in your case) running archived programs from the homescreen. Indeed, you can use the third-party BASIC libraries it includes to archive and unarchive your subprograms on the fly, essentially giving your program unlimited space to grow:

http://dcs.cemetech.net/index.php?title=Third-Party_BASIC_Libraries

I downloaded your Doors CS 7 and I tried it out on my calculator. It is really neat with all of its features, and I also noticed how it could run my archived programs. I especially liked how it could scroll instantly to wherever an error occurs in a program unlike the calculator's default snail pace.

But there was one problem with the editing. If there is a bug section for Doors CS 7, I should probably post it there. I just noticed that there is, so I will continue my post there

Sounds good, I look forward to your report. In the meantime, I presume you'd like to hear more about the program archiving/unarchiving functions, or do you need to resolve your label conflicts first?

Well, I will continue my archiving talk here and then post the bug report in the proper forum. Right now I am making a comparison of the before I edit using doors CS and after. I lose 70 lines of code mysteriously sometimes, and I am using an editor to compare the files to find where the difference is.

Anyways, my program is currently using over 100 labels or so. Things are getting very messy so I think that I am going to make a 2nd program. But the thing is, the first program has some key functions/labels in it that the 2nd program will need such as the battle/level up function and pokemon center function.

How would I refer to those functions in the 2nd program? Would I have to copy those essential functions to the 2nd program, or can I call those functions from my 2nd programs?

KPA, you may not want to hear this, but you should essentially stop at this point and set up a second or even third program that will allow you to call on routines that are needed a lot. You would need data programs and programs that execute routines and all sorts of things. There is no way you are going to pack in an entire pokemon game in one program, or even 2. I have 50 some odd programs I think at this point and I am no where near done with mine.