New Homebrew - Kick Ice

[DaveM]

Better.  I fixed the bad temporary kernel, and replaced it with a better temporary kernel.  Screenshot is no longer slightly mocked up, as I got rid of the graphics garbage that was showing up previously.  I added the blue underneath the white platform so it looked more like an ice floe floating on water.  I'm playing around with having that blue band cycle through various shades of blue, but I haven't come up with an effect that I like quite yet.  I also slightly changed the player sprites and colors.  In the previous screenshot, I thought the red guy looked too much like a Devo band member wearing diapers. ?  Eventually, the players will rest flush against the ice floe block, as it'll all be part of the same kernel.  But for now, I'm still playing around with stuff, so I've kept it separate.

[DaveM]

Very slowly making progress, mostly due to lack of time, but some progress is being made!

 

Here's a look at the game's other enemy, "Slammy the Seal!"  In one player games (or if one player gets knocked off in a two-player game), Slammy will jump on board from time to time to try to knock you off.

 

Most of the past few weeks though, I've been working on player movement.  Since the game is played on an ice floe, I wanted the players to slide around a bit as if they were running on ice.  It took quite a while to figure out a formula that worked how I wanted it to.  I'll probably tweak it a bit before I release a playable ROM, but with what I have right now, the players will start out slow, gain some speed, then skid as you try to come to a halt or turn around.  I've also completed the running animation for the player characters.  

 

With the animation complete, I'm going to try to put together a little title screen animation sequence as my next step.  After that, it's the menu screen, then finally starting on the actual gameplay.  

[DaveM]

It's been a while, so I wanted to provide an update.  Here's the first little sampling of partial playability.  Basically, you can move the guys back and forth and have them bump each other around, and that's it so far.  The button makes the player kick, but that really doesn't do anything at the moment.  They automatically kick each other when they come into contact (I still need to work on the kick animation holding for more than one frame when that happens). The plan is for the kick action to be automatic, and the button will be used to jump (not implemented yet).  The player could also switch the difficulty switch to "A", which would then have the button used to kick and the player would push the joystick up to jump.

 

The player that's moving faster when they make contact will "win the contest" and kick the other player.  The longer you hold the joystick in one direction, the faster you'll go.  If you're moving slowly and reach the end of the ice floe, you'll stick there and not fall off.  But if you keep pushing, or if you reach the edge and you're moving fast, you'll fall off.  Eventually, I'll add a splash graphic effect when they fall in, but for now, they just fall off, and the only way to get them back is to push reset.

 

No real gameplay yet.  You can't trigger the seal to come on the screen, the bird does nothing other than swoop in when you start up, no scoring, the title screen logo stays there the whole time, and of course, no falling ice blocks, so no gameplay yet.  Just a sample of how the players will slide around and kick each other.

KickIce_20211214.bin

[DaveM]

Short video of the opening title screen animation.  Still a bit of tweaking to be done, and a kernel to be rewritten, but the basic stuff is there. 

 

 

[DaveM]

So I'm having two major problems when working on this game.  Here's the first -

 

The main play area (below the bird and above the scoreboard) will need a new kernel.  I need the two player objects, multi-colored, as well as an asymmetrical playfield (i.e., 6 PF segments).  I don't need the ball or missile objects.  I'm just getting started on attempting this, but not having any luck so far.  I've been trying a 2 line kernel. The timing is very close, but just not working for me.  Does anyone know of an existing kernel template out there that I can use for this?

 

As for the other problem, I'll cross that bridge a bit later.

 

EDIT:  I went back to working on this late last night.  I'm still over, but now, I'm over by just 1 lousy cycle on lines when both players are being drawn.  However, if I sacrifice my lovely vertical black bar of sta HMOVEs on the left side, then the timing works out.  Of course, I don't want to sacrifice the HMOVEs, but I may have to.  Anyway, it'll be a few days before I can get back to it to see if that works.  I'll share my code when I do, and maybe there will be a way I can get rid of that one extra cycle and keep the HMOVEs.

Edited December 29, 2021 by DaveM

[DaveM]

Need a bit of assistance here.  I wrote a new kernel for the play arena area (currently the area between the logo and the water), and I thought I had the new kernel all figured out and working perfectly.  Then I opened up the ROM in Stella, and the players' movements are all jittery.  It's working just fine in the 8bit workshop/Javatari editor. I can't figure out why there's a difference.  Would someone mind taking a look to see where the problem is?  Thanks in advance!

KickIce_20220101.a KickIce_20220101.bin KickIce_20210101.zip

[+Karl G]

