Quick Questions for Atari 2600 Programmers Thread

[Living Room Arcade]

If you have a quick question for the programmers regarding Atari 2600, post it here.  

Edited April 20 by Living Room Arcade

[Living Room Arcade]

Programmers, do you think it's possible to make a Klondike Solitaire-type game for Atari 2600?

Or isn't the Atari 2600 hardware able to handle something like that?  

Your opinions, please.  

 

 

My guess:

Spoiler

No.  Reason: Not enough RAM.

Edited February 18 by Living Room Arcade

[glurk]

I'd say the problem with that would be less about RAM (which can be added in carts) and more about any adequate way to display all of the cards properly.  Very few card games have been made for the 2600, and those that have are a bit lacking in the display department.  

 

Although I'm sure some people enjoy Bridge and Blackjack...

[mzxrules]

doing some quick math, the game state for klondike could be stored in about 86 bytes, leaving 42 bytes left over for other things

 

• 52 bytes to shuffle the deck. We can use this memory to not just store the deck, but also the cards dealt to each stack such that e.g. index 0-23 is the shuffled deck, 24 is stack 1, 25-26 is stack 2 etc.
• 1 byte for the deck cursor. The deck has a maximum 24 cards, so this would be 5 bits.
• 3 bytes for the hidden card cursor for stacks 2-7. Since hidden card stack length caps at 7 cards, only 3 bits are needed to store state, so you could store 2 stacks in one byte.
• 2 bytes for the 4 suit foundations. Since they increment sequentially, you only need 4 bits to store each suit.
• 28 bytes to store each of the 7 stacks. For each stack, 1 byte will store the top card, 1 byte will store the stack length, and 2 bytes will store the "run" pattern as a series of up to 12 bits. Since cards can only be stacked in an alternating black and red sequence in descending card value order, only 1 bit is needed to determine a card's suit (i.e. determine if a red card is a diamond or heart, black card is spade or club).

[Living Room Arcade]

Wow!  So, RAM is not the problem, you say.  You say that displaying the cards would be the trick.    

Well, I think, usually, we see Klondike on PC's and smartphones.  

It's probably way too much graphical detail for Atari 2600, right?  

Edited February 18 by Living Room Arcade

[glurk]

It probably could be done in some limited way, but look at the existing card games I mentioned before, like Bridge, or Blackjack.  The graphics are just "good enough" but not really great.

 

The 2600's graphics capabilities (and lack of...) are quite well known, even to non-programmers.  2 sprites, 2 missiles, one ball, and a 40 pixel playfield.  There just really isn't enough there to do 7 rows of cards in full color, wvith suits and all.

 

Even with DPC type enhancements it would be difficult, and orobably use much flicker.   But I'm sure some clever programmer could pull off some limited version in some way.  But it would involve compromise...

[mzxrules]

yea. one way to compromise would be to break down the game into multiple views. You could have one view that only renders 2 stacks per frame that you can scroll between the stacks left and right, and another view for rendering the deck, top cards, and fountain cards. I think it'd be pretty doable, just end up being like 8 or 16K

[+Bruce-Robert Pocock]

Honestly, you could certainly have 2 cards per row, and four rows for seven total cards, and only show the top card suit and number, and there you go.

[Living Room Arcade]

Have you guys seen Poker Squares?  I think it's the best looking one.  

Poker Squares

 

For reference, here are some others

    

Blackjack, Casino Blackjack, Bridge and Euchre

Casino 21 Blue

Edited February 19 by Living Room Arcade

[+karri]

 

This was my Easter surprise for the Lynx. An egg themed klondike for 160 x 102 pixels. The code would be trivial to port to 7800. But 2600?

I can share my C source if someone is interested. Perhaps the new cc2600 compiler would be the easiest path for trying to compile it...

[Living Room Arcade]

On 2/18/2024 at 5:01 AM, mzxrules said:

doing some quick math, the game state for klondike could be stored in about 86 bytes, leaving 42 bytes left over for other things

 

