New Homebrew - Kick Ice

[DaveM]

I've started work on a new game called "Kick Ice", and I'm having a few problems with HMOVE.

 

I decided to start with the scoreboard.  It's a 2-player co-op game, so I wanted to display two scoreboards at the bottom of the screen.  I'm using the 8-bit Workshop tool to write the code, and when using its emulator, everything works perfectly.  That's the first screenshot, below.  I'm using the PF1 and Ball objects for my timer bars.  The background is white, so I'm cutting a hole in the red playfield to let the white background show through.  Then I'm covering up the right side of the bar with the ball so it counts down nice and smooth.  I'm also using HMOVE to create the vertical line of black at the left side of the screen, although in the code, you'll notice I have an HMOVE commented out at line 209, since putting that one in there caused issues with the timing, so I changed the background to black, and used PF0 there as a workaround. 

 

To test out the timer bar, when you press the button on Joystick 0, the timer bar will reset, and then count down to zero.  It works smoothly in the 8-bit workshop tool.  

 

However, when I dump the ROM and try it on Stella, I'm having issues.  As you can see, there's one scanline in each scoreboard that's not being blacked out, and when you test out the timer bar, the timer does not smoothly count down.  The ball object will count the first few ticks smoothly, then it pauses, takes out a couple chunks, then starts moving again.  

 

For the life of me, I can't figure out why there's a difference between the two, and obviously, I want it to work on Stella.  Could someone please take a look at the code, and advise me on how to correct this problem?  Since the blue scoreboard is pretty much just a copy of the red, I'm sure if the problem is solved on the red one, I can copy the solution to the blue one.

 

As for the game itself, here's the basic idea - the two players will run back and forth on an ice floe that'll be positioned just on top of the scoreboard.  An enemy (perhaps a giant bird) will fly back and forth across the top, dropping large ice blocks.  The players must dodge the falling ice blocks, then kick them off the side of the ice floe before too many accumulate.  If too many of them pile up, the ice floe will sink.  But as one player kicks a block off to the side, the other will have to jump over the block, or else he'll get swept off the side as well.  There will be power ups and at least one other enemy, as well as a one-player option by the time all's said and done.  Sort of a Kaboom meets Pengo.

 

 

KickIce_20211024.bin KickIce_20211024.a

Edited October 24, 2021 by DaveM

[Thomas Jentzsch]

You are writing to HMBL too early after HMOVE. There has to be a gap of at least 24 cycles.

[DaveM]

9 minutes ago, Thomas Jentzsch said:

You are writing to HMBL too early after HMOVE. There has to be a gap of at least 24 cycles.

Thanks!  That takes care of the timer bar, it works perfectly now.  I was careful to leave 24 cycles between HMOVE and HMCLR, but forgot about HMBL.

 

I'm still having an issue with the two scanlines that aren't being blacked out on the left side though.  Can't figure out how to get rid of those.

KickIce_20211024a.bin KickIce_20211024a.a

[Thomas Jentzsch]

You are calling a subroutine at $f34e which doesn't WSYNC/HMOVE.

[DaveM]

18 hours ago, Thomas Jentzsch said:

You are calling a subroutine at $f34e which doesn't WSYNC/HMOVE.

Thank you!  That did the trick!

 

I'm going to move onto character design now.  I hope to have a working title screen within the next couple weeks, outside life permitting.  I'm really trying to learn kernel timing, and just good kernel design with this game.  With just the scoreboard alone, I'm doing stuff that I didn't know how to do when working on Mr. Yo-Yo.  My plan is to try out a lot of new stuff with this one.

 

[DaveM]

Things are going MUCH slower than I had hoped.  Just not enough time right now to devote to working on the game.  BUT... progress is being made!

[+D Train]

I like the looks of that.  Does it flap?

[DaveM]

17 minutes ago, D Train said:

I like the looks of that.  Does it flap?

Not yet, but it will! ?

[+ZeroPage Homebrew]

15 hours ago, DaveM said:

Things are going MUCH slower than I had hoped.  Just not enough time right now to devote to working on the game.  BUT... progress is being made!

Nice! Reminds me of the birds in Phoenix but I like the design of yours better, a lot more detail!

 

- James

 

[DaveM]

2 hours ago, ZeroPage Homebrew said:

Nice! Reminds me of the birds in Phoenix but I like the design of yours better, a lot more detail!

Yes, I thought the comparisons to the Phoenix birds would be inevitable, so I'm trying to do as much as I can to make sure they don't look like clones.

 