After you set the position of the players, you do a HMOVE without a WSYNC first (the WSYNC was commented out). I added the WSYNC back in and moved both above your timer wait loop. This stabilizes the movement apart from when the players run off the screen, so you will need to tweak your edge detection code for the rest of the fix.

 

KickIce_20220101.asm

[DaveM]

19 hours ago, Karl G said:

After you set the position of the players, you do a HMOVE without a WSYNC first (the WSYNC was commented out). I added the WSYNC back in and moved both above your timer wait loop. This stabilizes the movement apart from when the players run off the screen, so you will need to tweak your edge detection code for the rest of the fix.

 

KickIce_20220101.asm 64.47 kB · 3 downloads

Thanks Karl! 

 

I'm not sure what the problem is you're seeing when the players run off the screen.  It seems to be working as planned for me.  But there's always tweaking to be done, especially after I start working on the gameplay, so edge detection is likely to change anyway.

KickIce_20220102.bin KickIce_20220102.a

[DaveM]

With the new kernel written, I now need some advice on how to continue.  

 

In the game, the bird will drop ice blocks onto the players, who must dodge them, then kick them off the platform.  I'll be using the playfield to render the ice blocks.  It's a 2-line kernel, and there will be 47 double-lines between the bird and the water.  I'm using 5 of the 6 available playfield objects (I had to sacrifice the left PF0 in order to get the kernel timing to work), so that means I'll need 5 * 47 = 235 bytes of RAM to store the PF values for the ice block locations.  In the files I've attached above, I have these stored in ROM, but that's just temporary.  For what it's worth, the blocks will be 3 playfield blocks wide, by 10 double scanlines tall.  The platform is 26 pf blocks wide, so that should give me plenty of room.  The plan is once too many ice blocks (3-5, I'll have to play with it once the game is coded) accumulate on the platform, it will cause the platform to sink and the player(s) will lose a life.

 

So what would be the best way of handling the ice blocks and all the RAM it looks like I'll need?  I've done some very basic research on some bank switching schemes, and it looks like the E7 scheme may be the way to go.  Of course, I know nothing about how to do any of this, so I'm not sure where to start.

 

Is there a better way of handling all the possible playfield data I'll need?  Maybe there's a solution I haven't thought of or don't know about.  I keep thinking of Pengo and all the blocks on the screen there, so I'm guessing there's a way of doing all this.

 

Any advice or suggestions would be greatly appreciated!  Thanks!

[+Pat Brady]

1 hour ago, DaveM said:

So what would be the best way of handling the ice blocks and all the RAM it looks like I'll need?  I've done some very basic research on some bank switching schemes, and it looks like the E7 scheme may be the way to go.  Of course, I know nothing about how to do any of this, so I'm not sure where to start.

 

Is there a better way of handling all the possible playfield data I'll need?  Maybe there's a solution I haven't thought of or don't know about.  I keep thinking of Pengo and all the blocks on the screen there, so I'm guessing there's a way of doing all this.

 

Pengo's resolution (in terms of data storage for the stationary ice blocks) is 11x8. Conceptually that can fit in 11 bytes, though the actual game may use more RAM in some way dictated by the kernel. That doesn't account for sliding or disappearing blocks, but those might be handled separately.

 

If you really need 235 bytes, E7 would certainly give you plenty of RAM, but F8SC (or F6SC or F4SC) and FA might also work.

 

 

[DaveM]

On 1/2/2022 at 5:14 PM, Pat Brady said:

E7 would certainly give you plenty of RAM, but F8SC (or F6SC or F4SC) and FA might also work.

OK, how do I go about using each of these?  I'm only familiar with what I used for Mr. Yo-Yo, which was the F8 method, and I'm having trouble tracking down a "How-To" on these other methods.

 

On 1/2/2022 at 5:14 PM, Pat Brady said:

If you really need 235 bytes

And this is sort of my other question.  Is there a better way to do this?  Maybe I don't need all that RAM after all, and there may be a better way to store the data I need?

[+Pat Brady]

2 hours ago, DaveM said:

OK, how do I go about using each of these?  I'm only familiar with what I used for Mr. Yo-Yo, which was the F8 method, and I'm having trouble tracking down a "How-To" on these other methods.

I'm not an expert on 2600 bankswitching. This page is a good primer on the various methods. It omits the RAM addresses for Atari SC schemes, which are F000-F07F (write) and F080-F0FF (R).

 

Note that you can't use INC or DEC instructions with on-cart RAM (regardless of bankswitching method). Also, since it's not on zero page, any accesses will take an extra cycle, which can affect kernel timing.

 

I took a quick peek at the Stella source code and it appears to detect SC when in each bank the first 128 bytes and second 128 bytes are identical. For FA, it just looks for a 12K cart that does not contain any 3-byte sequences that imply E7.

 

