Jump to content
IGNORED

N00b questions about bB


LatchKeyKid

Recommended Posts

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.  

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

  • Like 2
Link to comment
Share on other sites

11 minutes ago, Random Terrain said:

 

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.  :)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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
Link to comment
Share on other sites

Posted (edited)

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 mainimage.thumb.png.a89e1f06ddb5ab960b6b01b574691177.png
Edited by LatchKeyKid
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!

  • Like 1
Link to comment
Share on other sites

Posted (edited)

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 by LatchKeyKid
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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. 

  • Like 3
Link to comment
Share on other sites

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.  :)

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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 by LatchKeyKid
  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...