N00b questions about bB

[LatchKeyKid]

13 minutes ago, Gemintronic said:

As a side my experiments with bB code flicker management have always been worse.  Tried doing something akin to NES sprite order cycling and it just interfered with the built in flicker management.

Are you referring to more complex DPC/multisprite kernel flicker management in the underlying bB compiler code or just the more simple alternating frame player sprite management in the basic code mentioned earlier in the thread by Splendidnut?   I was hoping to try the latter obviously only once I actually got pixels moving on the screen first.  

[+Gemintronic]

1 hour ago, LatchKeyKid said:

Are you referring to more complex DPC/multisprite kernel flicker management in the underlying bB compiler code or just the more simple alternating frame player sprite management in the basic code mentioned earlier in the thread by Splendidnut?   I was hoping to try the latter obviously only once I actually got pixels moving on the screen first.  

 

I think what I tried was with the multi sprite kernel.  Basically, every main loop I'd swap player0 through 5 sprites and positions.

[+TwentySixHundred]

1 hour ago, Gemintronic said:

 

I think what I tried was with the multi sprite kernel.  Basically, every main loop I'd swap player0 through 5 sprites and positions.

I tried this method and spent a good month trying to perfect it. It's horribly slow even with just two alternating sprites, making it unusable for any real game. I even tried executing drawscreen mid code and repositioning, which rendered all the sprites but tanked performance. Think the issue is the drawscreen function where a function like drawsprite would be more suited. The function drawsprite would allow that sprite to be drawn midway through code execution so the sprite can be re-positioned and drawn again before drawscreen executes the full frame. This is all just a pipe-dream as it would probably still be too slow.

[+splendidnut]

If you want to experiment with sprite flicker techniques in the bB Multisprite Kernel, it would probably work out better if you disable the original code first.  The original code does a pretty decent job outside of a couple of edge cases... Literal edge cases, where a sprite goes off the top/bottom of the screen.  I was looking at ways of trying to fix that a few months ago.

 

As for 'drawscreen' / 'drawsprite':  I agree that it would be nice to have stack-able kernels.  It wouldn't necessarily be a performance issues... more of an implementation issue.  The bBasic compiler would need to be modified quite a bit to support it.  The drawscreen command is relatively straight forward; it does a subroutine call to the display kernel.   The display kernel code does all the heavy lifting of video frame management:  handling VSYNC, the VBLANK at the top of the screen (where kernel preparations are done), and running the display kernel to draw the screen.   If you want more flexibility, all that would need to be broken apart, at the very least into 'startvideoframe' and 'drawkernelrow' functions.

 

That's partially what lead me to developing Neolithic C : the ability to play around with video frame loop code from a blank canvas.  These sorts of things can be done in bBasic as well, but require changes that can fit in without breaking what's there.

[LatchKeyKid]

Well, my first attempt at putting pixels on the screen just by watching the Telemachus and Bob the Hedgeoctopus bB instructional video series and using what they did as a template didn't go so well.   It seems that bB is VERY sensitive to indentation and wouldn't successfully compile anything I wrote until I basically copy pasted over a randomterrain file so it's definitely a me problem, lol, and not visual studio.  Is there a guide as to what needs to be indented and how much?

[+Random Terrain]

32 minutes ago, LatchKeyKid said:

Well, my first attempt at putting pixels on the screen just by watching the Telemachus and Bob the Hedgeoctopus bB instructional video series and using what they did as a template didn't go so well.   It seems that bB is VERY sensitive to indentation and wouldn't successfully compile anything I wrote until I basically copy pasted over a randomterrain file so it's definitely a me problem, lol, and not visual studio.  Is there a guide as to what needs to be indented and how much?

 

The bB page has this section:

 

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

[+splendidnut]

Every line needs to be indented by at least a single space EXCEPT for lines that are labels, or the 'end' keyword.  That is how bBasic detects labels being defined.

[LatchKeyKid]

11 minutes ago, Random Terrain said:

 

The bB page has this section:

 

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

 

10 minutes ago, splendidnut said:

Every line needs to be indented by at least a single space EXCEPT for lines that are labels, or the 'end' keyword.  That is how bBasic detects labels being defined.

 

Thanks!  Somehow I missed that guide.  Does it matter how much things are indented?  Some of the sample programs I've seen (whether on the site or posted here by other new coders) have different levels of tabs but I wasn't sure if that's just for asthetics/personal organization or if it has an effect given the relative importance of indenting.   For reference, the last time I used any form of basic was when it had line numbers on an Apple IIe. 

[LatchKeyKid]

On a similar note, I wanted to make sure I didn't pick up any fellow n00b habits so had another question.   I saw in one program that a coder assigned player0x and y to one of the alphabet available variables but I didn't see that in any sample programs and programs seem to work without it.  Is that just wasteful and unnecessary coding on his part due to inexperience?  I kind of assumed key preassigned compiler sprite variables were locked in outside of the a-z programmer assigned variables.

[+splendidnut]

7 minutes ago, LatchKeyKid said:

I kind of assumed key preassigned compiler sprite variables were locked in outside of the a-z programmer assigned variables.

Correct.  The sprite variables used by the display kernel are defined by the bBasic kernel that is used, so you do not need to define them.

[LatchKeyKid]

11 minutes ago, splendidnut said:

Correct.  The sprite variables used by the display kernel are defined by the bBasic kernel that is used, so you do not need to define them.

Thanks again for all the very quick help!  I'll probably post a few more questions tonight as I incorporate the above.

[+Random Terrain]

1 hour ago, LatchKeyKid said:

Does it matter how much things are indented?

 

I always indent with 3 spaces so it's easier to tell that a line is indented. I've seen people indent with one space and it can be hard to tell that the line is indented at all.

 

 

1 hour ago, LatchKeyKid said:

I saw in one program that a coder assigned player0x and y to one of the alphabet available variables but I didn't see that in any sample programs and programs seem to work without it.  Is that just wasteful and unnecessary coding on his part due to inexperience?  I kind of assumed key preassigned compiler sprite variables were locked in outside of the a-z programmer assigned variables.

 

If you are talking about stuff that looks like this "dim _P0_L_R = player0x.a" you have to do that if you are using subpixel movement. Once you get past the "n00b" stage, you'll be using it a lot. It lets you control how fast your sprites are moving.

 

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

 

 

This subpixel movement, or movement of a non-integer number of pixels for each frame, allows more flexibility in gameplay mechanics than ordinary integer variables provide, or at least it simplifies the calculations that would otherwise be required using only integers. Here's an example using player0 and player1:

   dim _P0_L_R = player0x.a
   dim _P0_U_D = player0y.b

   dim _P1_L_R = player1x.c
   dim _P1_U_D = player1y.d

And here are a few examples of how you could move player0 to the left:

   _P0_L_R = _P0_L_R - 0.85

   _P0_L_R = _P0_L_R - 2.0

   _P0_L_R = _P0_L_R - 1.052

[LatchKeyKid]

Thanks but, no, he was literally renaming the "x" alphabet variable to be player0x and the "y" to be player0y.   I suspect he thought he had to in order to get them to work?  I don't want to provide a link as to potentially embarass him but figured I'd ask.   I was able to get things working to get a sprite on screen with the advice above but I decided to push my luck and go for two multicolor sprites with different widths and now I'm getting a kernel option error.  Am I messing up the spacing?  I've tried cutting and pasting it direct from working programs with no luck.    When I remove the "playercolors" kernel option and manually set a single color with COLUP0, it compiles and works just fine.   I appreciate all the help as I understand it's tedious to hand hold me through this.

 

set kernel_options player1colors playercolors

 

   COLUBK = $00

   player1x = 50

   player1y = 50

   player0x = 80

   player0y = 50

 

 

main

  player1:

        %10000011

        %11000010

end

 

  player1color:

        $C0;

        $F0;

end

 

  NUSIZ0 = $05

  player0:

        %10000011

        %11000011

end

 

  player0color:

        $F0;

        $C0;

end

 

  drawscreen

 

 

  goto main

Edited May 16 by LatchKeyKid

[+Random Terrain]

5 minutes ago, LatchKeyKid said:

Thanks but, no, he was literally renaming the "x" alphabet variable to be player0x and the "y" to be player0y.   I suspect he thought he had to in order to get them to work?

 

Yeah, that's just a waste of a variable.

 

6 minutes ago, LatchKeyKid said:

When I remove the "playercolors" kernel option and manually set a single color with COLUP0, it compiles and works.

 

You can ONLY use these combinations:

 

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

 

You can't use combinations that aren't in the chart.

[LatchKeyKid]

9 minutes ago, Random Terrain said:

 

You can ONLY use these combinations:

 

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

 

You can't use combinations that aren't in the chart.

 

I didn't notice that just the two multicolor sprites together weren't a valid option and that you have to add a third kernel option (regardless of whether you want to use it or not) to get those first two to work.   Thanks!

[LatchKeyKid]

Well, I've got controllable pixels/sprite on the screen along with a working playfield... until I try to use pfcolors with it.  I've assigned pfheights successfully and everything works fine until I try to also use pfcolors.  I've tried picking my own colors, cutting and pasting from Random's PF maker, and using other playfield makers and I always seem to get an unstable frame rate and flicker (sometimes 30fps, 45, 60, etc).   It all goes back to normal once I take out the pfcolors kernel option and go back to a single color chosen by COLUPF.   I've double checked and I have 11 rows set with custom heights that add up to 88 exactly along with 11 colors (one for each row) so their isn't a numerical mismatch.  I'm defining pfheights first and putting the pfcolors in the main loop as I saw you read you can have some color issues (usually bleed though) and I'm not attempting to change them later as PFCOLORS and PFHEIGHTS are fixed when used in combo together.   And I'm indenting them all.   I'm not sure what is causing this instability only when I activate pfcolors and goes away when I remove it as an option.   Some of the code from Random's playfield editor gives 12 values for pfcolors and all the NTSC/PAL constants but that doesn't help either.  Is the issue that I have some wild swings in my heights on pfheights as they go from 2 to 22?  I've tried reducing the difference but no real luck (though admittedly only to 3-19).  

 

