N00b questions about bB

[+Karl G]

12 hours ago, LatchKeyKid said:

edit:  Success!  Thanks again!  I can't seem to change the last digit to the actual number I'm putting in as the initial score (999999) but I'm actually ok with it as it'll just fly by super fast decreasing every second regardless so it'll only be visible before the gameplay starts.

In case you do want to fix it, you would set the variable for the last score digit to $9A in this case because of the binary-coded decimal encoding. Here's a version of my test program that counts down from 99999 instead.

 

pfscore_centered_countdown.bas

[LatchKeyKid]

47 minutes ago, Karl G said:

In case you do want to fix it, you would set the variable for the last score digit to $9A in this case because of the binary-coded decimal encoding. Here's a version of my test program that counts down from 99999 instead.

 

pfscore_centered_countdown.bas 527 B · 1 download

 

Thanks again and fixed again!   Subtracting 110 (so effectively 11) flips through those last two numbers in a very satisfying way to give me a 2 1/2 minute level timer (assuming no bonus points are generated) for level failure.

[+splendidnut]

On 9/27/2024 at 10:42 PM, LatchKeyKid said:

For the dim'ed sc1-3 variables, do those count against the alphabetical a-z variables you have or are they already reserved by the backend of bB?   I didn't see you in the code assigning them to a letter so I assumed the latter but figured I'd ask just in case.

With BatariBasic, DIM'ing variables doesn't do any sort of allocation... it just creates aliases for the already defined variables.   So,  "DIM myVar = a" just tells the compiler/assembler that myVar is the same as a.

 

All bBasic 'variables' are actually defined by a back-end inclusion file that's selected based on which kernel you use.   For the multisprite kernel, this would be multisprite.h file in the bbasic/includes directory.

[LatchKeyKid]

11 hours ago, splendidnut said:

With BatariBasic, DIM'ing variables doesn't do any sort of allocation... it just creates aliases for the already defined variables.   So,  "DIM myVar = a" just tells the compiler/assembler that myVar is the same as a.

 

All bBasic 'variables' are actually defined by a back-end inclusion file that's selected based on which kernel you use.   For the multisprite kernel, this would be multisprite.h file in the bbasic/includes directory.

 

Thanks.   This was the first time I had used a DIM statement as I had avoided them in my prior entry level coding attempts so wasn't sure.   I didn't realize you could assign an arithmetic value (variable plus/minus a number) to a dim without using one of the existing variables or at a bare minimum a temp.... in this case it was score+1, score+2, score+3.   Now that it's pointed out to me explicitly, I get it though. 

[LatchKeyKid]

Is there something wrong with my coding here?   I've tried a half dozen different ways to simply flip player3 on alternate frames for an explosion effect and I can't seem to get it to work no matter how I code it even though I can flip players 0-2 without any issue.   Is there a bug specifically with player3 in the multisprite kernel in this regard?   I've tried putting the code in separate lines instead of combining it, using a full variable c instead of the c{1} bit just to test it out, changing it to player5/NUSIZ5 instead of player3, and placing it in different parts of the code even in case that would matter.  Nothing seems to let me flip the virtual player sprite and I'm not sure why.

 

The relevant section from random terrain's site that I've used for instruction: 

 

https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#ephvarreg

"Therefore the values _COLUP1, COLUP2-COLUP5, _NUSIZ1, and NUSIZ2-NUSIZ5 are all persistent. Also note that bit 3 of _NUSIZ1 and NUSIZ2-NUSIZ5 contains the REFP value."

 

if c{1} then NUSIZ3{3} = 1 else NUSIZ3{3} = 0; reflect explosion on alternating frames

c{1} = !c{1}; swap alt frame counter

   

[+Random Terrain]

Does making sure there is a space before and after each semicolon help?

[+Karl G]

44 minutes ago, LatchKeyKid said:

c{1} = !c{1}; swap alt frame counter

I don't know that this syntax would work to invert a bit. Try this instead:

 

    c = c^2 ; Flip value of bit 1

 

[LatchKeyKid]

9 minutes ago, Karl G said:

I don't know that this syntax would work to invert a bit. Try this instead:

 

    c = c^2 ; Flip value of bit 1

 

 

I got the coding from this entry on RT:

 

https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#dim

 

"The example below shows how you can flip a bit:

a{2} = !a{2}"

 

There are some later examples about using power notations so I'll try that.  I did find the mistake that I made in that I defined the original NUSIZ values in the main loop instead of before it and setting the main NUSIZ3=$05 obviously changed the third bit as well every frame after I manually flipped it previously.   Do'h!

[+Karl G]

16 hours ago, LatchKeyKid said:

 

I got the coding from this entry on RT:

 

https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#dim

 

"The example below shows how you can flip a bit:

a{2} = !a{2}"

 

There are some later examples about using power notations so I'll try that.  I did find the mistake that I made in that I defined the original NUSIZ values in the main loop instead of before it and setting the main NUSIZ3=$05 obviously changed the third bit as well every frame after I manually flipped it previously.   Do'h!

Looks like you are correct! I had never tried it that way, though. Certainly that notation is more readable. Good to know.

[LatchKeyKid]

Thanks and I'm glad it helps.   It's definitely more readable for me as well which is why I tried it.  Unfortunately, I didn't take into account my other coding reversing the changes I was making before the drawscreen happened (and in any case the explosion was too quick at alternate frames so never would have worked).   I may instead try a solid block that expands instead eventually but for now just took it out to focus on one mechanic at a time.