Jump to content
Turbo Laser Lynx

bB / Atari 2600 graphics capabilities and tools?

Recommended Posts

Hi guys!

 

I've only had a quick look at it so far, and the bB examples in the different get started threads seem really straight forward and easy to understand, but I didn't find any post or thread about understanding the graphics yet (I did search around).

I'm trying to understand what kind of graphics are possible with batariBasic on the 2600 for visualizing a mock up in my head (at first). As it doesn't have the usual character based graphics as a lot of the other 8-bit systems I don't have a that much of a clue about how it works yet. Would something like the smurfs graphics be possible in bB (minus changing color every line in some places)? Lovely looking game btw:

 

 

I read that there's two player- and two missile- sprites which is nice, and I see that a lot of games are doing some sort of multiplexing.

 

I looked at the wip game Bag Boy here in the bB forum and it seems to have very colorful sprites and a lot of sprites moving around. I quickly skimmed through the code and I don't think I saw any assembly in there, so am I correct in assuming batari Basic is capable of multiplexing and "multicolor sprites"?


I read in this other thread that:

On 10/27/2019 at 9:36 AM, iesposta said:

Using batari Basic you can have single line color sprites, but Background color changes and Playfield color changes can only go down to double line. 

 

But I'm not sure I'm following here. Does "single line color sprites" mean that you can change color every line? (Looks like that in Bag Boy). And perhaps it means you can change color every other line ("double line") on the playfield and Background? (In contrast to having many colors on the same line on a sprite and changing color every line in the background).

I wonder what some of the other restrictions are that I haven't learned about yet, because it seems to me that I have underestimated the Atari 2600 earlier (I'm properly starting to familiarize myself with it only now). It seems to be able to have really colorful graphics in some ways compared to some limitations of other systems/computers of the time.

 

How many colors per line can a typical 2600 game usually have?

Are there some graphic tools for creating mock-ups or game graphics for easier understanding how the 2600 graphics work?

 

Ok I found this now:

On 8/17/2007 at 7:03 AM, CurtisP said:

bAtari Basic divides the screen into two sections: the playfield and the score. The playfield is made up of 11 eight-pixel high lines, each of which is 32 pixels across, with a four pixel wide space on each side.

So I guess it's a matter of how many times you can change the color of the playfield "cells" per line and perhaps you can change the background every third line in bB.


Thanks for any help!


 

Edited by Turbo Laser Lynx

Share this post


Link to post
Share on other sites

I'd read through Random Terrains website and compile a few examples from the bB boards here.  

 

batari BASIC does the heavy lifting by providing graphic kernels you can choose from.  You decide what tradeoffs and features you need:

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

 

The short answer is, if you want Smurfs level graphics you need to study up on the DPC+ kernel.  That requires AtariAge boards for physical carts so get a subscription for the discount.

  • Thanks 1

Share this post


Link to post
Share on other sites

Extremely simplified, 2600 changes the scan line that makes up a television picture as it is drawing that scan line. That’s what has allowed it to be exploited and pushed so far from what it was originally designed to be - which was a Pong / Tank video game.

 

It has what I like to think of as 7 “objects” that can be manipulated. Two 8-bit objects: Player0, Player1; Three 1-bit objects: Missile0, Missile1, Ball; and a Playfield, and Background

 

Next it is good to learn how the 2600 uses and changes those objects in different games.

You can see these objects visually using the emulator Stella’s “Debug Colors” by pressing Alt-period or Command-period (PC or Mac computer).

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

Hey thanks a lot for pointing me in the right direction guys!
 

On 11/12/2019 at 1:42 AM, Gemintronic said:

I'd read through Random Terrains website and compile a few examples from the bB boards here.  

 

batari BASIC does the heavy lifting by providing graphic kernels you can choose from.  You decide what tradeoffs and features you need:

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

 

The short answer is, if you want Smurfs level graphics you need to study up on the DPC+ kernel. 


I've studied the tables and I think I already understand it a lot more now. I do obviously need to test some things out and experiment to grasp it fully. I found this other table that complements the random terrain one (although they state the same thing): https://alienbill.com/2600/kernel.cgi

All those choices! It makes it hard to choose! Fun stuff, I love restrictions! :-D

 

 

18 hours ago, iesposta said:

Extremely simplified, 2600 changes the scan line that makes up a television picture as it is drawing that scan line. That’s what has allowed it to be exploited and pushed so far from what it was originally designed to be - which was a Pong / Tank video game.

 

It has what I like to think of as 7 “objects” that can be manipulated. Two 8-bit objects: Player0, Player1; Three 1-bit objects: Missile0, Missile1, Ball; and a Playfield, and Background

 

