N00b questions about bB

[LatchKeyKid]

17 minutes ago, KaeruYojimbo said:

I use pfpixel in Sky Destroyer/WATA Invaders.

Thanks again and they'll be next up on my list to check out.  In your games' case, does the AI enemy use pfpixel/create playfield blocks or does the player?

[LatchKeyKid]

What method do you folks use to create bB programs out of curiosity?  What are the benefits of the one you use?  I downloaded Visual Studio with the Atari Dev Studio extension when I did my hack to edit and recompile the disassembled hack and it looks like I can use that (is it a separate extension?) but I see that there are other options as well apparently.  I have to admit that I'm a bit intimidated by the Visual Studio program and I only learned the bare minimum to compile my hack at the time (and have already forgotten half of it in the year+ since).   I planning that one of my New Year's resolutions will be to finally take the plunge and try to program a game in bB from scratch.

Edited November 25, 2023 by LatchKeyKid

[+Random Terrain]

1 minute ago, LatchKeyKid said:

What method do you folks use to create bB programs out of curiosity?  I downloaded Visual Studio when I did my hack to edit and recompile the disassembled hack and it looks like I can use that but I see that there are other options as well apparently.  I think one of my New Year's resolutions will be to finally take the plunge and try to program a game in bB from scratch.

 

I use VbB (Build 568) because it has a bunch of tools I need.

 

https://www.randomterrain.com/atari-2600-memories-batari-basic-vbb.html#install_vbb

 

I couldn't get anything done without it.

[LatchKeyKid]

1 hour ago, Random Terrain said:

 

I use VbB (Build 568) because it has a bunch of tools I need.

 

https://www.randomterrain.com/atari-2600-memories-batari-basic-vbb.html#install_vbb

 

I couldn't get anything done without it.

Thanks!   So that is different from Visual Studio then?   I naively assumed they were related due to the common "visual" nomenclature.   Is there a guide to the general 10,000ft view of how a game comes together in vbb on your site?   Your site has been a big help in getting my game ideas together and seeing what's possible.  I'm probably a good portion of the hits to your kernel options page over the past year. 

Edited November 25, 2023 by LatchKeyKid
Some of the questions answered in the link posted!

[+KaeruYojimbo]

On 11/23/2023 at 7:38 PM, LatchKeyKid said:

In your games' case, does the AI enemy use pfpixel/create playfield blocks or does the player?

In those games the enemy character adds the playfield blocks. One OG example I can think of of a game where the player adds to the playfield is Master Builder.

 

2 hours ago, LatchKeyKid said:

What method do you folks use to create bB programs out of curiosity?

I use Visual Studio. I've never used vbb so I can't speak to any advantages or disadvantages other than Atari Dev Kit is still being actively supported and updated regularly whereas vbb hasn't been updated in years.

 

2 hours ago, LatchKeyKid said:

one of my New Year's resolutions will be to finally take the plunge and try to program a game in bB from scratch.

Do it! There's a great community of people here who will help you if you get stuck. Just don't fall into the "I've never programmed so much as a VCR before but my first project will be to port [insert name of latest triple-A release here] to the 2600" trap. Being ambitious is good, but biting off more than you can chew too early is a good way to get discouraged.

[LatchKeyKid]

19 minutes ago, KaeruYojimbo said:

Do it! There's a great community of people here who will help you if you get stuck. Just don't fall into the "I've never programmed so much as a VCR before but my first project will be to port [insert name of latest triple-A release here] to the 2600" trap. Being ambitious is good, but biting off more than you can chew too early is a good way to get discouraged.