• 52 bytes to shuffle the deck. We can use this memory to not just store the deck, but also the cards dealt to each stack such that e.g. index 0-23 is the shuffled deck, 24 is stack 1, 25-26 is stack 2 etc.
• 1 byte for the deck cursor. The deck has a maximum 24 cards, so this would be 5 bits.
• 3 bytes for the hidden card cursor for stacks 2-7. Since hidden card stack length caps at 7 cards, only 3 bits are needed to store state, so you could store 2 stacks in one byte.
• 2 bytes for the 4 suit foundations. Since they increment sequentially, you only need 4 bits to store each suit.
• 28 bytes to store each of the 7 stacks. For each stack, 1 byte will store the top card, 1 byte will store the stack length, and 2 bytes will store the "run" pattern as a series of up to 12 bits. Since cards can only be stacked in an alternating black and red sequence in descending card value order, only 1 bit is needed to determine a card's suit (i.e. determine if a red card is a diamond or heart, black card is spade or club).

@mzxrules  Hey, I am just realizing, you are the developer working on Zelda for Atari 2600, aren't you?  I'm very excited about that particular project.  Looks great!  I'm kind of a big fan.  I saw your recent post with video.  Looks like the shield is working!  May I ask, any news/updates about Zelda?  

Edited February 19 by Living Room Arcade

[mzxrules]

Not much I wanna say at the moment, other than I've been picking up the pace on development and focusing on getting core gameplay things completed. I'd like to show more soon, but there's a lot I want to fix up first.

[Living Room Arcade]

On 2/21/2024 at 2:56 AM, mzxrules said:

Not much I wanna say at the moment, other than I've been picking up the pace on development and focusing on getting core gameplay things completed. I'd like to show more soon, but there's a lot I want to fix up first.

@mzxrules  Sorry, I just saw your reply now.  Acknowledged.  Good stuff!  Looking forward to your next Zelda update!   

Edited February 24 by Living Room Arcade

[Living Room Arcade]

For reference

Blackjack Theta VIII

[Living Room Arcade]

Thanks, you guys, for your replies.  Very interesting!  Just to clarify, I'm not asking for anyone to to anything.  Was literally just wondering if it's possible.  That's all.

 

Q: Is Klondike Solitaire possible on Atari 2600

Answer seems to be: Maybe.  There's enough RAM.  Drawing the cards would be the challenge.

 

Next Quick Question: Hypothetically speaking, do you think Klondike with autocomplete is possible on Atari 2600?  

Again, to clarify, not asking anyone to do anything.  Just wondering simply is it possible on 2600 hardware.  Thank you!  

 

