bB standard kernal question

[+cvga]

I've been introducing myself to batari basic over the weekend. I've created some sprites and have been moving them around in the standard kernal. From what I understand, I can have two sprites, two missiles and one ball. I can also define the playfield. I've seen and understand the examples that use these. I've also seen and have created a couple of examples that use multiple sprites by reusing player0 and player1. Each time I use a drawscreen, I grab a different version of player0 and/or player1. However, my sprites flicker pretty badly. If I'm using the standard kernal, am I limited to one instance of player0 and player1 each time I execute a drawscreen?

[lord_mike]

Yep. Pretty much! in the standard kernel, there is no way around the limitation besides flickering.

[SeaGtGruff]

If I'm using the standard kernal, am I limited to one instance of player0 and player1 each time I execute a drawscreen?

Yes, but you can still draw multiple sprites with them.

 

For example, if you set player0 to 3 copies, and set player1 to 3 copies, then you can get 6 sprites on the screen at once without flicker-- but all 3 copies of player0 will move in sync with each other (and would be the same color as each other), and all 3 copies of player1 will move in sync (and be the same color). Still, you could use a playfield pixel as the "hero," and shoot the ball at 6 attacking enemies-- 3 moving in one formation, and the other 3 moving in another formation. Then, when you hit one, you can change the number of copies, and adjust their spacing if necessary, to remove the enemy that you hit.

 

Also, you can draw two or more shapes with one player if you stack them in a column, with blank lines between them-- the same way that some programmers make a vertical "game over" message with the two players. The shapes would have to move side-to-side as one column, but they could move up-and-down independently if you redefine the column of shapes with different numbers of blank lines between the shapes. And if the shapes are less than 8 pixels wide-- say, 4 or 5 pixels wide-- then you could keep redefining the column of shapes so they appear to move side-to-side a little bit independently, by shifting each shape left or right independently within the 8-pixel column. If you use the multicolored players options, you could even draw each shape with a different color.

 

Michael

[Fort Apocalypse]

Something else to think about is that on older t.v.'s (not sure what happens with plasma and lcd t.v.'s though) the phosphor continues to emit light a little after the scan is over. In Stella you can emulate that phosphor effect with alt-P. That is helpful if you want to take screenshots in Stella when there's flicker. I didn't know that option was there until a kind soul showed me.

Edited January 23, 2008 by Fort Apocalypse

[+cvga]

Thanks for the replies. I've been reading many of the posts regarding bB and can't express enough how helpful it has been to read the questions and answers that are given!

[+cvga]

Also, you can draw two or more shapes with one player if you stack them in a column, with blank lines between them-- the same way that some programmers make a vertical "game over" message with the two players.

 

That makes sense. I didn't think about creating more than one character with one player like this. I tried this out and I'm definitely closer to where I want to be. Suppose I wanted to make one of those 'jump the peg' triangular games (like you might see at Cracker Barrel restaurants). I could have a total of 15 pegs (actually 14 since you start with one empty hole) in 5 rows (or columns if you turn it sideways). My screen would look like one of the following...

 

x_x_x_x_x

_x_x_x_x

__x_x_x

___x_x

____x

 