2 hours ago, DaveM said:

And this is sort of my other question.  Is there a better way to do this?  Maybe I don't need all that RAM after all, and there may be a better way to store the data I need?

 

I think this is the most important question.

 

Back in 2009 I started a Primordial Ooze implementation (link) that had 16 arbitrary-length columns. A bitmap representation of that would take 384 bytes, but I did it without extra memory. I can't find the source code, but my recollection is that I kept a list of (row,column) pairs where transitions occurred, sorted by row, and a one-row bitmap. That would be 34 bytes (32 for the transition list, 2 for the bitmap). The kernel checks whether the current row is the next transition row, and if so, masks the transition column's bit in the bitmap. I remember I had to ensure that no row had more than one transition, because the kernel didn't have time to check 2 list entries and mask 2 columns. IIRC it was a 1-line kernel.

 

From what you've described, I think something similar to that might work, depending on:

1. Do all columns move downward at the same speed?

2. Do all blocks have the same height?

3. How many blocks can be in a single column at a time?    

 

[DaveM]

44 minutes ago, Pat Brady said:

Also, since it's not on zero page, any accesses will take an extra cycle, which can affect kernel timing.

Ouch.  I did not know that.  The timing on my kernel is pretty dang tight as it is, so using extra RAM probably won't work, at least how it's currently set up.

 

46 minutes ago, Pat Brady said:

Back in 2009 I started a Primordial Ooze implementation (link) that had 16 arbitrary-length columns. A bitmap representation of that would take 384 bytes, but I did it without extra memory. I can't find the source code, but my recollection is that I kept a list of (row,column) pairs where transitions occurred, sorted by row, and a one-row bitmap. That would be 34 bytes (32 for the transition list, 2 for the bitmap). The kernel checks whether the current row is the next transition row, and if so, masks the transition column's bit in the bitmap. I remember I had to ensure that no row had more than one transition, because the kernel didn't have time to check 2 list entries and mask 2 columns. IIRC it was a 1-line kernel.

When I was planning out this game, I had a very similar idea, but I couldn't quite wrap my head around it, and thought it would just be simpler to take advantage of some extra RAM and go with that.  So this may be the solution I'm looking for!

 

48 minutes ago, Pat Brady said:

From what you've described, I think something similar to that might work, depending on:

1. Do all columns move downward at the same speed?

Yes, at least while they're falling (with the understanding that the speed will increase from level to level).  When a block hits the platform, it'll stop there, and the players could then kick the block horizontally.  The block will then slide, and when it clears the edge of the platform, it will drop into the water and sink off screen.  At least, that's the plan.  The players will be able to jump to get out of the way of a block kicked towards them, but they won't be able to kick a block while they're in the air.

 

50 minutes ago, Pat Brady said:

2. Do all blocks have the same height?

Yes.  In playing around with it, it looks like a block size of 3 PF blocks wide by 10 double-scanlines tall will be ideal.  I'd like to do power-ups as well.  The plan is for a plain square block to be just a block, while the power-ups would take various shapes, while still fitting within the 3 PF x 10 square.  For example, a block shaped like an "S" would give the player spiky shoes so they wouldn't slide around on the ice.  Now, if different-shaped blocks causes too much of a headache, I have other ideas on how to trigger power-ups.

 

54 minutes ago, Pat Brady said:

3. How many blocks can be in a single column at a time?

Let's say 2, with one of them being on the platform, probably while sliding horizontally.  Too keep block-on-block collisions simple, the plan is to not drop one block while another is directly below it.  However, there wouldn't be anything preventing a player from kicking a block so that it slides below the path of another block.  

[DaveM]

Used F8 bankswitching to expand to 8k.  No other changes yet, just needed to give myself more room as the original 4k was almost full.  Been thinking a lot about the previous couple posts and I think there is a path forward for the game.  Haven't quite figured it all out yet, but my next step will be to add the menu, then start on the gameplay.  I think it can be done without extra RAM, but any additional suggestions and/or assistance would be greatly appreciated.

 

Now to the TMI portion of this post...

So my goal with this game is to be done (or at least almost done and very playable) by October 8.  Why Oct 8?  That's when I'm getting married!  Why would that have anything to do with this game?  Because the reception hall we have rented has a couple TV's hanging on the wall.  The manager there suggested we just have them run a slide show of pics of ourselves, but we just don't take a lot of pictures.  So on the drive back from our appointment there a few months back, I suggested that we get a couple Atari 2600s, hook them up to the TVs, and have Mr. Yo-Yo playing on one TV, and Kick Ice playing on the other TV, all ready for any of our guests to go over and play anytime during the reception.  As proof that my fiancee is the coolest, she actually said yes to that idea.  Now, I have double- and triple-checked with her on that idea since, and she's still ok with it, albeit with much less enthusiasm than she originally showed, but with less than 300 days now until the ceremony, I think I'll hold her to it. 

 