Thanks.  I will take a look at Master Builder then to see how it worked.  As for programming, it's been a few years but I have successfully programmed a VCR even back in the days of the front panel hidden dip switch array!     Of course, I and my brain were much younger back then though.  I've been trying to keep my expectations realistic with some preplanning (like studying the basic kernel table) and copious amounts of questions (sometimes stupid and/or obvious ones!) as well as looking at what I consider to be great examples of the types of games I'd like to make.  I've been peppering the forum here and various facebook groups with general questions about preferences regarding things like how to handle multiaction/multibutton support for example (since I want to have both jump and action mechanics) in order to gauge what I should or shouldn't do in theory..   I typically start with a general idea of the game and then work on the main character and enemy sprites since neither of those require coding experience.   Just recently I took my sprites and hacked them into an existing homebrew game (withing certain limits as the animations aren't exactly the same) to see how they generally look actually onscreen and made adjustments as a result as I was surprised that the animated gifs I've been relying on weren't 100% accurate to the onscreen feel.  It's definitely imposing to take that first real step and download or use the actual coding program though and that's where I'm at right now.  

 

I don't know if this is good or bad but I don't want to start out on the wrong foot with bad coding habits so I've got a bunch of questions rattling around in my head that are frankly above my paygrade currently since I haven't yet put a single pixel onto the screen on my own.   For example, do you use one single animation timer/variable to control all the animations of all the sprites?  Is it important to do the animations on different frames so as not to overload the CPU cycles all at once?   If the animation timer/variable only needs to go up to a certain number, can you repurpose the unused bits for something else instead?  I don't really have the necessary framework to know whether I'll run out of variables/RAM (or CPU cycles) and need to do manage this from the beginning instead of having to go back and rewrite everything once I run out half way through.  I fully admit that I'm putting the cart before the horse though right now in the planning stage so hopefully that won't discourage me in the long run.

Edited November 25, 2023 by LatchKeyKid

[+Random Terrain]

4 minutes ago, LatchKeyKid said:

Thanks!   So that is different from Visual Studio then?   I naively assumed they were related due to the common "visual" nomenclature.

 

Seems like everything by Microsoft has "Visual" in the name. VbB was made using Visual Basic or whatever it's called or was called. Atari Dev Studio and VbB were made by two different people. Atari Dev Studio is still being worked on. The creator of VbB got too busy or burned out or something and quit working on it. I had to upload the latest version I had since he never posted the latest.

 

If you want to try VbB, be sure to read this section:

 

How to 'Install' Visual batari Basic on a Windows PC

 

 

 

5 minutes ago, LatchKeyKid said:

Is there a guide to the general 10,000ft view of how a game comes together in vbb on your site?

 

There is a Tinkernut video showing a person making an example "game" with VbB that has several mistakes, so watch it with that in mind:

 

How To Make Atari Games

 

And it's not VbB specific, but there is a Parts of a Program section on the bB page:

 

Parts of a Program

 

 

 

3 hours ago, LatchKeyKid said:

I've seen references to different project folders, the "main loop", and other things but I don't know how much of that general frame work is automatic versus has to be set up by the end user.

 

This section of the VbB page talks about project folders:

 

How to 'Install' Visual batari Basic on a Windows PC

 

 

The main loop is talked about on the bB page:

 

Parts of a Program

 

 

 

3 hours ago, LatchKeyKid said:

For example, someone mentioned that all the sprites and playfields have to go in the final bank in a multibank game (is that for all kernels or just the DPC+ where it is mentioned?) but I wasn't sure if you have to set those up manually.

 

This is from the bB page:

 

You do not need to specify where sprite graphics go, as they all will be automatically placed in the last bank no matter where you define them (you can just leave all of your animation frames in the same bank that contains your main loop).

 

For the standard kernel, playfield graphics data gets stored in whatever bank you place it in. For the multisprite kernel, playfield graphics data automatically gets stored in the last bank. For the DPC+ kernel, playfield graphics data automatically gets stored in the "graphics" bank.

 

 

 

3 hours ago, LatchKeyKid said:

Your site has been a big help in getting my game ideas together and seeing what's possible.  I'm probably a good portion of the hits to your kernel options page over the past year. 

 

That's good. In case you didn't know, most of the example programs are listed here:

 

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

[+KaeruYojimbo]

1 hour ago, LatchKeyKid said:

I don't want to start out on the wrong foot with bad coding habits

All of my coding habits are bad. 🙂

 

The answer to a lot of your questions is "it depends." For example, you don't necessarily need to worry about making sure your animations take place on different frames, but it depends on how many animations we're talking about and whether or not you're doing a lot of other cycle-heavy stuff. Since you can't really count cycles easily in bB, you'll just have to try it one way and see if it works.

 

