Jump to content
IGNORED

New to Atari Basic...Can You Help?


pacfanboy

Recommended Posts

I'm new to Batari. I have some experience in Basic and the C-inspired scripting language Inform (which makes Infocom-esque text adventures). I've always wanted to make an Atari game, but 6502 scared me away. I just found out about Batari and it sounds amazing! I've been looking over some source code, editing minor things and compiling, etc. I'm kinda lost when I read some of the topics on this forum, but it seems easy enough to learn. You mind if I ask some "basic" questions? They're probably dumb and if I could have found the answers elsewhere with ease, I apologize for my laziness and I won't do it again :) I'm just excited with the idea of making 2600 games and want to dive right in...

 

--multicolored sprites can't be done? That means you can't make a colorful Pitfall Harry, but you can do a single-color Indiana Jones character?

 

--there can be only 2 sprites on the screen? How do you work around this?

 

--what's the easiest way to animate the sprites (the player with joystick movements and enemies by themselves)?

 

--how come most sample games made with Batari have line breaks in the playfield? How would you make a solid background like the mazes in "Ms. Pac-Man" or the solid castle structure in "Adventure"?

 

--one last question...I'm a big fan of maze games...is their a tutorial on making maze games for Batari? A sorta how-to guide? Or is their any source code available I could study? Are they hard to make? Like how would you deal with the artificial intelligence of the enemies within the maze?

 

If there's not a lot of info on maze games...then how about a game like "Berzerk"? Is that possible on Batari without adding 6502 assembly code?

 

if anybody could answer any of these questions, thanks! I'll probably ask many more in the future :)

Edited by pacfanboy
Link to comment
Share on other sites

--multicolored sprites can't be done? That means you can't make a colorful Pitfall Harry, but you can do a single-color Indiana Jones character?

You can do multi-colored sprites with the 0.99 versions that batari has posted in his blog, but not with version 0.35 or before. His blog is in the AtariAge blog forums.

 

--there can be only 2 sprites on the screen? How do you work around this?

Again, you can do multiple sprites with the 0.99 versions. With 0.35 and earlier, you'll need to either use multiple copies of a player (the 2600 can display up to 3 copies of each player, but they will be spaced at specific distances horizontally, and they'll be the same shape). You can also use flicker, meaning you draw a player with one shape on the first screen, then change that player's shape, color, and position for the second screen, flipping back and forth (usually on every other screen, or 30Hz flicker).

 

--what's the easiest way to animate the sprites (the player with joystick movements and enemies by themselves)?

Do you mean just moving them around, or actually changing their shapes while they're moving (or even while standing still)?

 

--how come most sample games made with Batari have line breaks in the playfield? How would you make a solid background like the mazes in "Ms. Pac-Man" or the solid castle structure in "Adventure"?

The 0.99 versions have a kernel option called "no_blank_lines" that lets you get rid of those gaps between the playfield rows.

 

--one last question...I'm a big fan of maze games...is their a tutorial on making maze games for Batari? A sorta how-to guide? Or is their any source code available I could study? Are they hard to make? Like how would you deal with the artificial intelligence of the enemies within the maze?

Version 0.99 has a playfield command that lets you define an entire playfield at once without having to draw the individual rows or columns with pfhline or pfvline as in 0.35, so that makes it easier to draw an entire maze on the screen. As far as moving around in the maze, there are two options-- using the collision detection, which means you let the player hit the wall and then have the program respond as desired (e.g., knocking the player back so he can't pass through the walls, or frying the player as in Berzerk, etc.). The other option is to check the position of the player in the maze using some other process, so that the player pixels are prevented from ever intersecting with a wall; one way to do that in batari BASIC is by using the pfread function to see if the player is about to move into a block that has the playfield pixel turned on, but that involves converting the player position into the equivalent playfield position (since the player pixels are a lot smaller than the playfield pixels, hence the player position values don't directly coincide with the playfield pixel coordinates).

 

If there's not a lot of info on maze games...then how about a game like "Berzerk"? Is that possible on Batari without adding 6502 assembly code?

It should be, but it might depend on how many sprites you're trying to display! :)

 

I'm on my way to bed right now, so I can't go into more details in any of my answers, but check out Random Terrain's web site for a good summary of the bB commands (version 0.35).

 

Michael

 

http://www.randomterrain.com/atari-2600-me...c-commands.html