(Do you know what I mean by autocomplete?  It means all of the cards have been revealed and you can now win.  In that case, the computer can play the cards on the table for you.  It's fun to watch, kind of exciting, and practically speaking, saves you a lot of time compared to doing it yourself.)

 

LATE EDIT: My guess:

Spoiler

I guess yes, because the algorithm/procedure for autocomplete is simple, would require only a little extra code.  

 

Edited February 25 by Living Room Arcade

[+karri]

You need to enforce the rules when the player chooses his moves. Autocomplete is just building on the rule check function. So it takes very little extra resources.

[Living Room Arcade]

Hello programmers, 

 

Do programmers generally always get the highest scores on their own games that they made?  You know, because they know all the tricks to win at it.  Or is that not true?  Do the players score higher than even the programmers could?  I've always wondered.

 

Any programmers out there would like to share your response, I'd be interested to hear!  Thanks!

[freshbrood]

On 2/17/2024 at 9:02 PM, Living Room Arcade said:

Programmers, do you think it's possible to make a Klondike Solitaire-type game for Atari 2600?

Or isn't the Atari 2600 hardware able to handle something like that?  

Your opinions, please.  

 

 

My guess:

  Reveal hidden contents

No.  Reason: Not enough RAM.

Hi. Ninja Kombat dev here. I am also currently working on a Texas Holdem Poker game in 2600 using 6ai players + 1human. (Forthcoming demo for that one as well)

 

I think the math is very possible to do a Solitaire game because thats less complicated than Holdem, and I have already figured out a way to do it using just BBasic and no special kernels. 

 

So in my humble opinion, if you are only using Bbasic then I would only display the very top face cardss. (Any solitaire player understand all under cards are consecutive and same colored- no need to show a portion of the under cards.

 

This would minimize flicker to only having 4 sprites at a time. 

 

You could show how long the card stacks are in a few ways. For example:

 

1) A "2" card sprite could actually be 6 pixels tall, while only drawing the number 2 at the bottom 5 pixels and setting the height to 5. Then as you stack it on top of an A it becomes 6 pixels tall and moves one y position down. Voila. Not fancy but now you can represent all 52 cards as only 4 stacks with varying heights. You only need to flicker twice- po for Hearts and Diamonds, p1 for Spades and Clubs, etc..

 

A third flicker maybe for the unplaced card. Not fancy but doable 

 

2) Option 2 would be to use missiles to extend the stacks of cards and have all sprites fixed at (e.g.5?) pixels. But getting a white background with a red or black number card might require a colored playfield or additional flicker tricks. 

 

3) Draw the selected card in your hand in the corner of the screen using playfield blocks, but using a missle or ball just a white square you can place down onto the other 4:stacks. Once placed the giant pf card display disappears and the white block you placed becomes the top sprite card on top of the stack. I might favor this 3 option most. Card held in your hand is just a white square represented by pf blocks in the corner that you place on top of the 4 flickered card sets. It would fill the negative space on the screen nicely, minimize flicker and be the easiest to code not having to use special kernels and just whole simple colors.

 

On 2/17/2024 at 9:02 PM, Living Room Arcade said:

Programmers, do you think it's possible to make a Klondike Solitaire-type game for Atari 2600?

Or isn't the Atari 2600 hardware able to handle something like that?  

Your opinions, please.  

 

 

My guess:

  Reveal hidden contents

No.  Reason: Not enough RAM.

 

[freshbrood]

2 minutes ago, freshbrood said:

Hi. Ninja Kombat dev here. I am also currently working on a Texas Holdem Poker game in 2600 using 6ai players + 1human. (Forthcoming demo for that one as well)

 

I think the math is very possible to do a Solitaire game because thats less complicated than Holdem, and I have already figured out a way to do it using just BBasic and no special kernels. 

 

So in my humble opinion, if you are only using Bbasic then I would only display the very top face cardss. (Any solitaire player understand all under cards are consecutive and same colored- no need to show a portion of the under cards.

 

This would minimize flicker to only having 4 sprites at a time. 

 

You could show how long the card stacks are in a few ways. For example:

 

1) A "2" card sprite could actually be 6 pixels tall, while only drawing the number 2 at the bottom 5 pixels and setting the height to 5. Then as you stack it on top of an A it becomes 6 pixels tall and moves one y position down. Voila. Not fancy but now you can represent all 52 cards as only 4 stacks with varying heights. You only need to flicker twice- po for Hearts and Diamonds, p1 for Spades and Clubs, etc..

 

A third flicker maybe for the unplaced card. Not fancy but doable 

 

2) Option 2 would be to use missiles to extend the stacks of cards and have all sprites fixed at (e.g.5?) pixels. But getting a white background with a red or black number card might require a colored playfield or additional flicker tricks. 

 

3) Draw the selected card in your hand in the corner of the screen using playfield blocks, but using a missle or ball just a white square you can place down onto the other 4:stacks. Once placed the giant pf card display disappears and the white block you placed becomes the top sprite card on top of the stack. I might favor this 3 option most. Card held in your hand is just a white square represented by pf blocks in the corner that you place on top of the 4 flickered card sets. It would fill the negative space on the screen nicely, minimize flicker and be the easiest to code not having to use special kernels and just whole simple colors.

 

 