I learned a lot through trial and error. I just started making a game and added things as I figured them out. If you wait until you have all the answers to start, you'll never get started.

[RevEng]

On 11/25/2023 at 11:13 AM, LatchKeyKid said:

I don't know if this is good or bad but I don't want to start out on the wrong foot with bad coding habits so I've got a bunch of questions rattling around in my head that are frankly above my paygrade currently since I haven't yet put a single pixel onto the screen on my own.   For example, do you use one single animation timer/variable to control all the animations of all the sprites?  Is it important to do the animations on different frames so as not to overload the CPU cycles all at once?   If the animation timer/variable only needs to go up to a certain number, can you repurpose the unused bits for something else instead?  I don't really have the necessary framework to know whether I'll run out of variables/RAM (or CPU cycles) and need to do manage this from the beginning instead of having to go back and rewrite everything once I run out half way through.  I fully admit that I'm putting the cart before the horse though right now in the planning stage so hopefully that won't discourage me in the long run.

Not originally addressed to me, but I have 2 cents. Programming on old consoles, and the 2600 in specific, is a sort of extreme situation where you can't apply very many general rules. Your specific game design may be ram hungry, and thus call for trading off rom and cpu for ram. Someone else's design may be rom or cpu hungry. You likely won't understand which constraints you'll be bumping up against until you eventually become an expert in implementing your specific kind of game on the 2600. Rewrites are a normal and natural part of the process, and shouldn't be thought of as wasted time.

 

While I said "there aren't very many general rules", I do strongly believe Knuth's thoughts on premature optimization apply to the 2600. As meagre as the 2600 resources are, they're actually pretty well balanced - don't assume you'll be short on one resource vs another until you have evidence for it. Write code and figure it out. Nobody ever finished coding a 2600 game that was exactly implemented as it was planned up front.

 

In terms of your specific questions about sprite animation... Animation doesn't use much cpu time. With bB animation amounts to changing a single pointer value. My own preference for animation is to use a single frame counter variable and animate all of the sprites using a mask, but that approach requires your animation frame counts to be based on powers-of-two (i.e. 2, 4, 8, 16) which i don't personally find constraining. Others really want more flexible animation counts, or don't understand bitwise operations, and wind up using separate variables. Sometimes you just want the animation to change with screen position, in which case you can use the position variables to drive that. None of this is make or break, nor is it a big cost to change your mind later and take a different approach.

[TwentySixHundred]

The amount of times i have rewritten projects (either large portions or from scratch) i have lost count. Rather than lost time i put it down to getting more talented and efficient. Especially when taking an hiatus from a project but still writing small test programs to understand features and methods better. I find sometimes it's easier to just start from scratch. Many times it's faster to rewrite the parts you already know but in a more efficient elegant way, over trying to fix previous code IMO

[LatchKeyKid]

5 hours ago, RevEng said:

Not originally addressed to me, but I have 2 cents. Programming on old consoles, and the 2600 in specific, is a sort of extreme situation where you can't apply very many general rules. Your specific game design may be ram hungry, and thus call for trading off rom and cpu for ram. Someone else's design may be rom or cpu hungry. You likely won't understand which constraints you'll be bumping up against until you eventually become an expert in implementing your specific kind of game on the 2600. Rewrites are a normal and natural part of the process, and shouldn't be thought of as wasted time.

 

While I said "there aren't very many general rules", I do strongly believe Knuth's thoughts on premature optimization apply to the 2600. As meagre as the 2600 resources are, they're actually pretty well balanced - don't assume you'll be short on one resource vs another until you have evidence for it. Write code and figure it out. Nobody ever finished coding a 2600 game that was exactly implemented as it was planned up front.

 

In terms of your specific questions about sprite animation... Animation doesn't use much cpu time. With bB animation amounts to changing a single pointer value. My own preference for animation is to use a single frame counter variable and animate all of the sprites using a mask, but that approach requires your animation frame counts to be based on powers-of-two (i.e. 2, 4, 8, 16) which i don't personally find constraining. Others really want more flexible animation counts, or don't understand bitwise operations, and wind up using separate variables. Sometimes you just want the animation to change with screen position, in which case you can use the position variables to drive that. None of this is make or break, nor is it a big cost to change your mind later and take a different approach.

