35 replies to this topic

[kamakazi]

Hi Everyone!

It's been a long time since I was on here last. Been busy with college stuff and taking care of my wife. For our recent anniversary, we purchased a 2600 Jr with Centipede (complete in box) and Ms. Pac-Man (new). Junior has been getting more attention than our PS3...but it has also sparked my interest more into developing for the console. So much in fact that I setup an old desktop just for developing for it. I have been reading about what others have done along with the issues they had during development. I am turning to my friends here in hopes that maybe sharing programming experiences with the 2600 will point this game idea in the right direction.

I know of the 2600's 126 memory restraints. I'm wanting to try to create a game similar to Bejeweled for the 2600...in Breakout style. But would the 2600 be able to handle it?

So far, on paper, I plan to use the 2600's players, missile, and ball sprite routines...if these will work. My main concern is how to have the 2600 keep track of what is where or tricks in checking for matches. This will be my first attempt at Assembly after programming in BASIC since the Atari 800 first hit store shelves.

For development, I already installed Virtual Bb, Batari BASIC, and Stella emulator. What other programs (for Windows XP at least) are available for creating 2600 sprites?

Thanks in advance for the help.

[Player 3]

kamakazi, on Fri Aug 13, 2010 11:56 AM, said:

 What other programs (for Windows XP at least) are available for creating 2600 sprites?  

I believe if my disassembly-peeping days are correct, you might as well draft the sprites in something real simple such as MicroSoft Paint, the default Windows art program. Once you are ready to implement graphics, you have to specify what pixels go where.


Such as an example in an assembly program known as Pitfall!:

Harry1:
    .byte 000000 ; |        |
    .byte %10000000 ; |X       |
    .byte %10000000 ; |X       |
    .byte %11000011 ; |XX    XX|
    .byte %01100010 ; | XX   X |
    .byte %01100010 ; | XX   X |
     .byte %110110 ; |  XX XX |
     .byte %111110 ; |  XXXXX |
     .byte %011100 ; |   XXX  |
     .byte %011000 ; |   XX   |
     .byte %011000 ; |   XX   |
     .byte %111100 ; |  XXXX  |
     .byte %111110 ; |  XXXXX |
     .byte %111010 ; |  XXX X |
     .byte %111000 ; |  XXX   |
     .byte %011000 ; |   XX   |
     .byte %011000 ; |   XX   |
     .byte %010000 ; |   X    |
     .byte %011000 ; |   XX   |
     .byte %011000 ; |   XX   |
     .byte %011000 ; |   XX   |
     .byte 0000 ; |        |

Please note that sprites can only be EIGHT pixels wide, but any amount in height. I hear there's an assembly method to enlarge the width of a sprite using some method, but that's a while ago, which would be a couple of months. Oh, and when you program a sprite, it has to be upside-down in order to be rendered properly in a human-recognizable view.

[kamakazi]

The upside-down sounds similar to the 7800's way of rendering sprites. Weird. Thanks for the advice!

[Player 3]

kamakazi, on Fri Aug 13, 2010 1:42 PM, said:

The upside-down sounds similar to the 7800's way of rendering sprites.  Weird.  Thanks for the advice!

Now hold up, boy, I ain't finished with you.





To put what I said in easier terms, DRAFT your sprites, CODE the game first with placeholder/final graphics, use said method. Draft, code, place.

Or you could directly find specific sections of disassembled programs on Qotile.net. Great resource.

[Random Terrain]

Creating sprites with Visual bB is about as easy as it gets. A lot better and more fun than using some crappy paint program.

[Player 3]

Random Terrain, on Fri Aug 13, 2010 5:19 PM, said:

Creating sprites with Visual bB is about as easy as it gets. A lot better and more fun than using some crappy paint program.

Yeah, but bB/VbB doesn't exactly give all the power the programmer can use.


Even in bB, you still have to pin-point what pixels go where and what colour they are.

[Random Terrain]

Player 3, on Fri Aug 13, 2010 5:30 PM, said:

Yeah, but bB/VbB doesn't exactly give all the power the programmer can use.


Even in bB, you still have to pin-point what pixels go where and what colour they are.

You draw your sprite and select colors using the Sprite Editor and you can save it and drag and drop the file into your program or you can copy the data and paste it:

http://www.randomter...b.html#spriteed




Maybe I'm not understanding what you are saying. Pixels in sprites using bB are twice as high, so if you want to use the data using nothing but assembly, you'll want to adjust the data, but the essential data is ready to go. If you want to use nothing but bB, you have everything you need.

Edited by Random Terrain, Fri Aug 13, 2010 6:29 PM.

[Wickeycolumbus]

kamakazi, on Fri Aug 13, 2010 1:42 PM, said:

The upside-down sounds similar to the 7800's way of rendering sprites. Weird. Thanks for the advice!

They can be either way, depends on the kernel. It's typically done upside down like that because it's usually more economical (in terms of CPU usage) to do count down loops rather than count up.

[Random Terrain]

Wickeycolumbus, on Fri Aug 13, 2010 6:07 PM, said:

. . . it's usually more economical (in terms of CPU usage) to do count down loops rather than count up.

Is that true for most things? Like if I'm using various counters, is it better to count down than count up?

[Wickeycolumbus]

Random Terrain, on Fri Aug 13, 2010 6:31 PM, said:

Wickeycolumbus, on Fri Aug 13, 2010 6:07 PM, said:

. . . it's usually more economical (in terms of CPU usage) to do count down loops rather than count up.

Is that true for most things? Like if I'm using various counters, is it better to count down than count up?

While it is usually true, it really only matters if timing is critical, like in a Kernel for example. The difference is only a few cycles.

[Random Terrain]

Wickeycolumbus, on Fri Aug 13, 2010 6:54 PM, said:

While it is usually true, it really only matters if timing is critical, like in a Kernel for example. The difference is only a few cycles.

Thanks. I'll count down whenever I have the choice, just in case.

[RevEng]

On the theoretical side...

We're talking about a 2-cycle difference. Count up if it makes your bB code more understandable, as that's more valuable.

On the practical side...

A countdown loop to zero in bB isn't optimized. It still uses a "CMP #0" before the branch. So there's actually no savings.

[Random Terrain]

RevEng, on Fri Aug 13, 2010 8:29 PM, said:

On the theoretical side...

We're talking about a 2-cycle difference. Count up if it makes your bB code more understandable, as that's more valuable.

On the practical side...

A countdown loop to zero in bB isn't optimized. It still uses a "CMP #0" before the branch. So there's actually no savings.

Thanks. That's good to know.

[batari]

RevEng, on Fri Aug 13, 2010 8:29 PM, said:

On the theoretical side...

We're talking about a 2-cycle difference. Count up if it makes your bB code more understandable, as that's more valuable.

On the practical side...

A countdown loop to zero in bB isn't optimized. It still uses a "CMP #0" before the branch. So there's actually no savings.

