Jump to content
IGNORED

Game Idea: bobobo bobobobobo


Tombor

Recommended Posts

Hi. I'm new to the forums... sort of a long time reader first time poster.

 

A friend of mine and I are sort of in the planning stages of an attempt at an Atari 2600/VCS game but we need some help and/or suggestions if possible.

 

Our idea is a bit bizarre... sort of. We're basing the game on a Japanese Manga called bobobo bobobobobo. The manga stars the title character who sports a giant afro and whips around nose hairs to fight the "baldness empire" (an example can be found at http://groups.msn.com/RasterDisplay/bobobobobo.msnw).

 

The premise of our game is much like that of the manga: Bobobo defends all that is right and good by using his powerful nosehairs to thwart villainy.

 

Our game document is incredibly simple (we think): bobobo stands stationary in the middle of the screen and each of two players controls one of his nosehairs with the paddle controller. Movement would be limited to 180 degrees for both players and the object of the game is to work together to fight off hordes of mindless enemies. Holding the fire button would extend the nosehairs (my friend suggested a sort of "timing" thing that would allow the nosehairs to extend further the longer you hold the fire button while swinging away). We debated also having a certain point in play were the enemies bumrush in a large full screen horde ala Robotron. Or something.

 

I've been reading up on 6502 assembly (working at a library helps a lot when it comes to old computer books...) and I've been following Andrew Davie's SUPERB tutorial (I had no idea what I was doing until I started following them), but we're both still encountering issues.

 

Is there a way we can find source code for games that used the paddles? Warlords trickles to mind as it used 4 players.

 

With the paddles being to to a port and the VCS limited to 2 players on screen, is it feasible to have both nosehairs declared as one player sprite and have them function independently? I thought since character movement would be limited to 180 degrees on both I thought there might be a way to sort of have both nosehairs as one player and "split" the movement. An example being player one can move 180 degrees on the left side while player two moves 180 degrees on the right. Or do you have to have both function as sperate players?

 

Are there any tutorials or source code that'll allow you to "cheat" and produce multiple sprites on screen? Our "enemy AI" would consist of just hordes running at the stationary bobobo and the nosehairs. Is there a way we can declare ALL the enemies as just one player sprite or missile or ball graphic but have the enemies move randomly on the screen?

 

I'm still working through the tutorials so I may actually encounter some of these answers but if anybody is willing to give me and my friend any suggestions and opinions we'll gladly take it all in.

 

Sorry if I sound a bit confusing. I'm new to all this.

Link to comment
Share on other sites

You've only got two player sprites to work with when programming for the Atari 2600. Each player sprite is independent, 8-bits wide, and as tall as you want to make it (up to the limit of the screen height of 192 scanlines). Eight bits doesn't give you much room to make your sprites very wide, but there are tricks you can pull to stretch them out. By writing certain values to the NUSIZ0 and NUSIZ1 registers, you can horizontally stretch your sprites to double-size (16 color clocks) or even quadruple-size (32 color clocks), however you are still limited to 8-bit resolution per sprite. The same two registers may also be set up to generate 1, 2 or three copies of each player sprite. So if you're crafty with your coding, you can have as many as 6 movable sprites onscreen at a time.

 

If you want more sprites than six, you can double the figure to 12, but you'll have to display your per-screen limit of 6 on all odd numbered frames and then update them and re-display the 6 sprites on the even numbered frames. The disadvantage to displaying sprites on alternating frames is you subject the player to flicker. You could even go nuts by displaying 18 sprites on three different frames, but the flicker it induces might throw your prospective players into fits of epilepsy.

 

You also get two missiles and a ball, but they are only a single bit wide. So all you can really draw with each of them are solid vertical lines or fragmented vertical lines. Writes to the NUSIZ registers permit you to draw fat vertical lines and fat fragmented vertical lines with the missiles and the ball.

 

Scrounge around on the web for Steve Wright's Stella Programmer's Guide for more details about sprites and what can be done with them. After giving that document a thorough read, I'm sure you'll be eager to come back here with plenty of follow-on questions.

 

Also, Look on the web for the source code for Joe Grand's SCSIcide for an example of a game that uses the paddle controllers.

 

A Nose hair warrior? I can't wait.

 

Ben