Thanks and I appreciate the detailed response.  I consider posts/questions in the thread to be open to all especially as I'm specifically soliciting advice and am grateful for those who take the time to respond.  I definitely think Knuth's rule applies to me and is doubly dangerous since my knowledge base is very small.  I know I have to focus first just on getting pixels on the screen (single screen playfield and sprites) and that's my goal for the end of January.   I'm not sure if bB supports using masks and, if it does, how to do it but (again) I need to learn to walk before I try to run.  My ultimate goal would be a multiscreen basic kernel platformers in the vein of VHZC's games (like Ninjish and Knight guys) but obviously with expectations and results tailored to my level of (zero) experience of course.  Regardless, I have no idea which resource I'd be running out of first though (RAM? ROM? Patience?). 

[LatchKeyKid]

On 11/25/2023 at 12:41 PM, KaeruYojimbo said:

I learned a lot through trial and error. I just started making a game and added things as I figured them out. If you wait until you have all the answers to start, you'll never get started.

Thanks and I definitely feel like my own coding insecurities have contributed to my own procrastination in starting any of the project ideas I've come up with over the past year.  That's a large part of why I decided I'm going to take the plunge in the New Year and just start regardless.

[+Random Terrain]

17 minutes ago, LatchKeyKid said:

. . . have contributed to my own procrastination . . .

 

I have a page for that too:

 

https://www.randomterrain.com/rt-motivation-and-creativity-page-for-programmers.html

[LatchKeyKid]

On 11/25/2023 at 12:14 PM, Random Terrain said:

 

Seems like everything by Microsoft has "Visual" in the name. VbB was made using Visual Basic or whatever it's called or was called. Atari Dev Studio and VbB were made by two different people. Atari Dev Studio is still being worked on. The creator of VbB got too busy or burned out or something and quit working on it. I had to upload the latest version I had since he never posted the latest.

 

If you want to try VbB, be sure to read this section:

 

How to 'Install' Visual batari Basic on a Windows PC

 

 

 

 

There is a Tinkernut video showing a person making an example "game" with VbB that has several mistakes, so watch it with that in mind:

 

How To Make Atari Games

 

And it's not VbB specific, but there is a Parts of a Program section on the bB page:

 

Parts of a Program

 

 

 

 

This section of the VbB page talks about project folders:

 

How to 'Install' Visual batari Basic on a Windows PC

 

 

The main loop is talked about on the bB page:

 

Parts of a Program

 

 

 

 

This is from the bB page:

 

You do not need to specify where sprite graphics go, as they all will be automatically placed in the last bank no matter where you define them (you can just leave all of your animation frames in the same bank that contains your main loop).

 

For the standard kernel, playfield graphics data gets stored in whatever bank you place it in. For the multisprite kernel, playfield graphics data automatically gets stored in the last bank. For the DPC+ kernel, playfield graphics data automatically gets stored in the "graphics" bank.

 

 

 

 

That's good. In case you didn't know, most of the example programs are listed here:

 

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

I appreciate the links!  I've been through various parts of your site but definitely not all so they definitely help.  I erased some of the questions in my original post as I saw your first link partly explained them once I read through it but these definitely clarify more.  It took me a bit of time to go through them so apologies for the delay.  I've seen plenty of sample programs you link in each individual part but there are definitely more than I haven't seen in these links.  One actually addresses a question that I ironically asked elsewhere on the internet just the day before!  Thanks for confirming where the playfield and sprites go in multibank programs and I'll keep that in mind.  I've been (prematurely!) worrying whether I'll have enough room for both depending on where they go but knowing that they can theoretically go in separate banks does alleviate alot of that fear for the future.  Obviously my first attempts will just be a single 4k ROM and getting basic things to work like sprites, playfields, and basic animation before I move onto other things.

[LatchKeyKid]