Next it is good to learn how the 2600 uses and changes those objects in different games.

You can see these objects visually using the emulator Stella’s “Debug Colors” by pressing Alt-period or Command-period (PC or Mac computer).


I think I kind of had understood this, but thanks for clarifying. Checking out how different games uses the Player/Missile graphics really helps! Thanks a lot for that hint!
 

15 hours ago, Random Terrain said:

 

Thanks, this helps a lot!

I only checked two games so far (will check more when I have more time in front of the computer) but neither smurfs or bag boy seem to use the missile or ball graphics. Are these usually not "worth using" other than in really special cases?

 

Wohoo, I also found this nice "multisprite" example, perfect for understanding the multiplexing.
https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#ex_multisprite_9_objects
 

 

Edited by Turbo Laser Lynx
  • Like 1

Share this post


Link to post
Share on other sites
33 minutes ago, Turbo Laser Lynx said:

Wohoo, I also found this nice "multisprite" example, perfect for understanding the multiplexing.
https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#ex_multisprite_9_objects

 

Also check out the DPC+ example programs:

 

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

  • Thanks 1

Share this post


Link to post
Share on other sites

Ahaa! Now I see what @Gemintronic meant:

Quote

DPC+ is based on the Display Processor Chip that was designed by David Crane for Pitfall II: Lost Caverns. The DPC+ kernel is hardware assisted and only works with Melody/Harmony cartridges and any version of Stella released after October of 2012.

Are there many purists in the 2600 scene who'd count this as cheating? I usually like targeting a base system, but as long it's about having fun I think this kind of thing is fine too. I'm also a sucker for nice graphics so...:lol: Like my experimenting on the Vic-20 has been on a 16k expanded system so far, and I will probably have to go all the way to 32K

Anyhow, I'm impressed how well done bB seems to be made and documented! I'm going to have so much fun. I wish there was similar fantastic "easy to get started with" development tools / "environments" for other retro systems too.
 

Edited by Turbo Laser Lynx

Share this post


Link to post
Share on other sites

The whole "cheating" discussion can be a bit of a sore point at times. Suffice it to say that there are people who enjoy programming to the original constraints, and people who enjoy making games that make use of extra cartridge hardware. Our community is big enough to support both approaches, I think.

  • Like 1

Share this post


Link to post
Share on other sites

I don't consider it cheating if a physical copy can be produced to work on unmodified original hardware.  I don't care if the cartridge itself is harmony/melody/modified...as long as it is not like SGM games for colecovision that require the expansion module - gotta read and understand what you're buying in that homebrew scene...

  • Like 1

Share this post


Link to post
Share on other sites

IMO about cheating i say do what works for you. There is many ways too look at it and firstly i will say much respect goes to those who choose the purest route of ASM. However i wouldn't say BASIC is a cheat way out either, especially as batari has many restrictions of it's own. Well written BASIC games can look great it just takes effort, a full understanding of the restrictions and some thinking outside the box.

 

Some have fun spending the 4 weeks or so writing a kernel and kudos to them while others like myself haven't the time. I have looked into 6502 lessons on you tube ect and made some novice assembler programs for the NES and C64 in the past. Gone through the Stella handbook countless times and have a pretty clear idea of whats going on. Although the shear time it takes and the assembler language just isn't really my thing (intriguing and interesting just not for me). High level languages just make sense in my mind and im confident in the language therefore can write in a speedy manner.

 

I think the issue is those who appear out of the blue and pump out low quality 1v1 shooters and claim the game is finished never to be seen again. Although there is machine code "games" that were terrible through-out the 2600's history aswell. Good games just take some effort and competency no matter what tools are used.

 

My opinion anyway

  • Like 1

Share this post


Link to post
Share on other sites
3 hours ago, Turbo Laser Lynx said:

Are there many purists in the 2600 scene who'd count this as cheating? 

Some do. But they probably all own and love Pitfall II, so don't listen to them.

 

Use what you need to use to make the game you want to make. If that means 32K and an ARM co-processor, go for it. But it can also be fun to see what you can accomplish in 4K.

  • Like 1

Share this post


Link to post
Share on other sites

Cheating really depends on your vision for the game.  Also, how tied you want to be to extra hardware when it comes time to physically  create yer game.

 

Making a 4k ROM game physically is something almost anyone can do.  DPC+ requires AtariAge to make it for you.  So, if "from scratch" matters enough your options change.

 

Personally, I'd try making a 4k game first and move your way up.

  • Like 1

Share this post


Link to post
Share on other sites
5 hours ago, Karl G said:

The whole "cheating" discussion can be a bit of a sore point at times. Suffice it to say that there are people who enjoy programming to the original constraints, and people who enjoy making games that make use of extra cartridge hardware. Our community is big enough to support both approaches, I think.