Link to comment
Share on other sites

You've only got two player sprites to work with when programming for the Atari 2600.  Each player sprite is independent, 8-bits wide, and as tall as you want to make it (up to the limit of the screen height of 192 scanlines).  Eight bits doesn't give you much room to make your sprites very wide, but there are tricks you can pull to stretch them out.  By writing certain values to the NUSIZ0 and NUSIZ1 registers, you can horizontally stretch your sprites to double-size (16 color clocks) or even quadruple-size (32 color clocks), however you are still limited to 8-bit resolution per sprite.  The same two registers may also be set up to generate 1, 2 or three copies of each player sprite.  So if you're crafty with your coding, you can have as many as 6 movable sprites onscreen at a time.  

 

If you want more sprites than six, you can double the figure to 12, but you'll have to display your per-screen limit of 6 on all odd numbered frames and then update them and re-display the 6 sprites on the even numbered frames.  The disadvantage to displaying sprites on alternating frames is you subject the player to flicker.  You could even go nuts by displaying 18 sprites on three different frames, but the flicker it induces might throw your prospective players into fits of epilepsy.

 

The PS2 Bobobo game was pretty epilepsy-rrifc so I may actually want to take a chance on that... maybe.

 

I can SORT of understand what you're talking about... I'm a newbie at this, I'm just glad I got the thing to compile Andrew's kernal, but I think I got an idea general idea of how to program this.

 

 

NUSIZ0 (NUSIZ1)

These addresses control the number and size of players and

missiles.

 

Missile Size D5 D4 Width

0 0 1 clock

0 1 2 clocks

1 0 4 clocks

1 1 8 clocks

 

Player-Missile number & player size

 

1/2 television line (80 clocks)

8 clocks per square

 

 

Earlier in the guide it says you can effect the size and number of copies by writing to the D0, D1, and D2 registers. I'm about to sounding stupid but were are those? Can I just write a number that would correspond with whatever size I want into the size register? Like if I want the nose hair or the "baldness Empire" thugs to be 8 pixels high could I write an 8? That was actually pretty moronic what I just said there I think....

 

If I were to write to that to make multiple sprites do I have to worry about other factors like horizontal or vertical postioning and the kernal and all that jazz?

 

On another note, I think, is there a way I can get the playfield to display in more then one color? From what I gather in the stella guide the Playfield is limited to one color.

Link to comment
Share on other sites

Earlier in the guide it says you can effect the size and number of copies by writing to the D0, D1, and D2 registers.  I'm about to sounding stupid but were are those?  Can I just write a number that would correspond with whatever size I want into the size register?  Like if I want the nose hair or the "baldness Empire" thugs to be 8 pixels high could I write an 8?  That was actually pretty moronic what I just said there I think....

 

D0, D1 and D2 are not registers. They identify the bits within a [any] register. All of the registers inside the 2600 CPU are 8 bit registers, and therefore each has bits identified as D0, D1, D2...D7, where D0 is the low order bit and D7 is the high order bit. Therefore, you may affect the size and number of copies of the Player One Sprite by setting the lower three bits (D0, D1 and D2) of the NUSIZ0 register. Three bits worth of control gives you a total of 8 different possibilites to chose from, which are detailed in the appendix of the Stella Programmer's Guide.

 

You set up the horizontal shape of a sprite by writing a bit pattern to the GRP0 (player one) or to the GRP1 (player two) register. The height of the sprite all depends on how many scanlines you chose to leave your designed bit pattern in your player graphic register. Also, you should be aware there is nothing to stop you from changing the horizontal bit pattern you set in your player sprite register (GRP0 or GRP1), a fact which permits you to draw sprites that are not of constant shape throughout their entire length.

 

If I were to write to that to make multiple sprites do I have to worry about other factors like horizontal or vertical postioning and the kernal and all that jazz?

 

Oh, yeah. And "all that jazz" covers quite a lot of territory.

 

On another note, I think, is there a way I can get the playfield to display in more then one color?  From what I gather in the stella guide the Playfield is limited to one color.

 

It is, but you can easily change that "one color" every scan line. You can even change it a few times in the middle of a scanline, but you really have to get into cycle counting to pull it off.

 