Is there anything stopping a programmer from making their own flicker management system to have multiple additonal sprites in the basic kernel?   I'd assume that the rate limiting factor would be the RAM required to double all the sprite registers like position and movement but I'm just guessing.   Nothing too advanced since I'm just a n00b but maybe just having two enemy sprites along with the player...

[+splendidnut]

Very basic flicker management can be accomplished by merely switching/rotating what things are displayed.  The amount of RAM needed is determined by how many sprites you want visible at a time multiplied by how many bytes of information (position / type) you need for each one.

[LatchKeyKid]

2 hours ago, splendidnut said:

Very basic flicker management can be accomplished by merely switching/rotating what things are displayed.  The amount of RAM needed is determined by how many sprites you want visible at a time multiplied by how many bytes of information (position / type) you need for each one.

Thanks.  Very basic would probably be a good aspirational goal for me at this point.   I just assumed that you could (even with the basic kernel) alternate which of two virtual sprites you're displaying on alternate frames as long as you have the extra variables to store the duplicate data.  I don't recall seeing that in basic kernel games hence the question and I assumed that really limited RAM was the limiting factor as to why.

[+splendidnut]

The standard kernel has a RAM-based playfield, which uses a big chunk of RAM.  That's really why there's so few variables available to the user when using the standard kernel.

 

I'm a bit surprised that there was never an option added to the standard kernel to also support ROM-based playfields.  While it would kill all the different playfield drawing functions, it would free up a lot of RAM.

[LatchKeyKid]

1 hour ago, splendidnut said:

The standard kernel has a RAM-based playfield, which uses a big chunk of RAM.  That's really why there's so few variables available to the user when using the standard kernel.

 

I'm a bit surprised that there was never an option added to the standard kernel to also support ROM-based playfields.  While it would kill all the different playfield drawing functions, it would free up a lot of RAM.

Thanks.  When I read that the playfield was stored in RAM, I thought that it was a great idea as it allows the mutability of the playfield but it was a surprised at how much of the very limited RAM it took up to do that.  My first thought was wondering if there was an option to only use RAM for the second half of the playfield if it is asymetrical and have the left half be stored/drawn normally.  Obviously the ability to modify the playfield wouldn't work on half the screen but it would free up over 20 variables and you'd still be able to use the various PF functions on that half.  That seemed to me like a great kernel option but admittedly I don't have the programming experience to know if there is a catch that I'm missing.

[+splendidnut]

1 minute ago, LatchKeyKid said:

That seemed to me like a great kernel option but admittedly I don't have the programming experience to know if there is a catch that I'm missing.

Every kernel option adds complexity to the kernel implementation.  The standard kernel is already quite complex due to all the options available.

 

It seems you're trying to escape the constraints of bBasic.  The bigger you dream, the more likely you'll need ASM to accomplish what you want

[LatchKeyKid]

Good point.  I need to focus on trying to fall asleep first! 

[LatchKeyKid]

Just curious about sprite management by scanline in bB standard kernel... is it possible?   Other than color when those options are enabled for p0/p1, is it possible to change things about a sprite line by line?  For example, if you wanted to move a multi-line ball or missile to institute a shift/bend (like in my profile picture with the reaper's scythe) or if you wanted to make a player sprite double wide for added size but just for a couple lines (like in Kung Fu Master to extend the players leg beyond the typical 8 pixels in order to kick).

[+splendidnut]

The standard kernel would have to be modified/customized to support line-by-line size changes of the player/missiles.  The easiest way would probably involve swapping out a feature, like the player0colors, to substitute in the size change.

 

Also, you would have to be careful and take into account the parallel features of whichever size register you are going to be changing:

  - each player (sprite) / missile pair are controlled with a shared register (NUSIZx)

  - the ball size is controlled by the same register (CTRLPF) as the playfield controls (priority + mirror/repeat settings).

[LatchKeyKid]

Thanks again.  I figured that might be the case given the complete lack of any mention over on RandomTerrain's site despite how detailed and complete it is but thought it might be good to ask.  I'll just save that for another time and, just in case, I've been converting my sprites to something that doesn't require those types of tweaks.

[+Gemintronic]

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.