N00b questions about bB

[+Karl G]

3 hours 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.

For the first iteration, or after a "reboot" command, the code does indeed zero out RAM. Usually you'll need to clear it out if you allow your game to restart anyway, though, but otherwise there's no need to do so on startup.

[LatchKeyKid]

So I was getting some jittering with the scanlines alternating between 261 and 262 and when looking that up I saw that might be due to going over on my cycles likely during the kernel (I assume that's what you're programming before the drawscreen command?).  I've been moving stuff out of the pre-drawscreen area (but still in the main loop) as well as not automatically check everything but instead skip around with goto/gosub so as not to autocheck every potential option (like whether a player is moving or jumping or standing still).   I found the "set debug cycles" command that is supposed to flash the background if you're over so I decided to include it and everything seemed ok with the first compile.   Only when I compile it a second time in a row with it enabled, it turns the background a strange color but it is NOT flashing.   I genuinely not sure if this is a positive or if the strange color is "normal" as long as it's not flashing.  Just for reference, the background is supposed to be black.

 

Edited May 22 by LatchKeyKid

[RevEng]

Short answer: You're running into a cycle rounding issue. Ignore it for now, and as you add more code to your project it will probably go away. If you're done your project, you can artificially add code to try to make it go away. I haven't seen it not go away on it's own, but in theory you might need to add code to one particular code path.

 

Long answer: For bB and most assembly games, the RIOT 64 cycle timer is used to check when parts of the screen have finished being drawn. But that 64 cycle timer is measuring groups of scanlines that are 76 cycles long, so unless the size of screen you're measuring is a multiple of 16 scanlines, there will be a remainder. The problem with having a remainder is the scanline count can be thrown off by one, depending on exactly what cycle the timer check executed on.

 

The actual situation is even a bit more complicated than what I've described above, due to the fact that bB and most assembly games are measuring out multiple sections of the screen with that same timer, and there's also a bit of constant overhead in setting up the timer loops.

[LatchKeyKid]

13 hours ago, RevEng said:

Short answer: You're running into a cycle rounding issue. Ignore it for now, and as you add more code to your project it will probably go away. If you're done your project, you can artificially add code to try to make it go away. I haven't seen it not go away on it's own, but in theory you might need to add code to one particular code path.

 

Long answer: For bB and most assembly games, the RIOT 64 cycle timer is used to check when parts of the screen have finished being drawn. But that 64 cycle timer is measuring groups of scanlines that are 76 cycles long, so unless the size of screen you're measuring is a multiple of 16 scanlines, there will be a remainder. The problem with having a remainder is the scanline count can be thrown off by one, depending on exactly what cycle the timer check executed on.

 

The actual situation is even a bit more complicated than what I've described above, due to the fact that bB and most assembly games are measuring out multiple sections of the screen with that same timer, and there's also a bit of constant overhead in setting up the timer loops.

 

Thanks and that did the trick when I just added back the "missing" playfield lines.   After staring at the screen like that for a few hours on and off, it was giving me a headache!

[LatchKeyKid]

Thanks again for all the help so far.   I was curious if there is a (semi)automated way to share sprites in the bB standard kernel.   I've seen info on how to do it for the DPC+ kernel on RT's site but I couldn't find a mention of it for the standard kernel.  I did find this old thread here on AA though mainly on how to do it with ASM but obviously many updates likely added many new features in the 15+ years since so I figured I'd ask.

 

 

It's not a huge deal as I'll have a single repeat but I thought it would be a good idea to ask just to learn.   Would making a specific subroutine that you call when you need the sprite be a good option or is that even more wasteful in CPU cycles and ROM space than simply rewriting the sprite twice or even three times?

 

[RevEng]

The info in that post still holds. While bB has had updates since then, of course, but the way the standard kernel and players work remains the same.

 

The answer to using a sub vs just repeating the player definitions depends on how much player data we're talking about. If you want to make things optimal, you'd have to run the test and see with your data. I'd recommend not worrying about it too much. If you need to free up rom at some later stage, this probably won't be part of the 20% of squeezing you can do to get 80% of the rom relief.

[LatchKeyKid]

Thanks.  I just decided to repeat it to avoid problems but I ran into a different one potentially and I don't know if it's a problem with me/my code or a known glitch.   In adding the attack animation, I can't get it to load if the character is moving left and jumping diagonally (joy0left and joy0up).   I can't even get Stella to enter debugger mode with the ` tilda key when I'm pressing up/left/spacebar unlike when I press up/right/spacebar to check to see if it's even registering the joy0fire button so I don' know if that's a Stella glitch since it won't register the ` tilda only in that direction.

 

