7 replies to this topic

[Byte Knight]

Whenever I program a game in batari basic, I seem to use up the 26 allowed variables very quickly. So, feel free to post techniques of using up fewer variables in this thread.

Something I just discovered - the way I used to prevent a player (or ball in this case) from going through a playfield wall was like this:

main
 x=ballx:y=bally

 if joy0right then ballx=ballx+1
 if joy0left then ballx=ballx-1
 if joy0up then bally=bally-2
 if joy0down then bally=bally+2

 drawscreen

 if collision(ball,playfield) then ballx=x:bally=y

 goto main

This takes up more memory (which is less of a concern with the new kernel), but ends up saving 1.5 variables:

main
 x{0}=0:x{1}=0:x{2}=0:x{3}=0

 if joy0right then ballx=ballx+1:x{1}=1
 if joy0left then ballx=ballx-1:x{3}=1
 if joy0up then bally=bally-2:x{0}=1
 if joy0down then bally=bally+2:x{2}=1

 drawscreen

 if collision(ball,playfield) && x{1} then ballx=ballx-1
 if collision(ball,playfield) && x{3} then ballx=ballx+1
 if collision(ball,playfield) && x{0} then bally=bally+2
 if collision(ball,playfield) && x{2} then bally=bally-2

 goto main

So, you've still got half of x and all of y to play around with!

Any other variable-saving techniques out there?

[Random Terrain]

Byte Knight, on Fri Jun 17, 2011 11:02 PM, said:

Any other variable-saving techniques out there?

Is that similar to what I'm doing here:

http://www.atariage....xample-program/

[Byte Knight]

Random Terrain, on Fri Jun 17, 2011 11:11 PM, said:

Byte Knight, on Fri Jun 17, 2011 11:02 PM, said:

Any other variable-saving techniques out there?

Is that similar to what I'm doing here:

http://www.atariage....xample-program/

Wow, that's smooth as a baby's bottom!

I suppose if I used pfread after a collision check to see which part of the ball was touching the playfield, I wouldn't have to use any extra variables at all! Unfortunately, the new kernel doesn't seem to support pfread yet...

[Random Terrain]

Byte Knight, on Sat Jun 18, 2011 9:17 AM, said:

Unfortunately, the new kernel doesn't seem to support pfread yet...

I hope it will. pfread sure is a nice thing to have.

[theloon]

Re-DIM-ing variables and using the re-DIMed variables in different game sections has helped me. If if I know the variable won't be used and doesn't need to be retained in a seperate game section then it's fair game for re-DIM-ing

[theloon]

..somehow double posted

Edited by theloon, Sat Jun 18, 2011 5:16 PM.

[Byte Knight]

theloon, on Sat Jun 18, 2011 5:14 PM, said:

Re-DIM-ing variables and using the re-DIMed variables in different game sections has helped me. If if I know the variable won't be used and doesn't need to be retained in a seperate game section then it's fair game for re-DIM-ing

Great tip! I didn't even know you could re-dim variables. I can now save two variables in my next game...

[Random Terrain]

Byte Knight, on Sat Jun 18, 2011 11:48 PM, said:

I didn't even know you could re-dim variables. I can now save two variables in my next game...

That's mentioned on the bB page:

http://www.randomter...mmands.html#dim

Quote

Note that more than one alias may be mapped to the same variable. This is useful for when you will inevitably need to reuse variables in multiple places.

But it's about the 5th paragraph down, so people might miss it. I'll put it in a "Did You Know?" box so it will be more noticeable.

I do it for a few variables that can be reused, but I especially do it for bit operations:

   rem  ****************************************************************
   rem  ****************************************************************
   rem  *
   rem  *  Create aliases for variables.
   rem  *
   rem  ****************************************************************
   rem  '
   rem  '  (You can have more than one alias for each variable.)
   rem  '
   rem  '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

   rem  ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
   rem  '
   rem  '  All-purpose bits for various jobs.
   rem  '
   rem  ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
   rem  '
   dim BitOp_All_Purpose_01 = t

   dim BitOp0_Debounce_Reset = t

   dim BitOp4_Toggle_Screen = t

   dim BitOp5_B_Direction_X = t

   dim BitOp6_B_Direction_Y = t

   dim BitOp7_Missile0_Moving = t



   rem  ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
   rem  '
   rem  '  Player0/Missile0 direction bits.
   rem  '
   rem  ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
   rem  '
   dim BitOp_P0_M0_Direction = u

   dim BitOp0_Player0_Direction_Up = u

   dim BitOp1_Player0_Direction_Down = u

   dim BitOp2_Player0_Direction_Left = u

   dim BitOp3_Player0_Direction_Right = u

   dim BitOp4_Missile0_Direction_Up = u

   dim BitOp5_Missile0_Direction_Down = u

   dim BitOp6_Missile0_Direction_Left = u

   dim BitOp7_Missile0_Direction_Right = u

I've had weird random problems with def, so I'm back to just using bit operations the old regular way. Using a separate name for each bit helps me know exactly what is going on at a glance.

Edited by Random Terrain, Sun Jun 19, 2011 12:16 AM.