Link to comment
Share on other sites

Thanks for getting back! I mean what's the best way to animate by changing their shapes while moving. when i try to go thru different source codes, it seems like there are different ways, i think. what's the best way? is there a good source code example i could use for reference? and can that same method be used for enemies? thanks again!

Edited by pacfanboy
Link to comment
Share on other sites

Thanks for getting back! I mean what's the best way to animate by changing their shapes while moving. when i try to go thru different source codes, it seems like there are different ways, i think. what's the best way? is there a good source code example i could use for reference? and can that same method be used for enemies? thanks again!

Animating the player sprites is done the same way regardless of whether the players are being moved around or not, and regardless of whether the player sprite is being used for the hero or an enemy. Basically, you just tell bB which shape to use. Keep in mind that you have to draw the screen between each change in the player's shape, otherwise the only one that will actually count will be the one that was done just before drawing the screen.

 

In other words, the following example is *BAD*-- you should *NOT* do it this way, because the only shape that will be drawn will be the last one:

 

loop

  COLUBK = $04
  COLUP0 = $1C

  player0x = 76
  player0y = 44

  player0:
  %11111111
  %01111110
  %00111100
  %00011000
  %00000000
end

  player0:
  %11000000
  %11111000
  %11111110
  %11111000
  %11000000
end

  player0:
  %00000000
  %00011000
  %00111100
  %01111110
  %11111111
end

  player0:
  %00000011
  %00011111
  %01111111
  %00011111
  %00000011
end

  drawscreen

  goto loop

On the other hand, this next example will work, but it isn't coded too well, plus the animation is too fast to see well:

 

loop

  COLUBK = $04
  COLUP0 = $1C

  player0x = 76
  player0y = 44

  player0:
  %11111111
  %01111110
  %00111100
  %00011000
  %00000000
end

  drawscreen

  COLUBK = $04
  COLUP0 = $1C

  player0x = 76
  player0y = 44

  player0:
  %11000000
  %11111000
  %11111110
  %11111000
  %11000000
end

  drawscreen

  COLUBK = $04
  COLUP0 = $1C

  player0x = 76
  player0y = 44

  player0:
  %00000000
  %00011000
  %00111100
  %01111110
  %11111111
end

  drawscreen

  COLUBK = $04
  COLUP0 = $1C

  player0x = 76
  player0y = 44

  player0:
  %00000011
  %00011111
  %01111111
  %00011111
  %00000011
end

  drawscreen

  goto loop

The problem with the preceding example (aside from the animation being too fast) is that it uses too much repetitive code, like setting the same position over and over, or calling drawscreen over and over. It's almost always best to have a single "display kernel" loop within your program, and use the drawscreen command just once in that loop, then use if statements and gosub statements to change things as needed, as well as to perform things only when actually needed. In these examples, note that the background color is always the same, and the player's position is also always the same, so we could set those things once, before we drop down into the loop. However, we *do* need to set the player color inside the loop, because drawscreen causes the player color to be "forgotten" when it draws the score at the bottom of the screen. So if we add a variable to control which shape to use for the player, we can change the code to be as follows:

 

  dim shape = a

  COLUBK = $04

  player0x = 76
  player0y = 44

  shape = 1

loop

  COLUP0 = $1C

  if shape <> 1 then goto shape_not_1

  player0:
  %11111111
  %01111110
  %00111100
  %00011000
  %00000000
end

shape_not_1

  if shape <> 2 then goto shape_not_2

  player0:
  %11000000
  %11111000
  %11111110
  %11111000
  %11000000
end

shape_not_2

  if shape <> 3 then goto shape_not_3

  player0:
  %00000000
  %00011000
  %00111100
  %01111110
  %11111111
end

shape_not_3

  if shape <> 4 then goto shape_not_4

  player0:
  %00000011
  %00011111
  %01111111
  %00011111
  %00000011
end

shape_not_4

  drawscreen

  shape = shape + 1

  if shape = 5 then shape = 1

  goto loop

But the code still isn't the best, because it uses too many goto statements, when it would be better to use gosub statements instead, as follows:

 

  dim shape = a

  COLUBK = $04

  player0x = 76
  player0y = 44

  shape = 1

loop

  COLUP0 = $1C

  if shape = 1 then gosub shape_1

  if shape = 2 then gosub shape_2

  if shape = 3 then gosub shape_3

  if shape = 4 then gosub shape_4

  drawscreen

  shape = shape + 1

  if shape = 5 then shape = 1

  goto loop

