11 replies to this topic

[Random Terrain]

I thought I saw someone use endif in bB without using asm. Is that possible or 'legal'? If so, I could put lines of code between the if-then and the endif and not have to use a goto or a gosub just because it all couldn't fit or work on one line. If this is possible, how is it done in bB (I should also add this info to the bB pages if it's possible).


Thanks.

Edited by Random Terrain, Thu May 22, 2008 12:59 PM.

[lord_mike]

Oh, that would be sweeet! I've been hoping for functionality like that.. it would eliminate half my goto's and the code would be much eaiser to both read and write!

That would be my #1 feature request! Add the ability to reference the bitwise variables using constants (i.e. instead of a{1}=1 be able to use a{CONSTANT_NAME}=1 and I'd be in Batari Basic heaven!!! A do...while statement and a C-like "switch" statement would be nice, too, but that's icing on the cake!

Edited by lord_mike, Thu May 22, 2008 1:05 PM.

[batari]

lord_mike, on Thu May 22, 2008 2:03 PM, said:

Oh, that would be sweeet! I've been hoping for functionality like that.. it would eliminate half my goto's and the code would be much eaiser to both read and write!

That would be my #1 feature request! Add the ability to reference the bitwise variables using constants (i.e. instead of a{1}=1 be able to use a{CONSTANT_NAME}=1 and I'd be in Batari Basic heaven!!! A do...while statement and a C-like "switch" statement would be nice, too, but that's icing on the cake!

The working version of bB i have now already supports something like you say for bitwise variables. Actually it's more powerful than that. It works like this:

def CONSTANT_NAME=a{1}

...

CONSTANT_NAME=1


As for long if-thens, I dunno - you can already do that easily.

E.g., instead of

  if x=4 then x=t-2:mosterheight=(monsterheight&7)+1:pfhline 3 4 x off:a=(rand&127)+16:r{0}=1:gosub killmonster

negate the condition, like this:

  if x<>4 then here
  x=t-2:mosterheight=(monsterheight&7)+1
  pfhline 3 4 x off:a=(rand&127)+16:r{0}=1
  gosub killmonster
here

Is that really any worse than this:

  if x=4 then
  x=t-2:mosterheight=(monsterheight&7)+1
  pfhline 3 4 x off:a=(rand&127)+16:r{0}=1
  gosub killmonster
endif

Edited by batari, Thu May 22, 2008 2:29 PM.

[Random Terrain]

batari, on Thu May 22, 2008 4:28 PM, said:

As for long if-thens, I dunno - you can already do that easily.

E.g., instead of

  if x=4 then x=t-2:mosterheight=(monsterheight&7)+1:pfhline 3 4 x off:a=(rand&127)+16:r{0}=1:gosub killmonster

negate the condition, like this:

  if x<>4 then here
  x=t-2:mosterheight=(monsterheight&7)+1
  pfhline 3 4 x off:a=(rand&127)+16:r{0}=1
  gosub killmonster
here

Is that really any worse than this:

  if x=4 then
  x=t-2:mosterheight=(monsterheight&7)+1
  pfhline 3 4 x off:a=(rand&127)+16:r{0}=1
  gosub killmonster
endif

Thanks. So just switch it around. Duh! That makes sense. I will now smack myself in the forehead with a baseball bat. So there's nothing wrong with using a bunch of labels like that then? It doesn't waste cycles or carsnooples or jumtibbles or any of that stuff that is still over my head?

[batari]

The additional labels to not hurt in any way.

I expect someone will ask, "what if I have boolean operators?"

So to preemptively answer that question, you invert each individual condition and change && to || or vice-versa.

E.g.:

  if x=4 && y=2 then r=4

becomes:

  if x<>4 || y<>2 then here
  r=4
here

or:
  if !joy0up || r<4 then e=e+1

becomes:

  if joy0up && r>=4 then here
  e=e+1
here

[Random Terrain]

batari, on Thu May 22, 2008 6:14 PM, said:

The additional labels to not hurt in any way.

Thanks. That's good news.

batari, on Thu May 22, 2008 6:14 PM, said:

I expect someone will ask, "what if I have boolean operators?"

So to preemptively answer that question, you invert each individual condition and change && to || or vice-versa.

I figured that one out on my own, so I'm slightly less stupid than I was before.

[Gorf]

Random Terrain, on Thu May 22, 2008 3:39 PM, said:

So there's nothing wrong with using a bunch of labels like that then? It doesn't waste cycles or carsnooples or jumtibbles or any of that stuff that is still over my head?

A label is nothing more than a marker to a place in memory.
The only resource it takes up is the text use to spell it in your
code file. Labels are your friend.

(Besides, how else do you think I got away with what is so far Tempest 2600...works for me!)

[Random Terrain]

Gorf, on Tue May 27, 2008 5:49 AM, said:

Random Terrain, on Thu May 22, 2008 3:39 PM, said:

So there's nothing wrong with using a bunch of labels like that then? It doesn't waste cycles or carsnooples or jumtibbles or any of that stuff that is still over my head?

A label is nothing more than a marker to a place in memory.
The only resource it takes up is the text use to spell it in your
code file. Labels are your friend.

(Besides, how else do you think I got away with what is so far Tempest 2600...works for me!)

Thanks. I thought that all of the labels or 'goto-ing' to the labels would waste cycles or something. Nice to know I can use this and not jump to subroutines or fake subroutines where I use goto instead and jump back to a label. I can keep it all right where it is instead of stuffing code in my cheeks like a squirrel.

[Nukey Shay]

Although you might not realize it, a conditional GOTO instruction is already being used in all IF-THEN statements. IF {condition} THEN {action}. If the condition is false, the action is skipped. Alternately, they could skip ahead unless a condition is false. In either case, a branch is occuring.

Labels themselves do not increase a program's memory usage. They are just a point of reference for the interpreter, regardless of if they are used.

[Random Terrain]

Nukey Shay, on Tue May 27, 2008 7:05 AM, said:

Although you might not realize it, a conditional GOTO instruction is already being used in all IF-THEN statements. IF {condition} THEN {action}. If the condition is false, the action is skipped. Alternately, they could skip ahead unless a condition is false. In either case, a branch is occurring.

Labels themselves do not increase a program's memory usage. They are just a point of reference for the interpreter, regardless of if they are used.

Thanks. So I'm 'goto-ing' all of the time anyway.

[Gorf]

Random Terrain, on Tue May 27, 2008 6:00 AM, said:

Thanks. I thought that all of the labels or 'goto-ing' to the labels would waste cycles or something. Nice to know I can use this and not jump to subroutines or fake subroutines where I use goto instead and jump back to a label. I can keep it all right where it is instead of stuffing code in my cheeks like a squirrel.

Remember that labels can also be a marker to a data location. The data location does take memory space
but the label dont, nor will it ever waste any cycles.

[Gorf]

Nukey Shay, on Tue May 27, 2008 7:05 AM, said:

Although you might not realize it, a conditional GOTO instruction is already being used in all IF-THEN statements. IF {condition} THEN {action}. If the condition is false, the action is skipped. Alternately, they could skip ahead unless a condition is false. In either case, a branch is occuring.

Labels themselves do not increase a program's memory usage. They are just a point of reference for the interpreter, regardless of if they are used.

Yes good point. Once the compiler unravels it, its a 'jmp'(goto)
To sum it up even smaller. Labels are memory location bookmarks.