lives counter

[+batari]

This is one optional feature I want to add - a lives counter above the score. I am posting because I want some opinions on this.

 

It is easy to allow up to 6 lives (or ships in the demo). With some effort you can do 7 with goofy TIA tricks, but as I discovered, it's hard to make it look nice if you want to keep the code somewhat compact. As you can see from the demo, the ships kind of shift around a little.

 

So would you prefer a nice-looking 6, or a quirky 7?

 

Demos attached.

ships.zip

[SeaGtGruff]

This is one optional feature I want to add - a lives counter above the score. I am posting because I want some opinions on this.

 

It is easy to allow up to 6 lives (or ships in the demo). With some effort you can do 7 with goofy TIA tricks, but as I discovered, it's hard to make it look nice if you want to keep the code somewhat compact. As you can see from the demo, the ships kind of shift around a little.

 

So would you prefer a nice-looking 6, or a quirky 7?

 

Demos attached.

I think 6 is probably enough (it's what most games have, anyway), but maybe you could allow a kernel option for choosing either 6 or 7? And if you used blocks instead of shapes, you should be able to get 7 easy with three copies of both missiles, plus the ball-- or more than 7 if you just use playfield blocks (as was done in Millipede).

 

Michael

[MausBoy]

I think 6 is definately plenty, and what I'm wondering is if a game only allows 3 lives, can you decide if they are centered or to the right/left. Also, does it take away any playfield lines?

 

I like to use the playfield line 11 to create three lives dots to the left and a centered healthbar over the score, but that just takes way to many cycles, especially in a horizontally scrolling game; so this would be great, as long as it can be shifted all the way left to still allow room for the healthbar over the score.

[+batari]

This is one optional feature I want to add - a lives counter above the score. I am posting because I want some opinions on this.

 

It is easy to allow up to 6 lives (or ships in the demo). With some effort you can do 7 with goofy TIA tricks, but as I discovered, it's hard to make it look nice if you want to keep the code somewhat compact. As you can see from the demo, the ships kind of shift around a little.

 

So would you prefer a nice-looking 6, or a quirky 7?

 

Demos attached.

I think 6 is probably enough (it's what most games have, anyway), but maybe you could allow a kernel option for choosing either 6 or 7? And if you used blocks instead of shapes, you should be able to get 7 easy with three copies of both missiles, plus the ball-- or more than 7 if you just use playfield blocks (as was done in Millipede).

 

Michael

I prefer 6 as well, but yeah, it's no problem to allow both as options.

 

In fact, the space between the visible screen and the score can have other purposes. What I'm going to do is make it somewhat simpler to insert one's own mini-kernel into this space, and over time, maybe mini-kernel modules will be created that can be seamlessly included, such as a status bar, timer, bonus counter, radar screen, etc. Well, maybe not a radar screen unless someone can suggest an easy, nearly RAM-less way to do it.

 

While the minikernels do not take anything away from the regular bB screen, of course nothing's free - Putting in a mini-kernel will make the total visible screen larger, which also means that you have less time for bB code per frame. But you can use as few or as many scanlines in the mini-kernel as you wish (within reason, of course), as the interval timer will be started just before it.

I think 6 is definately plenty, and what I'm wondering is if a game only allows 3 lives, can you decide if they are centered or to the right/left. Also, does it take away any playfield lines?

 

I like to use the playfield line 11 to create three lives dots to the left and a centered healthbar over the score, but that just takes way to many cycles, especially in a horizontally scrolling game; so this would be great, as long as it can be shifted all the way left to still allow room for the healthbar over the score.

A 3-life mini kernel could easily be hacked out of this one.

 

There might also be time for lives and a simple health bar side-by-side - I'll have to look into it.

Edited December 20, 2006 by batari

[vdub_bobby]

Of the two demos posted, I like the 6-life demo better.

 

How hard would it be to make it the same width as the score, though? You'd have to use the 6-digit score routine.

 

That would restrict you to using a life icon that was 7-pixels wide (or less) but I think it would look much cleaner; more integrated.

 

And a RAM-less radar...hmmmm. Sounds like an interesting challenge...

Edited December 20, 2006 by vdub_bobby

[+batari]

Of the two demos posted, I like the 6-life demo better.

 

How hard would it be to make it the same width as the score, though? You'd have to use the 6-digit score routine.

Would be easy - and you wouldn't need to use the 6-digit score routine as long as the players were positioned correctly.

That would restrict you to using a life icon that was 7-pixels wide (or less) but I think it would look much cleaner; more integrated.

It shouldn't be a big deal to write a bunch of different mini-kernels for all sorts of different purposes.

And a RAM-less radar...hmmmm. Sounds like an interesting challenge...

Well, it's not totally RAM-less - There are 4 bytes set aside for future expansion, so you could use those to pass data to the kernel from bB, and temp1-temp6 are all available as temporary RAM. But that's clearly not enough for a bitmap...

 

Also, for practicality, I'd say that kernels should be limited to around 10 scanlines, or they might push the score off of the visible screen, (unless you want to bypass the score, which is also possible.)

[vdub_bobby]

And a RAM-less radar...hmmmm. Sounds like an interesting challenge...

Well, it's not totally RAM-less - There are 4 bytes set aside for future expansion, so you could use those to pass data to the kernel from bB, and temp1-temp6 are all available as temporary RAM. But that's clearly not enough for a bitmap...

 

Also, for practicality, I'd say that kernels should be limited to around 10 scanlines, or they might push the score off of the visible screen, (unless you want to bypass the score, which is also possible.)

It wouldn't be hard to do a radar with 5 objects on it; just use P0, P1, M0, M1, and the BL as dots. Assuming that there are variables holding X & Y values for each of those objects you'd just have to translate those values to the radar width/height.

 

Main problem would be positioning all five objects - that would kill a lot of screen space; at least 5-6 lines and probably more.

 

For more than 5 objects you could (a) flicker or (b) try to generate a bitmap on the fly. Which seems like it would be difficult.

[+batari]

And a RAM-less radar...hmmmm. Sounds like an interesting challenge...

Well, it's not totally RAM-less - There are 4 bytes set aside for future expansion, so you could use those to pass data to the kernel from bB, and temp1-temp6 are all available as temporary RAM. But that's clearly not enough for a bitmap...

 

Also, for practicality, I'd say that kernels should be limited to around 10 scanlines, or they might push the score off of the visible screen, (unless you want to bypass the score, which is also possible.)

It wouldn't be hard to do a radar with 5 objects on it; just use P0, P1, M0, M1, and the BL as dots. Assuming that there are variables holding X & Y values for each of those objects you'd just have to translate those values to the radar width/height.

 

Main problem would be positioning all five objects - that would kill a lot of screen space; at least 5-6 lines and probably more.

Not if the radar screen is fairly narrow.

 

In the first scanline, set SP=$11 and JSR to the next instruction, which hits RESP0 and RESP1 one cycle apart at a fixed position. Then hit RESMP0 and RESMP1 to put the missiles on top of their respective players. then two cycle-73 HMOVEs to shift the objects. Two scanlines, and you could place any objects you need on a radar screen 27 pixels wide.

 

Adding the ball would limit this to around 18, but another scanline would bump that up to 33 (or 42 without the ball, if my calculations are correct.)

[+atari2600land]

I like the 6 one better. I'm also glad to see you're back to working on a new release of Batari Basic! Just wondering, what is the code for that (I know I can't do it on a release I have, I'm just curious.)

[+batari]

I like the 6 one better. I'm also glad to see you're back to working on a new release of Batari Basic! Just wondering, what is the code for that (I know I can't do it on a release I have, I'm just curious.)

Here's the code:

minikernel; display up to 6 lives on screen
; enter on cycle 10
 lda #0
 ldy #7
 sta VDELP0
 sta VDELP1
 lda.w lives
 lsr
 lsr
 lsr
 lsr
 sta RESP0
 lsr
 tax
 sta RESP1
 lda lifenusiz0table,x
 sta NUSIZ0
 lda lifenusiz1table,x
 sta NUSIZ1
 lda lifecolor
 sta COLUP0
 sta COLUP1
 lda #$b0
 sta HMP0
 sta HMOVE				   

lifeloop
 sta WSYNC
 cpx #0
 beq skipall
 lda (lifepointer),y
 sta GRP0
 cpx #1
 beq skipall
 sta GRP1
skipall
 dey
 bpl lifeloop
 sta WSYNC
 iny
 sty GRP0
 sty GRP1
 rts

 if (<*) > $F5
 align 256
 endif
lifenusiz1table
 .byte 0
lifenusiz0table
 .byte 0,0,0,2,2,6,6,6

Edited December 21, 2006 by batari

[+atari2600land]

I meant the code you'd use in the latest version of Batari BASIC to get the lives counter to show up.

[+batari]

I meant the code you'd use in the latest version of Batari BASIC to get the lives counter to show up.

You just use "include 6lives.asm" for a 4k game. Optionally, or for a bankswitched game, you need to use the new command "inline_include" which will give you control over where the code goes (i.e. in a bankswtiched game, you need to place it in the last bank.) Or a custom includesfile will work as well.

 

Usage is like defining a player sprite, except the keyword is "lives:".

 

You also have a variable lifecolor to define the color.

 

The only difficulty is that in order to save a variable, I used the upper 3 bits if the graphic pointer to define the number of lives. It's not hard to work with - for example to subtract a life you do "lives=lives-32" and to check for zero lives, "if lives<32 then ..." will suffice. But I will provide examples or maybe a function to help deal with this.

[MausBoy]

Looks/sounds great to me, can't wait to give it a try! I think the most useful combination will be a healthbar/lives counter combo.