shape_1

  player0:
  %11111111
  %01111110
  %00111100
  %00011000
  %00000000
end

  return

shape_2

  player0:
  %11000000
  %11111000
  %11111110
  %11111000
  %11000000
end

  return

shape_3

  player0:
  %00000000
  %00011000
  %00111100
  %01111110
  %11111111
end

  return

shape_4

  player0:
  %00000011
  %00011111
  %01111111
  %00011111
  %00000011
end

  return

You could also replace the multiple if statements with an on statement, but the on statement uses goto instead of gosub, so you would need to change the return statements to goto statements that jump back to the next line. Also, the on statement starts with 0 instead of 1, so we should change the value of shape to go from 0 to 3, instead of from 1 to 4, as follows:

 

  dim shape = a

  COLUBK = $04

  player0x = 76
  player0y = 44

  shape = 0

loop

  COLUP0 = $1C

  on shape goto shape_0 shape_1 shape_2 shape_3

draw_screen

  drawscreen

  shape = shape + 1

  if shape = 4 then shape = 0

  goto loop

shape_0

  player0:
  %11111111
  %01111110
  %00111100
  %00011000
  %00000000
end

  goto draw_screen

shape_1

  player0:
  %11000000
  %11111000
  %11111110
  %11111000
  %11000000
end

  goto draw_screen

shape_2

  player0:
  %00000000
  %00011000
  %00111100
  %01111110
  %11111111
end

  goto draw_screen

shape_3

  player0:
  %00000011
  %00011111
  %01111111
  %00011111
  %00000011
end

  goto draw_screen

Finally, the animation is still too fast. To slow it down, you just need to add another variable to count the frames, and then update the shape variable only after a certain number of frames have been drawn, as follows:

 

  dim shape = a

  dim frame = b

  const speed = 30

  COLUBK = $04

  player0x = 76
  player0y = 44

  shape = 0

  frame = 0

loop

  COLUP0 = $1C

  on shape goto shape_0 shape_1 shape_2 shape_3

draw_screen

  drawscreen

  frame = frame + 1

  if frame = speed then frame = 0 : shape = shape + 1

  if shape = 4 then shape = 0

  goto loop

shape_0

  player0:
  %11111111
  %01111110
  %00111100
  %00011000
  %00000000
end

  goto draw_screen

shape_1

  player0:
  %11000000
  %11111000
  %11111110
  %11111000
  %11000000
end

  goto draw_screen

shape_2

  player0:
  %00000000
  %00011000
  %00111100
  %01111110
  %11111111
end

  goto draw_screen

shape_3

  player0:
  %00000011
  %00011111
  %01111111
  %00011111
  %00000011
end

  goto draw_screen

In this last example, I also defined a constant called speed, because that makes it easier for us to change the speed if we want, by changing the value of the constant at the top of the program, rather than having to hunt through the code and find all the places where we need to change it. However, note that we can't change it while the program is running, since it's a constant instead of a variable. So if you want to be able to change the speed *during* the program, make speed a variable.

 

The only other thing you need to worry about is controlling whether to make the shape change or stay the same. For example, if you draw a man, you might want him to stand still if he is not being moved around, but pump his legs if he is being moved around. I'll post some examples of that later, but in the meantime you could look at the code for my unfinished Reventure game, which is in this forum (although I probably wouldn't code it the same way now).

 

Michael

Link to comment
Share on other sites

This is great stuff! thanks so much! i'm playing around with this source code, trying to implement joystick controls to move & animate the character, though i'm not too sure what to do :) . i'm also looking through your reventure code (which, by the way, is an awesome game), so that should help big time.

Edited by pacfanboy
Link to comment
Share on other sites

This is great stuff! thanks so much! i'm playing around with this source code, trying to implement joystick controls to move & animate the character, though i'm not too sure what to do :) . i'm also looking through your reventure code (which, by the way, is an awesome game), so that should help big time.

Thank you for the kind words about Reventure, which still has a long way to go. I hope to resume work on it eventually, although I'll probably start by doing a major rewrite of the existing code.

 

Right now I'm busting my ass trying to finish up a major project, which is why I haven't been able to post any other animation and movement examples for you yet. I'll see what I can do later this week.

 

Michael

Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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