In short, yes. I know its possible. 

[Living Room Arcade]

Thank you, @freshbrood!  With those hardware limitations of the 2600, it's like a puzzle to solve, isn't it?  Sounds kind of fun to think about!  Thank you for your insights.  

 

The consensus so far seems to be that there's enough RAM, but compromises (and a lot of creativity and ingenuity!) would be needed to display the cards.  Interesting!  

[Living Room Arcade]

New Question

 

Programmers, would it be technically possible, with all of the limitations of the Atari 2600 hardware, to create a race car game for the 2600 in which the CPU-controlled cars have an existence off the screen?  

 

I am not asking anyone to do anything.  This is only intended as discussion.  I'm curious about the challenges and limitations of Atari 2600 programming.  That's all that this is.  

 

Atari 2600 programmers, your thoughts?  

 

UPDATE: New thread here.  

Edited April 21 by Living Room Arcade

[+splendidnut]

11 minutes ago, Living Room Arcade said:

Programmers, would it be technically possible, with all of the limitations of the Atari 2600 hardware, to create a race car game for the 2600 in which the CPU-controlled cars have an existence off the screen?  

Yes it's possible.  The total number of cars (on screen + off screen) would mainly be limited by their RAM requirements and how much CPU processing time each car needed.

[freshbrood]

37 minutes ago, Living Room Arcade said:

Thank you, @freshbrood!  With those hardware limitations of the 2600, it's like a puzzle to solve, isn't it?  Sounds kind of fun to think about!  Thank you for your insights.  

 

The consensus so far seems to be that there's enough RAM, but compromises (and a lot of creativity and ingenuity!) would be needed to display the cards.  Interesting!  

The contrainsts are what's fun! And especially that last part- creativity and ingenuity!

 

Don't worry about making graphics look good- just focus on making them functional and easy to understand first. The bare minimum. Add the bells and whistles later.  

Edited April 20 by freshbrood

[freshbrood]

On 3/16/2024 at 12:25 AM, Living Room Arcade said:

Hello programmers, 

 

Do programmers generally always get the highest scores on their own games that they made?  You know, because they know all the tricks to win at it.  Or is that not true?  Do the players score higher than even the programmers could?  I've always wondered.

 

Any programmers out there would like to share your response, I'd be interested to hear!  Thanks!

I would think you'd only need two variables for the x,y of each car.  (That's if you wanted some kind of map that shows where they are)

 

If you go by how Enduro does it then you really only need one single variable for every off screen car- using 127 as being parallel to the player (and onscreen, drawn) and say anything less than 107 is off screen behind the player and anything above say 147 is off screen ahead of the player. 

 

(my wacky phone keeps quoting the wrong topics! As to the offscreen cars, etc.. Iirc they are persistent in Enduro)

Edited April 21 by freshbrood

[+KaeruYojimbo]

On 3/16/2024 at 12:25 AM, Living Room Arcade said:

Do programmers generally always get the highest scores on their own games that they made?  You know, because they know all the tricks to win at it.

Good players are going to figure that stuff out eventually. That's part of what makes them good players. They pay close attention to what's going on in a game to figure out every little thing that happens and any way they can get more points. Even stuff the developer doesn't realize is there.

 

A few years ago a couple of High Score Club players found a bug in Ms. Galactopus that would sometimes give out a huge end of level bonus (and keep in mind that this was after the initial run of carts had been made and sold, so as far as I was concerned, this was a finished game, not a WIP). I tracked it down and fixed it before things got crazy, but if I hadn't I'm sure it wouldn't have been long before the best players figured out exactly how to trigger it consistently and get massive scores.

 

So combine that with the fact that the top players are just flat out better at playing video games than I am and any advantage I have as the developer goes away pretty quickly. I'm pretty good at my games, partly because I know what's going on under the hood and partly because I spend a lot of time playing them during development, but I'm nowhere near the best.