or (it's probably better to imagine the picture above turned sideways)

____x

___x

__x_x

_x_x

x_x_x

_x_x

__x_x

___x

____x

 

Initially I thought I would have to create a player0 that looks like a peg and a player1 that looks like a peg and rotate them through 8 drawscreens to get all of the pegs on the screen but that creates an extreme flickery mess.

 

Turning the board sideways reduces the number of columns to 5. Now I can use the two sprites as columns of pegs and cut my drawscreens down to 3 to show the whole board (although it's still flickery).

 

Is there a better way using batari basic with less flicker to accomplish what I want?

 

Also, I was playing with the ball graphic but I was disappointed that it looks like a square. Is there a way to make it look more rounded like an actual ball?

Edited January 23, 2008 by cvga

[SeaGtGruff]

Suppose I wanted to make one of those 'jump the peg' triangular games (like you might see at Cracker Barrel restaurants). I could have a total of 15 pegs (actually 14 since you start with one empty hole) in 5 rows (or columns if you turn it sideways). My screen would look like one of the following...

 

x_x_x_x_x

_x_x_x_x

__x_x_x

___x_x

____x

 

or (it's probably better to imagine the picture above turned sideways)

____x

___x

__x_x

_x_x

x_x_x

_x_x

__x_x

___x

____x

 

Initially I thought I would have to create a player0 that looks like a peg and a player1 that looks like a peg and rotate them through 8 drawscreens to get all of the pegs on the screen but that creates an extreme flickery mess.

 

Turning the board sideways reduces the number of columns to 5. Now I can use the two sprites as columns of pegs and cut my drawscreens down to 3 to show the whole board (although it's still flickery).

 

Is there a better way using batari basic with less flicker to accomplish what I want?

Actually, if you use the largest player size (quadruple wide), and the next-to-the-largest missile size (also quadruple wide), you could draw all 15 peg positions with just one player and one missile. Then you could use the other player as a cursor for pointing to which peg you want to move, and blink (or slow flicker) the other missile between two positions to mark which peg you've selected to move, and which position you've chosen to move it to. You could use the playfield to draw the triangular board (although it would be blocky looking), with "holes" in the playfield to let the background through.

 

I'm attaching a very preliminary display to show you what I mean, but it just has the 15 pegs showing (yes, I know that's 1 more than there should be).

 

Also, I was playing with the ball graphic but I was disappointed that it looks like a square. Is there a way to make it look more rounded like an actual ball?

The only ways to make the ball look rounded like a ball is to (1) vary its width and horizontal position from line to line-- which you can't do in batari Basic unless you write a custom kernel-- or (2) vary its width and height and position between two frames using flicker, which you *can* do in batari Basic. But you might want to just use square pegs, as I've done in my little demo program. For a game like this, the shape of the pegs is secondary to the game play, so square pegs should be perfectly acceptable.

 

By the way, the challenge with using just one player for all of the pegs is to be able to turn the pixels on and off as needed, which would require either defining a lot of player shapes for all of the possible peg arrangements-- which would take up a good bit of ROM-- or move the player shape into RAM so you could alter it on the fly. For the shape I drew in my demo, it would take 36 bytes of RAM, and you don't really have 36 bytes of RAM free in batari Basic, unless you use the Superchip option. However, one possibility is to create a modified version of the kernel that draws each line of player1 four times before moving on to the next line, so you could define the player shape using only 9 bytes instead of 36 bytes, and then you would need only 9 bytes of RAM to turn the pegs or pixels on and off as needed.

 

There are other possibilities, though. For example, it's easier to turn the playfield pixels on and off in the standard kernel. So if you use the playfield as the holes in the board, and use the background as the board itself, and then set the playfield control register (CTRLPF) so that the players are drawn *behind* the playfield, then you could just leave the player1 bits on all the time, and turn the playfield pixels on or off as needed to make it look like the pegs are turning on or off (moving).

 

Another possibility would be to just write a custom kernel, since one of the players will be motionless anyway (for all of the pegs), and only the other player would need to move around (for the cursor)-- plus, the cursor would really have only a set number of possible positions. So with a custom kernel, you could draw multiple copies of player1 from row to row for the pegs, because the most pegs you would have on any row would be 3, as follows:

 

						P1A

			  P1A

		P1A		 P1B

  P1A		 P1B

P1A		 P1B		 P1C

  P1A		 P1B

		P1A		 P1B

			  P1A

					P1A

Turning the pegs on or off would then be a simple matter of just changing the number of copies, spacing, and horizontal position on each row of pegs.

 

Actually, you could do pretty much the same thing without creating a custom kernel, by using the multisprite kernel, but you'd need to flicker the multisprites, since there are 9 rows on which pegs could appear, and you don't have that many multisprites.

 

Michael

 

jump_the_peg.bas

jump_the_peg.bas.bin

Edited January 23, 2008 by SeaGtGruff

[+cvga]

Thanks again for the response. I really appreciate all of the time you spend providing answers!

[Erik Zimmermann]

jump_the_peg ist great! thanks.

 

idea for a new bowling