I always assume I screwed up so I looked at literally every instance in the code of my custom sprite reflection bit variable, REFP1, joy0fire, and even every possible change of the player1 sprite I use for the controllable player character and I can't find any reason why it would NOT work only when pressing that key combo (left, up, fire) whereas it would work in every other combo.  The inability of Stella to enter debugger mode only in that key combo as well makes me wonder if it's a glitch there instead.  I'm using the most up to date 6.7.1 btw.   The below is a screen cap of when it works with up/right/fire whereas literally holding down the same keys except to the left doesn't let me get to this screen.  

 

edit:  While it won't let me get into the dev while pressing up/left/spacebar, it worked after I let go of the space bar and I rewound the frames until when I was pressing the fire button and it doesn't seem to be registering it in the emulator at all as shown in the second pic (with the character on the far left side of the screen.

 

 

Edited May 24 by LatchKeyKid

[LatchKeyKid]

It looks like I can stop rewriting my code for the 10th time as left/up/fire doesn't seem to work even with this simple program.

 

edit;  It looks like it's a keyboard thing as it works with a windows joystick.   I talked to one of the Stella devs here and he thinks it might be "key rollover" which I didn't know was a thing.  Well, at least I know the code worked even without all the rewrites, lol.

 

testleftupfire.bas.bin testleftupfire.bas

Edited May 24 by LatchKeyKid

[+splendidnut]

That example BAS only checks the fire button.

[LatchKeyKid]

4 hours ago, splendidnut said:

That example BAS only checks the fire button.

 

Indeed but stella but the point for me was to check and see if it's reading the fire input at all with that combo.   Does the sprite change to yellow when you hold up/left/fire at the same time?   It doesn't for me though it does when I hold up/right/fire at the same time like in the pic below where it read all three and turned the sprite yellow (which doesn't happen to the left for me).   It was just a simple program to see if there was a directional difference (and on my computer there is).    Regardless, it works with an actual controller so the issue is with the keyboard input (whether on my OS, keyboard, etc).

 

[+Random Terrain]

This is from the bB page:

 

When using an emulator on a computer, be sure to use the left Ctrl key instead of the space bar as the fire button since the space bar can stop you from moving diagonally with the arrow keys. Most computer keyboards can't handle certain simultaneous key presses.

[+splendidnut]

10 hours ago, LatchKeyKid said:

Does the sprite change to yellow when you hold up/left/fire at the same time?

Yes.  But I do have a gaming keyboard which is meant to handle the key-rollover issue better than other keyboards.

[alfredtdk]

----------------------------- 

Edited August 21 by alfredtdk

[LatchKeyKid]

16 hours ago, Random Terrain said:

This is from the bB page:

 

When using an emulator on a computer, be sure to use the left Ctrl key instead of the space bar as the fire button since the space bar can stop you from moving diagonally with the arrow keys. Most computer keyboards can't handle certain simultaneous key presses.

 

You've got so much info on your site a n00b like me struggles to find it sometimes!  That definitely fixes the issue without having to carry around an xbox controller to Starbucks to test stuff out, lol.

 

8 hours ago, splendidnut said:

Yes.  But I do have a gaming keyboard which is meant to handle the key-rollover issue better than other keyboards.

 

In my case, I'm rocking the standard issue potato laptop keyboard and this was the first time I had ever encountered the issue (and wasn't even aware of it even being a thing until now). 

 

Thanks to you both (and Thomas) for putting up with a nervous n00b.

[LatchKeyKid]

Is there a n00b friendly way to tweak the pfscore section?  The score area looks to lean about six pixels to the right side of the screen and I'm hoping to use it for alot of in game stuff and I'd prefer if it was centered.   I was hoping that a tweak of the kernel file would fix that but I'm obviously not really knowledgeable about how to start beyond just CTRL-F looking for pfscore.   I'm not confident enough in ASM to understand all the numbers next to GRP values and such to start messing with them willy nilly.    I've attached the multisprite kernel file as I didn't see one on the Atari Dev Studio plugin for Visual Studio github that was specific for the pfscore other than fonts.

 

 

multisprite_kernel.asm

[+splendidnut]

I can tweak that for you.  Though, it would help if I had a copy of your .bas source code to be able to check it while tweaking.  Feel free to send via PM if you don't want it public.

[+Karl G]

Re: centering the score - the reason it's not centered is because of the timing of the kernel to fit in two pfscore bars and a 6-digit score requires specific positioning of the objects. So there's not really a way to center the score and have the pfscore bars. If you only need five digits, then if you don't display the rightmost digit then it's pretty close to centered, if I remember correctly. 

[LatchKeyKid]

36 minutes ago, Karl G said:

Re: centering the score - the reason it's not centered is because of the timing of the kernel to fit in two pfscore bars and a 6-digit score requires specific positioning of the objects. So there's not really a way to center the score and have the pfscore bars. If you only need five digits, then if you don't display the rightmost digit then it's pretty close to centered, if I remember correctly. 

 

Thanks and I appreciate the response.  Yeah, I left off the last digit on my RONIN game to increase the spacing on that side for that very reason but I started up a side project today where that won't really be a good workaround so figured I'd ask.

[LatchKeyKid]

Is there a line counter in the bB kernels (specifically the multisprite kernel)?   I've seen the posts here and elsewhere mentioning that the timings are very tight on the kernels and I was curious if there was a line counter to allow for a change in the background color at a certain point in the display kernel.

 

On an unrelated note, is there a guide as to what I should and what I don't have to include in the main program in bB?   I've seen several individual mentions and warnings on RT's website and followed them but I was curious if there was a general guide to the topic.  I'm honestly not sure if the main program loop is a general approximation for the display area part of the program or if that reasoning is incorrect.   I've generally just tried putting display related programming into the main program and other calculations outside of it.   My n00bish attempts haven't yet pushed the bounds/limits of bB (other than the self imposed 4k size so far that I'm limiting myself to) but I figured I'd ask before I dip my toes into multibank programming potentially in the next couple of weeks/months.

[+Karl G]

As for the first question, there is not any kind of general line counter in the bB kernels. 

 

As to the second question, I'm not sure if I am understanding what you are asking correctly, but bB code that you write runs in the "overscan" portion of the frame, after the visible screen is drawn. The vblank and visible screen portions are out of your hands, and not controlled by you directly in a bB program. bB uses the vblank time slice to position sprites, etc before the visible screen. 

 

The exception is when you add a "vblank" section to your code as described in the manual. In this case, you can get some of your code to run in the cycles that are still free in this time slice if you need to. 

[LatchKeyKid]

4 hours ago, Karl G said:

As for the first question, there is not any kind of general line counter in the bB kernels. 

 

As to the second question, I'm not sure if I am understanding what you are asking correctly, but bB code that you write runs in the "overscan" portion of the frame, after the visible screen is drawn. The vblank and visible screen portions are out of your hands, and not controlled by you directly in a bB program. bB uses the vblank time slice to position sprites, etc before the visible screen. 

 

The exception is when you add a "vblank" section to your code as described in the manual. In this case, you can get some of your code to run in the cycles that are still free in this time slice if you need to. 

 

Thanks.   I was hoping there would be an easy way to change the background color once in the multisprite kernel by using a potential line counter it may already have.

 

I'm sorry about the wording of the second question as my unfamiliarity definitely led to some poor wording.  I was referring to what you need to put before the drawscreen command and what can go after.   I don't know if I'm overthinking it but I assumed that what came before it would be done during the display portion of the kernel but writing it out like that makes me realize that is incredibly unlikely.

[LatchKeyKid]

After a couple months off, I've decided to start up work again on my RONIN homebrew game.   While I did learn how to successfully advance/change screens with my Centurion homebrew, I keep wondering whether or not a single screen advancement style game ala Pitfall (where you go to the far left/right of the screen and it changes over automatically) is better or whether continuous side scrolling would be a better choice (similar to Super Mario Bros or Kung Fu).    I'd probably stick with the Pitfall style screen change if PF0 was available for use with the standard kernel but unfortunately that's not the case other than for a simple border from what I've read.  Honestly, I don't really have a clue how involved that would be so I downloaded the sample program from RT's pfscroll entry

 

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

 

as well as the .bas for the excellent Princess Rescue homebrew inspired by SMB.    For those with more experience, how do you store the various playfields to make this technique work?   It is usually some sort of huge table with a pointer or do you individually store each screen instead?   Or something totally different since I'm admittedly clueless?  I think I want to work on the level advancement and/or scrolling first before adding in the enemies.  I know that PFSCROLL uses up a fair amount of cycles for side scrolling on the L/R x-axis so I was thinking about putting it into vblank if possible (though I don't know how viable it is or if there is a hidden complication I'm not aware of).   I understand the playfield pixels are 4x the width of the sprite pixels but the sample program and various endless runner homebrew games I've played make it seem smooth enough for me personally.    Thanks in advance as always for advice on how to potentially incorporate this and/or whether I even should.