I'm writing a game. Everytime you die in the game, you are thrown back to the main menu. At the top of the menu code I have lots of line devoted to resetting all my variables to 0. For instance:
i was thinking you could make 1 varible = all yours
and just reset the 1 varible but it ends up being the
same thing you have to type out all 50+ variables anyways...
maybe you should go thru your varibles and see whats
the same as some of the others and reduce some of them
to 1 variable?
No you cant unless you dont stop and rerun program.
But if you have so many variables to clear at once, maybe you should aproach this one from bit different direction.
Do an array, Weapon()
Weapon(1)
Weapon(2)
and so on.
At start of code, DIM all same variable you have now.
revolvernum as 1
bulletnum as 2
and so on.
Now, if value of revolvernum changes (i assume you use simple "variable = variable + 1") etc.
┌─────────────────────── HELP: CLEAR Statement Details ────────────────────┤↑├─
│ ◄QuickSCREEN► ◄Details► ◄Example► ◄Contents► ◄Index►
│──────────────────────────────────────────────────────────────────────────────
│Details
│
│Syntax
│ CLEAR [,,stack]
│
│The CLEAR statement performs the following actions:
│
│ ■ Closes all files and releases the file buffers
│ ■ Clears all COMMON variables
│ ■ Sets numeric variables and arrays to zero
│ ■ Sets all string variables to null
│ ■ Reinitializes the stack and, optionally, changes its size
│
│The stack parameter sets aside stack space for your program.
│QuickBASIC takes the amount of stack space it requires, adds the
│number of bytes specified by stack, and sets the stack size to the
│result.
│
│ Note: Two commas are used before stack to keep QuickBASIC compatible
│ with BASICA. BASICA included an additional argument that set the
│ size of the data segment. Because QuickBASIC automatically manages
│ the data segment, the first parameter is no longer required.
│
│If your program has deeply nested subroutines or procedures, or if
│you use recursive procedures, you may want to use a CLEAR statement
│to increase the stack size. You may also want to increase the stack
│size if your procedures have a large number of arguments.
│
│Clearing the stack destroys the return addresses placed on the stack
│during the execution of a GOSUB. This makes it impossible to execute
│a RETURN statement correctly and produces a "RETURN without GOSUB"
│run-time error message. Using a CLEAR statement in a SUB or FUNCTION
│produces a run-time error message that reads "Illegal function call."
│
│Differences from BASICA
│
│BASICA programs using CLEAR may require modification. In BASICA
│programs, any DEF FN functions or data types declared with DEFtype
│statements are lost after a CLEAR statement. In compiled programs,
│this information is not lost because these declarations are fixed at
│compile time.
lurah wrote:No you cant unless you dont stop and rerun program.
But if you have so many variables to clear at once, maybe you should aproach this one from bit different direction.
Do an array, Weapon()
Weapon(1)
Weapon(2)
and so on.
Yeah. This is how I thought I was going to have to do it. However, I noticed that the CLEAR statement seems to do the trick. Thanks for the suggestion though.
Stoves wrote:The CLEAR statement performs the following actions:
?
? ? Closes all files and releases the file buffers
? ? Clears all COMMON variables
? ? Sets numeric variables and arrays to zero
? ? Sets all string variables to null
? ? Reinitializes the stack and, optionally, changes its size
It works like a charm Stoves. Hell yes! Thanks a lot.
' Create a structure for our variables
TYPE ProgamVars
var1 as integer
var2 as integer
var3 as integer
..
varN as integer
END TYPE
DIM SHARED vars AS ProgramVars 'create our variables
DIM SHARED init AS ProgramVars 'create our init values
' Set our init values
init.var1 = 0
init.var2 = 0
init.var3 = 0
..
init.varN = 0
vars = init 'copy init values into our variables
The advantage of this setup is that you can define your init values to be anything you want, not just zero. More over, because your variables are contained within a TYPE, they become easier to manipulate. Saving, loading and copying can be done by referencing the TYPEd variable (vars or init), instead of the individual variables that comprise the TYPE.
In my experience, properly designing your code structure is one of the most important parts of creating flexible code that's easy to work with. Normally this means grouping your variables properly using User Defined TYPEs (UDTs) and arrays.