Think of the TIA as a firehose loaded with two ink cartridges, one for the background and one for the playfield. The firehose sprays color onto the inside of your TV screen, sweeping from left to right (as you see it) to paint a playfield and it's background, one scanline at a time. The 1's in the bit patterns you set in the Playfield registers instructs the firehose to paint those length segments of the scanline with the "playfield color" ink color and the 0's tell it where it should paint the remaining scanline lengths with the background ink color. You can swap out either or both color ink cartridges at any time, be it at the end of a scanline of anywhere in the middle, by writing a color code to the COLUBK register (background) or to the COLUPF register (playfield). The stuff the firehose painted at the top of the screen before the ink cartridges got swapped out does not change until the screen is finished painting all the scanlines and then goes to the top of the screen to repaint it again with whatever color ink cartridge you've programmed into the color registers when it gets there.

 

 

Ben

Link to comment
Share on other sites

What you could do, though it might be a little tricky, is to have Bobobo in the center of the screen, and the enemies coming down from the top and bottom. How does that help? You can then have the nose hairs as a ball sprite, and shifting it over by a pixel or two every scanline. That would give you a larger hair than what you could do simply with a sprite, as it could be a larger width. As long as the nose hairs don't make more than a +45 degree angle, a direct diagonal line, than you would have one pixel per line, which is the most you can do without complicating things.

 

I attached a crudely drawn example, which could give you an idea of what this would look like. I don't have a clue of what Bobobo and the enemies look like exactly, so it's not the best example you could think of, but it shows exactly how the ball method works. Also, you can have up many enemies on the top and bottom, as long as there aren't two of the same sprite on any line.

 

Green = Background

Red = Player 0

Dark Green = Player 1

Blue = Ball

post-3091-1056649178_thumb.png

Link to comment
Share on other sites

That's actually a great pic! It looks just about what me and my friend have been sketching out the last week or so.

 

Would it still be possible to have two players control each nosehair if this is done with just one ball sprite? Also are the enemies their own sprites or is this a sort of example of what Pitfall Harry was talking of... writing to the registers to create copies multiple copies of one sprite?

Link to comment
Share on other sites

The limitation is 3 copies of a player sprite per horizontal scan line. Since there are two players, this means you can have 6 copies total (3 copies of each player sprite) per scanline.

 

The interesting thing about player sprites is that they are really one-dimensional objects. That is, you specify a value in the 8-bit GRPO (Player 1) or GRP1 (Player 2) register to give a sprite it's "horizontal shape." The number of scanlines you decide to display it is what gives a sprite it's second dimension, height.

 

For example:

 

A value of 10101010 in GRP0 defines a Player 1 sprite whose pattern is a set of four separate "dots" on your screen, which is exactly what you will see if you display it for only one scanline.

 

___________X_X_X_X________________

 

 

If you display the sprite for 8 scanlines, the pattern will trace out a rectangle with alternating stripes of background and whatever color you specify for the Player 1 sprite (in the COLUP0 register).

 

 

___________X_X_X_X________________

___________X_X_X_X________________

___________X_X_X_X________________

___________X_X_X_X________________

___________X_X_X_X________________

___________X_X_X_X________________

___________X_X_X_X________________

___________X_X_X_X________________

 

 

But you can change the pattern of your one-dimensional sprite after every single scanline. That's really handy if you want to draw more

interesting objects than vertical lines. Here's an example:

 

Put 11111111 into GRPO on scanline #1

Put 01111110 into GRPO on scanline #2

Put 00111100 into GRPO on scanline #3

Put 00011000 into GRPO on scanline #4

 

This will make a nifty little triangle on your screen like this:

 

 

___________XXXXXXXX________________

____________XXXXXX_________________

_____________XXXX__________________

______________XX____________________

 

 

In reality, what you've done is drawn four consecutive, different one-dimensional sprites -- all of them painted to the screen via the Player 1 sprite. But in your mind, you've always thought of the collection of four one-dimensional sprites as a single two-dimensional sprite in the shape of a little triangle.

 

You can make up to three copies of the four components of your triangle sprite, all on the same four sets of horizontal scanlines, with a single write of the appropriate value to the NUSIZ0 register.

 