Exactly! Very nice to see like minded people here. It's too easy to fall into the trap thinking that things should be only one way. There's obviously "merit" in- and fun to be had both ways.
 

4 hours ago, TwentySixHundred said:

There is many ways too look at it and firstly i will say much respect goes to those who choose the purest route of ASM. However i wouldn't say BASIC is a cheat way out either, especially as batari has many restrictions of it's own. Well written BASIC games can look great it just takes effort, a full understanding of the restrictions and some thinking outside the box.

 

Some have fun spending the 4 weeks or so writing a kernel and kudos to them while others like myself haven't the time.


Yes, I agree, and of course also the biggest respect and thanks to those who have made it possible coding in higher level languages for these old machines.
 

4 hours ago, KaeruYojimbo said:

Some do. But they probably all own and love Pitfall II, so don't listen to them.

 

Use what you need to use to make the game you want to make. If that means 32K and an ARM co-processor, go for it. But it can also be fun to see what you can accomplish in 4K.


Haha! :grin: I would also bet on it that they do. Both approaches are indeed interesting.
 

1 hour ago, Gemintronic said:

Making a 4k ROM game physically is something almost anyone can do.  DPC+ requires AtariAge to make it for you.  So, if "from scratch" matters enough your options change.

 

Personally, I'd try making a 4k game first and move your way up.


I've been looking into and learning about a lot of old systems lately :love: (I'm all over the place :o) so I haven't really thought about a physical release for the 2600 yet, but it's true that for an expensive atariage cart the expectations would probably be high, so at least with a physical release in mind it would possibly make sense to start more simple. I thought I saw a single cart was 25$ (can't seem to find it anymore) but perhaps AA have some deal(s) if they like a particular game someone wants to release with them?

 

Share this post


Link to post
Share on other sites

I will say that Random Terrain's website has been a huge help understanding batari basic. I started using the standard kernel but switched to the DPC+ for some of the graphic capabilities and what I was trying to accomplish, although I suppose I could have gotten the same gameplay value sticking with the original. 

 

In Bag Boy, once I switched to DPC+, I utilized multiple sprites but haven't used the missile or ball sprites yet. I have been trying to figure out how best to use them, either for a rain or snow effect, or for some other thing, like a more ornamental purpose. As I am learning more and more I keep picking apart code from other examples and programs,  as well as using the debugger to point me in the right direction. That and trial and error has worked pretty well for me considering my experience with programming was very limited from the start. 

  • Like 1

Share this post


Link to post
Share on other sites
7 hours ago, KevKelley said:

I will say that Random Terrain's website has been a huge help understanding batari basic.

I was mind blown by it, I haven't seen anything like it for any other retro console or computer.
 

Quote

I started using the standard kernel but switched to the DPC+ for some of the graphic capabilities and what I was trying to accomplish, although I suppose I could have gotten the same gameplay value sticking with the original.

It's really hard to choose. On one hand I really like the naive graphic results you can get on the oldest systems, it can be funny/humorous and still graphically striking (i.e. easy to read) because of the simplicity. Graphic design and cartoons use/have the same strengths and uses the same techniques, like restricted palette, a simple striking "message" and the viewer "filling out the rest" themselves. On the other hand the more fancy Atari 2600 / DPC+ games I've seen look really nice, obviously even those retain the same traits.
 

Quote

In Bag Boy, once I switched to DPC+, I utilized multiple sprites but haven't used the missile or ball sprites yet. I have been trying to figure out how best to use them, either for a rain or snow effect, or for some other thing, like a more ornamental purpose. As I am learning more and more I keep picking apart code from other examples and programs,  as well as using the debugger to point me in the right direction. That and trial and error has worked pretty well for me considering my experience with programming was very limited from the start. 

Bag boy is really great looking and fun so far!

 

Edited by Turbo Laser Lynx

Share this post


Link to post
Share on other sites

The graphics for my game were originally simple with the player, a cart, and a square. Power ups were other squares. Then I showed my wife, who asked why cars didn't look like cars.  I had also experimented programming in different kernels, like the multisprite kernel, but I found the DPC+ fit the needs of what I wanted to do and gave me flexibility in my learning. 

 

I definitely want to program a fun and original game using less. Before I learned of the limitations I had a grand idea of how I wanted the game but over time I adapted the game. I am amazed at all the incredible tools available and that are currently  being developed. When I tried learning this stuff years ago I had such a hard time but the Atari community is amazing. Sometimes when I find myself in a slump I go through the forums or look at the sample code and it gets me going again.

  • Like 1

Share this post


Link to post
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.

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