But of course, the game is far from finished (it's barely even started), and my time to work on it is rather limited:  I have a wedding to plan, which is taking up more time as we get closer.  Sadly, my fiancee's cancer has come back, so I've been spending time with her running her back and forth to doctors and hospitals.  Now the good news there is that they caught the recurrence early, and her new chemo drugs have slowed the spread down to very manageable levels in some areas, and have stopped the spread in others (and she gets to keep her hair ).  The doctor is very encouraged by the progress made so far and thinks we'll be successful in defeating it in the long run.  I'm also manager of a vintage baseball team, which is attempting to restart after having the last couple seasons cancelled due to COVID.  The entire league shut down for 2 seasons, which caused most of the teams to fold.  We had 9 teams, only 3 were interested in continuing, but after a lot of work by us three teams, we managed to revive a 4th team for a game this Saturday.  Trying to bring that whole thing back up to speed when most have given up and moved on is a lot of work.  Not to mention getting my guys in game shape, which is very easy to lose and hard to get back at our age.  Our butts have been kicked pretty bad so far this season.  Then of course, there's work.  Anyway, the time I have to work on Kick Ice is quite limited, but I'm still shooting for October.

KickIce_20220112.a KickIce_20220112.bin

[+ZeroPage Homebrew]

3 hours ago, DaveM said:

Because the reception hall we have rented has a couple TV's hanging on the wall.  The manager there suggested we just have them run a slide show of pics of ourselves, but we just don't take a lot of pictures.  So on the drive back from our appointment there a few months back, I suggested that we get a couple Atari 2600s, hook them up to the TVs, and have Mr. Yo-Yo playing on one TV, and Kick Ice playing on the other TV, all ready for any of our guests to go over and play anytime during the reception

That is awesome, a (sort of) Atari 2600 themed wedding! What a great idea. ?

 

Congratulations!

 

- James

[vcsrocks]

 On 1/6/2022 at 6:09 AM, Pat Brady said:

On 1/6/2022 at 2:20 AM, DaveM said:

OK, how do I go about using each of these?  I'm only familiar with what I used for Mr. Yo-Yo, which was the F8 method, and I'm having trouble tracking down a "How-To" on these other methods.

 

I'm not an expert on 2600 bankswitching. This page is a good primer on the various methods. It omits the RAM addresses for Atari SC schemes, which are F000-F07F (write) and F080-F0FF (R).

 

Note that you can't use INC or DEC instructions with on-cart RAM (regardless of bankswitching method). Also, since it's not on zero page, any accesses will take an extra cycle, which can affect kernel timing.

 

I took a quick peek at the Stella source code and it appears to detect SC when in each bank the first 128 bytes and second 128 bytes are identical. For FA, it just looks for a 12K cart that does not contain any 3-byte sequences that imply E7.

Perhaps stating the obvious, with the classic Atari SuperChip/SARA schemas (F8SC, F6SC and F4SC) you trade a total of 128 bytes of RAM for 256 bytes of ROM per bank.

In other words, with F8 you will get two pages of ROM with 4096 bytes each for a total of 8192 bytes (minus a few bytes for the switching routine).

F8SC will give you 128 bytes of RAM and two pages with 3840 bytes of ROM for a total of 7680 bytes.

For F6SC (4 banks) you will give up 1K and for F4SC (eight banks) it will be 2K.

All three will have the same additional RAM though, 128 bytes.

In practice this is really not a big deal though, as the additional RAM will make a big difference.

Just something to keep in mind.

[DaveM]

21 hours ago, ZeroPage Homebrew said:

That is awesome, a (sort of) Atari 2600 themed wedding! What a great idea. ?

Seems like a great idea.  Until some jerk says something like, "Hey Dave, got any better games to play?"  Then it becomes a "my foot kicking his ass" themed wedding! ?

[DaveM]

18 hours ago, vcsrocks said:

Perhaps stating the obvious, with the classic Atari SuperChip/SARA schemas (F8SC, F6SC and F4SC) you trade a total of 128 bytes of RAM for 256 bytes of ROM per bank.

It's not obvious to a newbie... or an idiot.  I'm sure I'm in at least one of those two categories. 

 

Good info.  I was actually a bit confused on all that.  I don't like using the extra cycle to access that RAM, but if I need it, I was thinking I could store the ice block data in the zero page RAM, and then use the extra RAM to store everything else.  I've got a few ideas, so over the next few weeks, I'll try them out and see if anything works.  Thanks!

[vcsrocks]

10 hours ago, DaveM said:

Good info.  I was actually a bit confused on all that.

That whole topic can be annoyingly confusing.  I made this for a friend a while ago:

 

 

Should probably have posted it with the text ?

 

[Thomas Jentzsch]

1 minute ago, vcsrocks said:

I made this for a friend a while ago:

A tip, which makes debugging with Stella easier: Let each bank have a different address. E.g. bank 0 = $1000, bank 1 = $3000, bank 3 = $5000 etc.

 

That way Stella can resolve labels much better.

[vcsrocks]

1 minute ago, Thomas Jentzsch said:

A tip, which makes debugging with Stella easier: Let each bank have a different address. E.g. bank 0 = $1000, bank 1 = $3000, bank 3 = $5000 etc.

 

That way Stella can resolve labels much better.

True, but it is important to point out that the most significant nibble of the address should be odd (i.e. A12 = 1) to stay within the address space of the cards.

 

Your example is correct in that sense but it may not be obvious to a newbie.

[DaveM]

Good info everyone!  Thanks!  I'm hoping to have some progress later this week.

[DEBRO]

Hi David,

 

On 1/2/2022 at 5:28 PM, DaveM said:

For what it's worth, the blocks will be 3 playfield blocks wide, by 10 double scanlines tall.

Am I reading this correct? The PF graphics have a horizontal resolution of 4 pixels. Are you saying your proposed blocks will have a horizontal resolution of 12 pixels?

 

I'd suggest you explore the source code to Gunfight. It may help.

 

Something else to consider is if the block is to slide horizontally; you would need the BALL to do a smooth horizontal motion. Without the BALL then the PF will move horizontally at a resolution of 4 pixels which could look choppy.

[DaveM]

12 hours ago, DEBRO said:

Am I reading this correct? The PF graphics have a horizontal resolution of 4 pixels. Are you saying your proposed blocks will have a horizontal resolution of 12 pixels?

Yes.  I want them to be big Pengo-sized blocks.  They have to be wider than the players, which are 8 pixels, so the next size up is 12 pixels.  Here's a mock-up screenshot on how it would look:

 

 

12 hours ago, DEBRO said:

Something else to consider is if the block is to slide horizontally; you would need the BALL to do a smooth horizontal motion. Without the BALL then the PF will move horizontally at a resolution of 4 pixels which could look choppy.

Understood.  Here's the plan... The ice blocks have only two areas where they could move horizontally - when the bird is holding them, or on the platform.  In the scanlines which draw the blocks the bird would be holding, the blocks would actually be drawn by the Ball and Missile1 objects.  That eliminates the choppiness there.  I would then also use those scanlines to reposition the two player objects.  So the highest up the screen the players would be able to reach is the bottom of the block that the bird is holding.

 

As the blocks drop, using the playfield is no problem, as there will be no horizontal movement.  If the player comes in contact with a falling block, it's goodbye player.

 

When the blocks are on the platform, of course, the PF will still be used, however, the blocks would slide VERY quickly horizontally.  4 pixels/frame was the speed I was thinking of using, making the Ball object unnecessary, but I'll have to see how it plays when I get there.  If the game proves too difficult at that speed and I need to slow them down, then I'll start thinking about adding the Ball object in there.  The problem is, there will be times when multiple blocks are sliding around there.  One player could kick a block one direction, and the other could kick another the other direction, and there's only one Ball to use to smooth all that out.  I guess I'll cross that bridge when I come to it.  It all depends on how the thing plays and whatever tweaks I need to make to it.

[DEBRO]

Hi David,

 

I think I understand the make up now. I'm assuming the bird will be isolated to its vertical position, the dropping ice blocks will drop at the same speed so there would be no overlap. What I'm not 100% clear on is if the blocks can stack. I assume not as I don't remember a play mechanic for the player to rise on top of a block.

 

If I'm understanding correctly then I envision possibly 3 kernels? One for the bird, another for the falling blocks, and the last for the players and blocks.

 

I don't think you should need the extra RAM for this setup. If the bird doesn't come any lower and that is the only object in its vertical zone then you could use direct indexing to draw it. Then transitioning to the block kernel, you would HMOVE to move the fine resolution object (it could be a player, missile, or ball since there is no overlap here). The block would drop on a course position value to fit nicely within the PF bits. Once the block arrives in the player area you could use indirect indexing to draw the descending block. Once the block is in place then an array of 5 bytes could hold the block state.