And there is nothing to prevent you from doing it all again on the next four set of scanlines. So if you were so inclined, you could draw 48 rows of your four-line triangle sprites, each of them copied in triplicate, for a total of 144 triangles onscreen at the same time, using only the Player 1 sprite. You could draw twice that number if you do the same thing with the Player 2 sprite.

 

The two player missiles and the ball are like the two player sprites, except that the 8-bit pattern you have to define a sprite is shrunk to a single bit to define the shape of a missile or a ball. So all you can really draw with the missiles and the ball are lines or segmented lines.

 

Ben

Link to comment
Share on other sites

Hi there!

 

I attached a crudely drawn example, which could give you an idea of what this would look like. I don't have a clue of what Bobobo and the enemies look like exactly, so it's not the best example you could think of, but it shows exactly how the ball method works. Also, you can have up many enemies on the top and bottom, as long as there aren't two of the same sprite on any line.

 

This is a very good, doable and proven (Asteroids!) concept.

 

I was spending thought's on doing a Gunfight sequel based on this technique, as there was this nice western Flash game here doing something like that:

 

http://www.game-america.de/cgi-bin/loadsit...it.html&ldir=us

(Click on the "Flash Game" Link on the bottom of the left frame)

 

Greetings,

Manuel

Link to comment
Share on other sites

I feel stupid asking these questions but...

 

If I have the enemies be player sprites can I have the players control the ball sprite?

 

I think I figured out what I meant myself when I said "all that Jazz" Pitfall Harry... you talk about having copies of sprites skipping scanlines to create 6 moveable sprites onscreen... would I only be worrying about the 192 scanlines that make the TV screen? Or would I have to change the scanlines that control vertical blank and overscan and horizontal scanning? I hope I just made sense.

 

I really appreciate everybody helping me... I think I've learned more about the 2600 and programming and game design the last week or so with these forums then I've known my entire life... which wouldn't be much before all this actually.

Link to comment
Share on other sites

If I have the enemies be player sprites can I have the players control the ball sprite?

 

Sprites, missiles and the ball are not tied to the game ports in any way. You, the programmer, have complete control over how each of the movable graphics respond to the signals a joystick wielding human player (or two) feeds into the Atari via the game ports. Your game code will have to check the status of the game ports at least once every video frame, and based on these signals, your code will have to branch to an appropriate subroutine to handle the sprite/missile/ball updates demanded by the input signals and your personal vision of the game action. Either or both human players can control any or all of the movable graphics. It's all up to you.

 

you talk about having copies of sprites skipping scanlines to create 6 moveable sprites onscreen... would I only be worrying about the 192 scanlines that make the TV screen?

 

If you want 6 movable sprites per scanline without resorting to alternating frames (and the accompanying flicker), then you will have to employ both Player Sprites and set the NUSIZ0 and NUSIZ1 registers to give you 3 copies of each player sprite. However, that limitation applies only when your sprites occupy the same set of horizontal scanlines. There are 192 visible scanlines per video frame. So if your sprites are only 4 scanlines tall, you can draw them on the screen as many as 192/4 = 48 times per TV screen! And yes, you can animate them over a series of frames, so long as the sprites of one row do not overlap the sprites in the row above or below. In the example of 48 rows of 4-scanline-high sprites, you'd be limited to moving your sprites only side-to-side, so as not to have them overlap vertically.

 

If you wanted to have 12 movable sprites, all occupying the same set of scanlines, then you'd have to write 6 of them to one TV frame, and 6 to another TV frame. Then you'd have to update and move the sprites on each alternating TV frame independantly. And you'd get flicker. But if you gotta have 12, then you gotta have the flicker.

 

 Or would I have to change the scanlines that control vertical blank and overscan and horizontal scanning?  I hope I just made sense.

 

No, that really doesn't make a lot of sense to me. Sorry.

 

I really appreciate everybody helping me... I think I've learned more about the 2600 and programming and game design the last week or so with these forums then I've known my entire life... which wouldn't be much before all this actually.

 

Cool!

 

 

Ben

Link to comment
Share on other sites

If I have the enemies be player sprites can I have the players control the ball sprite?

Absolutely...the player moves the "ball" sprite around in Adventure, and the "players" are used to make all the other movable objects in the game. You could also have the player control background pixels if you wanted (as in Surround...though that one uses an object for the"heads" of the opposing trails).

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...