Jump to content

Recommended Posts

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

Link to comment
https://forums.atariage.com/topic/99023-lives-counter/
Share on other sites

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

Link to comment
https://forums.atariage.com/topic/99023-lives-counter/#findComment-1199936
Share on other sites

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.

Link to comment
https://forums.atariage.com/topic/99023-lives-counter/#findComment-1200137
Share on other sites

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 by batari
Link to comment
https://forums.atariage.com/topic/99023-lives-counter/#findComment-1200158
Share on other sites

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 by vdub_bobby
Link to comment
https://forums.atariage.com/topic/99023-lives-counter/#findComment-1200166
Share on other sites

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

Link to comment
https://forums.atariage.com/topic/99023-lives-counter/#findComment-1200173
Share on other sites

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

Link to comment
https://forums.atariage.com/topic/99023-lives-counter/#findComment-1200179
Share on other sites

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

Link to comment
https://forums.atariage.com/topic/99023-lives-counter/#findComment-1200194
Share on other sites

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

Link to comment
https://forums.atariage.com/topic/99023-lives-counter/#findComment-1200349
Share on other sites

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 by batari
Link to comment
https://forums.atariage.com/topic/99023-lives-counter/#findComment-1200613
Share on other sites

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.

Link to comment
https://forums.atariage.com/topic/99023-lives-counter/#findComment-1200947
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...