One thing I did was that I wanted the bird to have a distinct vertical center.  Obviously, I'm using both player objects, with P1 a reflection of P0, but when you put them back-to-back, that gives the bird a big fat group of pixels in the middle.  So I'm breaking that up by sliding the Missile0 object in there to create the beak.  Now I can move his eyes to the edge of the player object bitmaps because the Missile separates them, and also give the claws just a bit more detail as well.

[DaveM]

Got some strange stuff going on here.

 

I've got the bird lowering in from above the screen, and I've got his wings animated.  But, when he gets into position, everything goes haywire.  A bunch of junk replaces the player objects.  I can't figure out why it looks good when he's moving, and when he hits his mark and stops, things go weird.

 

Also, in the red section, the "GAME OVER" text is now a bit glitchy.  There's extra pixels between the E and the O, as well as between the V and E.  I didn't even touch that section, so I don't know why that's showing up now.

 

KickIce.a KickIce.bin KickIce.a-vcs.zip

[+Karl G]

16 hours ago, DaveM said:

Got some strange stuff going on here.

 

I've got the bird lowering in from above the screen, and I've got his wings animated.  But, when he gets into position, everything goes haywire.  A bunch of junk replaces the player objects.  I can't figure out why it looks good when he's moving, and when he hits his mark and stops, things go weird.

 

Also, in the red section, the "GAME OVER" text is now a bit glitchy.  There's extra pixels between the E and the O, as well as between the V and E.  I didn't even touch that section, so I don't know why that's showing up now.

 

KickIce.a 26.12 kB · 7 downloads KickIce.bin 4 kB · 13 downloads KickIce.a-vcs.zip 44.83 kB · 7 downloads

Not sure what's going on when the bird reaches its low position, but I noticed that it doesn't happen if "Bird_VMax" is reduced by 1, which may give you the clue you need. I was able to eliminate the game over text glitch by changing "SLEEP 5" to "SLEEP 4" in the "TextLoop1" loop.

 

[DaveM]

Thank you Karl!

10 hours ago, Karl G said:

Not sure what's going on when the bird reaches its low position

I don't feel so bad for posting a question when a more experienced programmer isn't sure what's going on either. 

10 hours ago, Karl G said:

but I noticed that it doesn't happen if "Bird_VMax" is reduced by 1, which may give you the clue you need.

Thanks!  That worked.  I was playing around with it and noticed that when I broke apart the little mathematical equation I'm doing, it worked too.  So instead of this:

    lda #<(Birdie - Bird_Ht)
    clc
    adc Bird_VPos
    clc
    adc Bird_Ani_Ptr
    sta BirdPointer
 

I changed it to this, and it worked:

    lda Bird_VPos
    clc
    adc Bird_Ani_Ptr
    sta Temp

    lda #<(Birdie - Bird_Ht)
    clc
    adc Temp
    sta BirdPointer

 

As soon as I added that 2nd clc instruction, it didn't went all screwy.  But your solution is much simpler, so I'm going with that.

 

10 hours ago, Karl G said:

I was able to eliminate the game over text glitch by changing "SLEEP 5" to "SLEEP 4" in the "TextLoop1" loop.

Nice!  Don't know what was going on there.  When I started typing in the bird's code, a glitch showed up in the blue "Game Over", then by the time I was done typing in the code, the glitch jumped to the red section. Hmmph.

 

Anyway, thanks again!

 

So the bird is now done.  He's just going to fly back and forth across the top there, going up and down off the top of the screen.  Thrilled that I came up with a working kernel for him.  It may not be the best possible solution, but it works.  OK, I can't move him all the way to the left side without glitches, but he's not going over that far anyway.  I can always improve on it later.
 

 

 

[Thomas Jentzsch]

Both code samples you posted will always put identical values into Birdpointer. It makes no difference in which order you add the values together (assuming carry is always cleared). So the change makes no sense, it only creates unnecessary complicated code.

[DaveM]

3 minutes ago, Thomas Jentzsch said:

Both code samples you posted will always put identical values into Birdpointer. It makes no difference in which order you add the values together (assuming carry is always cleared). So the change makes no sense, it only creates unnecessary complicated code.

Yes, the results should be the same, but they weren't, that's the strange part.  The first bit of code output garbage graphics when the bird reached his final position.  The second bit of code worked perfectly.  It should be the same result, but that wasn't what I was getting.

 

In the end, I used Karl's suggestion of reducing the constant Bird_VMax by 1, kept the rest of the original code, and then things worked.  

[Thomas Jentzsch]

6 minutes ago, DaveM said:

Yes, the results should be the same, but they weren't, that's the strange part.

Then the bug must have been somewhere else. Or did you maybe set BirdPointer+1 directly afterwards?

[DaveM]

5 minutes ago, Thomas Jentzsch said:

Then the bug must have been somewhere else. Or did you maybe set BirdPointer+1 directly afterwards?