If you compile with -O, a peephole optimizer will be invoked which will remove all "CMP #0" and some other things such as loads right after a store to the same variable. If using bB code only, you may use -O without consequences (all CMP #0 are redundant in bB). It's not automatic because the peephole optimizer does not know if it's looking at inline asm. If you use CMP #0 in a non-redundant fashion in your inline asm, it will remove it.

[kamakazi]

@ Player 3: LOL. I didn't think you was...but was thanking in advance. And it still sounds similar to how the 7800 processes sprites. Too bad there isn't A VisualbB and batari for the 7800. That would be sweet!

Getting back to the 2600. I have to actually say that the 2600 is an interesting piece of hardware. After most of the material I've been reading, it's the 2600 that is the real magic. I bet if Atari would of actually allowed more time for game development during the system's early years, developers might of been able to produce some interesting graphics. I'm not counting Activision or Imagic...I'm talking about Atari employees. One of the most interesting games I've found is Centipede for the 2600. The title screen uses better graphics than the game play. At times it makes me wonder why Atari didn't use the mushrooms in the title screen in place of the dashes in the game play. Then again, the centipede flickers a bit too...and that would of probably only added to it.

One of the areas I am a little concerned about with the game idea I have is...

The game I am attempting to create is going to be similar to Breakout...but play more like a Bejeweled game. The idea is to have the player "shoot" colored blocks in the playfield and attempt to knock out a series of three bricks by matching colors (or more if the idea works). After a set time limit, any bricks on the playfield will drop closer to the player. If they reach the player's paddle, then it's game over. I am also thinking about having the ball come out randomly as an object to avoid. The main area I'm concerned about is the logic to keep track of what block is where along with its color. I am also not sure yet of what register to use for the block the player can shoot. I'm thinking that the Player 1 register would work. But the playing block needs to be able to change colors randomly without changing any blocks that have already been placed. And the Missile 0 register I'm not sure will work as it takes on the color of the player. I'm afraid that setting up a virtual grid for the blocks, similar to using a DIM statement in BASIC, would take away from most of the system's memory to the point there isn't enough room for the rest of the game. And I am using VisualbB for the work as I'm not comfortable enough with assembly yet.

[kamakazi]

I have another question...if the 2600's PMG only allows Player0, Player1, Missile0, Missile1, Ball and Playfield graphics, what was used to produce the 4 ghosts in Ms. Pac-Man? Just for learning purposes with VisualbB, I was going to try and create my own Space War style game with the second ship being computer controlled. I created two ships for Player0 and Player1 registers. But I was also working on the aforementioned breakout style game when I created a playfield, tested how it looked, then noticed that the playfield has thin horizontal blank lines. Does anyone know how to eliminate this?

[Wickeycolumbus]

kamakazi, on Sun Aug 15, 2010 1:29 PM, said:

I have another question...if the 2600's PMG only allows Player0, Player1, Missile0, Missile1, Ball and Playfield graphics, what was used to produce the 4 ghosts in Ms. Pac-Man?

Ms. Pac-Man repositions Player1 mid frame and updates the graphics accordingly. When two or more ghosts appear on the same line, it flickers them.

[RevEng]

kamakazi, on Sun Aug 15, 2010 1:29 PM, said:

...But I was also working on the aforementioned breakout style game when I created a playfield, tested how it looked, then noticed that the playfield has thin horizontal blank lines. Does anyone know how to eliminate this?

Use the no_blank_lines kernel option. It does come at a cost though, so read that link before you enable it.

[kamakazi]

So, Player1 is responsible for positioning all 4 ghosts??? Wow...bet that took a lot of coffee to pull off LOL. And I do have that game and did notice the flicker when two or more ghosts are on the same line. I have to ask, but how would you stop midframe and reposition Player1 in a different color without losing the other ghosts (other than on the same line)?

And for the no_blank_lines kernal...Hmmm...loss of Missile0. But that still leaves Missile1 right? And for a first time attempt at making a 2600 game, I don't plan to use multicolored sprites or playfields. Thanks for the info RevEng...it is helping me understand the 2600. It really is an amazing system as it obviously is showing games that it really shouldn't of been able to do if one stops to think about it.

[kamakazi]

Below is a screenshot of what I have so far. Currently, the game is being called "Blast Em!" So far, the paddle is using Player0 register and the block is using the Player1 register. At this time, the block is constantly flashing colors randomly picked and limited to 5 colors. But the paddle is moving and the block along with it. It's not much but it is a start. The game will use a joystick controller as the paddle will have limited movement. It will have to line-up with the row of blocks so that no block will appear offset.

Now I just need to figure out how to put random colored blocks on the screen. I also need to figure out what to use for shooting the block being held by the player's paddle. I'm excited I got this far!! I will show more screens as the game develops. For the time being, this is all I have.

Attached Thumbnails

• 

Edited by kamakazi, Sun Aug 15, 2010 6:03 PM.

[kamakazi]

I could use some ideas on what register to use for putting about 20 blocks of random colors on the playfield. Im' stumped. Any suggestions?

[Random Terrain]

kamakazi, on Sun Aug 15, 2010 10:42 PM, said:

I could use some ideas on what register to use for putting about 20 blocks of random colors on the playfield. Im' stumped. Any suggestions?

Are you talking about subjects like these:

http://www.randomter...ds.html#pfpixel

http://www.randomter...kernop_pfcolors

[kamakazi]

If what you are asking, Random, will allow multiple colored blocks on a single line (5 colors max) then yes, that would work. For a better idea, here is a rough image of what I'm trying to accomplish.

Below is a screenshot of the game so far. I created a grid over the playfield to show where all the blocks can be. Basically, the game will function much like those old LCD games. I hope to be able to put at the start of the game, randomly-colored blocks 10 blocks wide by 5 blocks down. This would be 50 blocks. As mentioned, only 5 colored blocks are used: red, blue, green, yellow and purple. Each grid section would need to hold only one block of one color.

When the player shoots the block being held by the paddle, it needs to stop at either the top of the playfield OR stop when it "hits" another block. After this, another block is given to the player of a random color. After a set time limit, I would like to have the blocks in the playfield drop to the player one row down. If any blocks reach the paddle then the game is over. For now, I would like to see if the 2600 could possibly put each block of it's own assigned color on a single row. Would the two commands you pointed me to allow this?

Attached Thumbnails

• 

[kamakazi]

I just had an idea. If Warlords used paddles and supported 4 players, are there more than just the Player0 and Player1 registers? I know all of you are going to get tired of my asking questions. I'm just trying to consider optional ways of moving this project forward. I've noticed in VisualbB that when typing in "player" that other keywords are shown and are player1, player2 and player3. Are there more registers that can be used?

[Wickeycolumbus]

kamakazi, on Tue Aug 17, 2010 7:15 PM, said:

I just had an idea. If Warlords used paddles and supported 4 players, are there more than just the Player0 and Player1 registers? I know all of you are going to get tired of my asking questions. I'm just trying to consider optional ways of moving this project forward. I've noticed in VisualbB that when typing in "player" that other keywords are shown and are player1, player2 and player3. Are there more registers that can be used?

No, only P0, P1, M0, M1, BL, and PF.