Is there something else I'm missing?     I see a mention of a flickering mess at the end of this thread mentioned by Cybearg but I'm not using any SC code that I know of.  Am I getting the RAM issue that requires SC code to hotfix?   I've genuinely tried to figure it out myself tonight but I'm stumped...  Other than setting the background to black and putting pfcolors and pfheights in the set kernel line, I'm not doing anything else with that aspect.  Is there an illegal color code in there?  I've tried several different sources with even different colors and that doesn't seem to matter.

 

 

 

   pfheights:

   20

   12

   2

   2

   22

   2

   2

   2

   2

   2

   20

end

 

   playfield:

   ................................

   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

   ................................

   .XXXXX.XXXXX.XXXXXX.XXXXX.XXXXX.

   ................................

   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

   ................................

end

 

main

 

     pfcolors:

        $02

        $8A

        $02

        $8A

        $0A

        $C2

        $C2

        $C2

        $C2

        $C2

        $02

end

 

Edited May 17 by LatchKeyKid

[alfredtdk]

6 hours ago, Random Terrain said:

 

Yeah, that's just a waste of a variable.

 

 

You can ONLY use these combinations:

 

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

 

You can't use combinations that aren't in the chart.

And truth.

 

6 hours ago, LatchKeyKid said:

 

I didn't notice that just the two multicolor sprites together weren't a valid option and that you have to add a third kernel option (regardless of whether you want to use it or not) to get those first two to work.   Thanks!

Don't dare make random combinations of kernel options, it will probably not compile your code. I speak from experience in trying to do this.

I'm also making several mistakes when compiling my projects, there are many things that I still don't understand. I'm a newbie at this.
But it's from our mistakes that we learn and I hope that over time we can be good game developers.

[+Karl G]

29 minutes ago, LatchKeyKid said:

   pfheights:

   20

   12

   2

   2

   22

   2

   2

   2

   2

   2

   20

end

There's a quirk with pfheights that requires the first height value to be 8. That is probably the most likely cause of your issue. 

[LatchKeyKid]

8 minutes ago, alfredtdk said:

Don't dare make random combinations of kernel options, it will probably not compile your code. I speak from experience in trying to do this.

I'm also making several mistakes when compiling my projects, there are many things that I still don't understand. I'm a newbie at this.
But it's from our mistakes that we learn and I hope that over time we can be good game developers.

 

In my defense, it is listed as a legal combo on Random's site albeit with a big asterisk/potential warning... so I suppose that makes it a Random combination. 

[LatchKeyKid]

7 minutes ago, Karl G said:

There's a quirk with pfheights that requires the first height value to be 8. That is probably the most likely cause of your issue. 

 

Thanks!  Just plugged it in and it worked!

[alfredtdk]

1 hour ago, LatchKeyKid said:

 

Thanks!  Just plugged it in and it worked!

I went through something similar using pfheights on Stay Puft and ECTO-1 and it was  Karl G  opened my eyes and helped me solve this problem.

[LatchKeyKid]

Thanks for all the help, folks!   Just to post to prove that it wasn't all wasted, here's my first 24 hours work as a proof of concept for an untitled samurai game I hope to make. 

 

Edited May 17 by LatchKeyKid

[LatchKeyKid]

Is it necessary to zero out variables (whether full byte or divided up into bits) that you're using right at the beginning of the program or is it done by the compiler behind the scenes anyways so it would be redundant?   It's not an issue in multibank projects but I didn't know if it was necessary to use the ROM space for it.

[+Gemintronic]

16 minutes ago, LatchKeyKid said:

Is it necessary to zero out variables (whether full byte or divided up into bits) that you're using right at the beginning of the program or is it done by the compiler behind the scenes anyways so it would be redundant?   It's not an issue in multibank projects but I didn't know if it was necessary to use the ROM space for it.

 

I've heard it's good practice to zero out RAM at the very start of your game.  On a real 2600 the RAM may start in an unexpected state.  Also, I heard rumors that clearing RAM helps the flashback portable play bB homebrew.  But, I haven't seen it be helpful so far.

 

UPDATE:  I should add that I've messed myself up in the past not clearing variables after soft resetting or starting a new game.  Sometimes variables don't get reset to their initial state and you get previous (stale) information.

[LatchKeyKid]

1 hour ago, Gemintronic said:

 

I've heard it's good practice to zero out RAM at the very start of your game.  On a real 2600 the RAM may start in an unexpected state.  Also, I heard rumors that clearing RAM helps the flashback portable play bB homebrew.  But, I haven't seen it be helpful so far.

 

UPDATE:  I should add that I've messed myself up in the past not clearing variables after soft resetting or starting a new game.  Sometimes variables don't get reset to their initial state and you get previous (stale) information.

 

Thanks and I'll do that then.  I just didn't know if the backend of the batari compiler automatically did all that when compiling. 

Edited May 21 by LatchKeyKid