I don't think I did, but I'll check again later after work (which reminds me, I should actually be working right about now)    

 

Anyway, the good news is that it works now, and I made more progress last night.  Nothing good enough or substantial enough to post yet, but definite progress.

[+Karl G]

The problem is that if the first addition sets the carry, it gets discarded and never makes it into the high byte of the pointer. This fixes the issue without having to set the max height lower.

 

    ldx #0
	lda #<(Birdie - Bird_Ht)
        clc
        adc Bird_VPos
        bcc ____skip_save_carry
        ldx #1
____skip_save_carry
        clc
        adc Bird_Ani_Ptr
        sta BirdPointer

        txa
        beq ____skip_set_carry
        sec
____skip_set_carry
        lda #>(Birdie - Bird_Ht)
        adc #0
        sta BirdPointer+1

 

Is there a cleaner way to preserve the carry when doing multiple additions to the low byte like this? It feels like this is unnecessarily kludgy.

[Thomas Jentzsch]

So the high byte was indeed involved. Then the changed make sense if the first addition never creates an overflow.

 

Else I would do this:

	lda #<(Birdie - Bird_Ht)
	clc
	adc Bird_VPos
	php
	clc
	adc Bird_Ani_Ptr
	sta BirdPointer
	lda #>(Birdie - Bird_Ht)
	adc #0
	plp
	adc #0
	sta BirdPointer+1

 

[DEBRO]

Yes, the issue would be the first addition of Bird_VPos.

 

Any inclusive value of Bird_VPos between 0 -21 for animation frames between 1 - 5 would cause the computation of the MSB to use the carry bit and set the MSB correctly. Other values of Bird_VPos would leave the carry clear and have the graphic pointer point to the page prior to the Birdie graphics.

 

The computation of the MSB isn't needed. You should set BirdPointer + 1 directly since all the graphics reside on the same page.

    lda #>Birdie
    sta BirdiePointer + 1

 

[DaveM]

I'm going to stick with reducing the Bird_VMax constant for now.  I've tried each of the other solutions, and they've all caused glitches in the game's rather ugly title screen logo which I've since added.  So I'll stick with what works for now while I re-design that logo, and if I have problems later, I'll revisit these solutions and see what works.  Thanks!

[+Karl G]

11 hours ago, DaveM said:

I'm going to stick with reducing the Bird_VMax constant for now.  I've tried each of the other solutions, and they've all caused glitches in the game's rather ugly title screen logo which I've since added.  So I'll stick with what works for now while I re-design that logo, and if I have problems later, I'll revisit these solutions and see what works.  Thanks!

Okay, speaking of that - moving code around shouldn't be messing up your 48-pixel routines, either. I'm not sure how I missed it before, but while you have your data aligned, there's nothing to prevent your draw loops for your 48-pixel routines from crossing a page boundary, and therefore adding a cycle and messing up your cycle count in the process. Let me know if you need any info/code on how to avoid this issue. Once this has been addressed, you shouldn't have the issue of adding/subtracting code causing issues in your display like that anymore.

[DaveM]

2 hours ago, Karl G said:

Okay, speaking of that - moving code around shouldn't be messing up your 48-pixel routines, either. I'm not sure how I missed it before, but while you have your data aligned, there's nothing to prevent your draw loops for your 48-pixel routines from crossing a page boundary, and therefore adding a cycle and messing up your cycle count in the process. Let me know if you need any info/code on how to avoid this issue. Once this has been addressed, you shouldn't have the issue of adding/subtracting code causing issues in your display like that anymore.

Sure!  Anything helps!

[+grafixbmp]

On 11/4/2021 at 10:21 PM, DaveM said:

Things are going MUCH slower than I had hoped.  Just not enough time right now to devote to working on the game.  BUT... progress is being made!

Baby Yoda? Or rather Grogu.

Edited November 12, 2021 by grafixbmp
Aditional info added

[DaveM]

Progress has been much, much slower than I had hoped.  I just haven't had the time to work on the game, and honestly, it's getting quite frustrating.  But, there's still just a little progress.  Here's a slightly mocked up screenshot:

 

I'm starting to get concerned though that what I'm trying to do isn't actually possible.  So during the game, between the bird and the scoreboard, I'd like to build a kernel that allows for two multi-colored player objects, plus an asynchronous playfield.  I'm going to use the playfield to draw blocks of ice (just large white squares, not the pseudo-3D ice block in the logo above), which will be dropped by the bird onto the players below.  The players will kick the blocks off the platform they're on.  

 

Anyway, 2 multi-color player objects plus an asynchronous playfield.  Is it possible?

 

I was also thinking of using the ball object to create a blizzard effect on some levels, but that may be too much.