Bomb Jack - WIP homebrew (2022)

[Arlasoft]

 

 

 

I've hopefully found the 'big' project I was looking for. Bomb Jack is one of my favourite arcade games and after checking out the demo from 2007 I was inspired to see what was possible.

 

What I have so far:

 

• ability to display maps to match the arcade, albeit 24 x 26 blocks instead of 26 x 26 (first level in so far)
• map uses PF1 (left only) & PF2 to minimise cycles required
• player movement and animation including walking, jumping, gliding, and falling
• fire bombs displayed in the same order as the arcade
• bombs can be collected and score updated accordingly
• 8K ROM with 128 bytes extra RAM. Bank 0 currently un-used - title screen, music data & routines etc?

 

In the attached binary you can mess around on the first level, with an added vertical wall for testing. You can fall through the top of that wall but in a proper map there would be another platform stopping that happening. 

 

For those not familiar with the game you can hold up while jumping to get extra height, fire while jumping will cancel the jump and spamming fire while falling allows you to 'glide' across the screen.

 

-----------------------------------------------------------------------------------

 

Now comes the hard part - enemies and power-ups. I'm making this post partly to gather some thoughts on the best way to handle those. 

 

I have a pretty tight kernel using macros and 76 cycle-exact sections to avoid looping and WSYNC's, giving the following cycles free:

 

[PLAYFIELD, BLANK, PLAYFIELD, BLANK, PLAYFIELD, LAST ROW] repeats x 26

PLAYFIELD:

• 7 cycles from 30-36
• 16 cycles from 49-64

 

BLANK:

•  62 cycles from 1-62

 

LAST ROW:

•  47 cycles from 13-59 or 5-51

 

 

PL1 is free for enemies, and I was thinking of using a ball or missile for the main power-up, as it doesn't matter if that flashes random colours based on the playfield or player colours.

Not sure about the 'B', 'E' and 'S' power-ups as having them using PL1 too just makes that even more complicated, but they do really need to be identifiable. 

 

I'm not adverse to changing enemy behaviour quite a bit to suit the 2600, keeping in them in horizontal zones rather than chasing the player all over the screen. They would still get in the way of the bombs you need. Or perhaps I have enough free cycles for genuine multiplexing....?

 

One of the main obstacles is that Y and X are both tied up, Y counting down scanlines until PL0 should be drawn (similar to DrawHarry in Pitfall), and X keeping track of the map row from 25 to 0.

 

 

Edited September 28, 2022 by Arlasoft

[Arlasoft]

Just noticed it glitches a bit in Stella, having tested in 8bitworkshop/javatari. Working on it...

 

EDIT: That's better!

 

bj_0_11.a26

Edited September 28, 2022 by Arlasoft

[JetSetIlly]

7 hours ago, Arlasoft said:

I've hopefully found the 'big' project I was looking for. Bomb Jack is one of my favourite arcade games and after checking out the demo from 2007 I was inspired to see what was possible.

 

 

Great! The player control feels spot on. You should continue with this.

[+ZeroPage Homebrew]

20 hours ago, Arlasoft said:

I've hopefully found the 'big' project I was looking for. Bomb Jack is one of my favourite arcade games and after checking out the demo from 2007 I was inspired to see what was possible.

 

This looks and plays great! Bomb Jack is one of my favourite games and the use of playfield for the bombs works really well. The jumping physics also feel spot on.

 

Incredible start to the game and can't wait for more!

 

- James

[+SpiceWare]

Looks awesome!

 

I suggest trying a reflected playfield and only update PF1 and PF2. It might allow you to increase your gameplay area. I used this technique in Stay Frosty when I couldn't accomplish my original goals.

 

Original layout, from Stay Frosty, Part 3:

 

 

Revised layout, from Stay Frosty, Part 4:

 

 

Key thing is you must update PF2 at cycle 48 for the left and right sides of the screen to be different.

[+SpiceWare]

Part 3 also covers the Mask technique of drawing the player. That can free up cycles.

 

        lda (FrostyImagePtr),y ; 5  5
        and (FrostyMaskPtr),y  ; 5 10
        sta GRP0               ; 3 13
        lda (FrostyColorPtr),y ; 5 18
        sta COLUP0             ; 3 21

 

 

It can take a little bit to wrap your head around a mask - I wrote a demo that you can find in this topic.

 

 

 

Look for my reply with this image:

 

[Arlasoft]

1 hour ago, SpiceWare said:

Looks awesome!

 

I suggest trying a reflected playfield and only update PF1 and PF2. It might allow you to increase your gameplay area. I used this technique in Stay Frosty when I couldn't accomplish my original goals.

 

 

Thanks, I'll take a look at the Stay Frosty stuff, especially the masking as I'm starting to implement enemies.

I'm already using just PF1 and PF2 in mirrored mode, I just don't bother with the second PF1 for the sake of two extra playfield pixels, especially as the PF data has to be stored in ZP (although I could move it to the super chip RAM) so the bombs can be cleared - 72 bytes is a hefty chunk as it is.

Edited September 29, 2022 by Arlasoft

[Arlasoft]

Have done some shuffling around to free up cycles for enemy sprites, so now the entire playfield, background colour, player sprite & colour are done in one scanline, leaving this kernel to repeat 26 times:

 

PLAYFIELD: (lines 0,2,4)

• 11  cycles from 49-60

BLANK: (1,3)

•  76 cycles from 1-76

LAST ROW: (6)

•  62 cycles from 1-62.

My fingers are crossed that with the play area starting at PF1 and only being 96 pixels wide, there will be enough time to decide whether to reposition P1 or draw it/do nothing, and still be able to position the sprite without calling a WSYNC. Taking a break for the weekend now for Ludum Dare, which depending on the theme may well be a 2600 game.

Edited September 30, 2022 by Arlasoft

[Ecernosoft]

On 9/28/2022 at 6:03 PM, Arlasoft said:

 

 

 

I've hopefully found the 'big' project I was looking for. Bomb Jack is one of my favourite arcade games and after checking out the demo from 2007 I was inspired to see what was possible.

 

What I have so far:

 

• ability to display maps to match the arcade, albeit 24 x 26 blocks instead of 26 x 26 (first level in so far)
• map uses PF1 (left only) & PF2 to minimise cycles required
• player movement and animation including walking, jumping, gliding, and falling
• fire bombs displayed in the same order as the arcade
• bombs can be collected and score updated accordingly
• 8K ROM with 128 bytes extra RAM. Bank 0 currently un-used - title screen, music data & routines etc?

 

In the attached binary you can mess around on the first level, with an added vertical wall for testing. You can fall through the top of that wall but in a proper map there would be another platform stopping that happening. 

 

For those not familiar with the game you can hold up while jumping to get extra height, fire while jumping will cancel the jump and spamming fire while falling allows you to 'glide' across the screen.

 

-----------------------------------------------------------------------------------

 

Now comes the hard part - enemies and power-ups. I'm making this post partly to gather some thoughts on the best way to handle those. 

 

I have a pretty tight kernel using macros and 76 cycle-exact sections to avoid looping and WSYNC's, giving the following cycles free:

 

[PLAYFIELD, BLANK, PLAYFIELD, BLANK, PLAYFIELD, LAST ROW] repeats x 26

PLAYFIELD:

• 7 cycles from 30-36
• 16 cycles from 49-64

 

BLANK:

•  62 cycles from 1-62

 

LAST ROW:

•  47 cycles from 13-59 or 5-51

 

 

PL1 is free for enemies, and I was thinking of using a ball or missile for the main power-up, as it doesn't matter if that flashes random colours based on the playfield or player colours.

Not sure about the 'B', 'E' and 'S' power-ups as having them using PL1 too just makes that even more complicated, but they do really need to be identifiable. 

 

I'm not adverse to changing enemy behaviour quite a bit to suit the 2600, keeping in them in horizontal zones rather than chasing the player all over the screen. They would still get in the way of the bombs you need. Or perhaps I have enough free cycles for genuine multiplexing....?

 

One of the main obstacles is that Y and X are both tied up, Y counting down scanlines until PL0 should be drawn (similar to DrawHarry in Pitfall), and X keeping track of the map row from 25 to 0.

 

 

Nice job! Is this a port from the NES?

[Dionoid]

Nice! The player movement feels like the Bomb Jack I used to play on my C64!

I remember the later levels can have quite a large number of enemies floating around the screen, so I think that's going to be a challenge. But maybe that can be solved by having less, but "smarter" enemy sprites.

 

I noticed that the vertical wall is having the same color as the bombs, which can be confusing. A technique that might help out here, is to use playfield color-switching, where you're changing the PF color on each scanline, and now the even lines are used to display the walls/platforms, while the odd lines are used to display the bombs. This way, it appears you are showing orange/red bombs and yellow platforms on the same lines, but actually you're alternating the display for each scanline like this (using a 6-scanlines repeat):

  line 1: orange/red (display bomb)

  line 2: yellow (display platform / wall)

  line 3: orange/red (display bomb)

  line 4: yellow (display platform / wall)

  line 5: orange/red (display bomb)

  line 6: yellow (display platform / wall)

 

I’m not sure if displaying PF on each scanline fits your kernel, though.

Anyway, great start to this game!

Edited October 2, 2022 by Dionoid

[Cris1997XX]

This looks really promising! Better than the eye-sore- err, Sega SG-1000 port, but I wonder how you'll handle the later levels and all those on-screen enemies. Make sure to give ZeroPage an exclusive demo for a preview 😂

[Ecernosoft]

On 9/29/2022 at 4:30 PM, Arlasoft said:

Thanks, I'll take a look at the Stay Frosty stuff, especially the masking as I'm starting to implement enemies.

I'm already using just PF1 and PF2 in mirrored mode, I just don't bother with the second PF1 for the sake of two extra playfield pixels, especially as the PF data has to be stored in ZP (although I could move it to the super chip RAM) so the bombs can be cleared - 72 bytes is a hefty chunk as it is.

72 bytes?

I used 48 bytes for ICT2600, you can go check it out in this link: 

 

[Ecernosoft]

19 hours ago, Cris1997XX said:

This looks really promising! Better than the eye-sore- err, Sega SG-1000 port, but I wonder how you'll handle the later levels and all those on-screen enemies. Make sure to give ZeroPage an exclusive demo for a preview 😂

Haha.

Just goes to show how much more time and effort we put in! Not to say they didn't....

Edited October 2, 2022 by Ecernosoft

[Arlasoft]

On 10/1/2022 at 8:17 PM, Dionoid said:

Nice! The player movement feels like the Bomb Jack I used to play on my C64!

I remember the later levels can have quite a large number of enemies floating around the screen, so I think that's going to be a challenge. But maybe that can be solved by having less, but "smarter" enemy sprites.

 

I noticed that the vertical wall is having the same color as the bombs, which can be confusing. A technique that might help out here, is to use playfield color-switching, where you're changing the PF color on each scanline, and now the even lines are used to display the walls/platforms, while the odd lines are used to display the bombs. This way, it appears you are showing orange/red bombs and yellow platforms on the same lines, but actually you're alternating the display for each scanline like this (using a 6-scanlines repeat):

  line 1: orange/red (display bomb)

  line 2: yellow (display platform / wall)

  line 3: orange/red (display bomb)

  line 4: yellow (display platform / wall)

  line 5: orange/red (display bomb)

  line 6: yellow (display platform / wall)

 

I’m not sure if displaying PF on each scanline fits your kernel, though.

Anyway, great start to this game!

Yeah, unfortunately there's no way I can afford to be drawing the playfield on odd rows as well. That scanline is going to be for A) drawing the current enemy, B) getting sprite and colour pointers for the next enemy or C) positioning the next enemy. With an asymmetric playfield I need to be setting PF2 on exactly cycle 48, as well as clearing PF1 before that, so that would come slap bang in the middle of the enemy code. 

Edited October 3, 2022 by Arlasoft

[Arlasoft]

On 10/2/2022 at 6:47 PM, Ecernosoft said:

72 bytes?

I used 48 bytes for ICT2600, you can go check it out in this link: 

 

72 bytes = 26 rows with three bytes for each. Same as the arcade except rows are 6 pixels tall instead of 8.

Not much I can do about that without significantly changing the level designs, which are pretty integral to how the game plays. 24 rows might work like the single-screen stages in Mighty Bomb Jack but probably not worth it for the sake of 6 bytes, especially now I'm using Superchip RAM.

Edited October 3, 2022 by Arlasoft

[Cris1997XX]

44 minutes ago, Arlasoft said:

Yeah, unfortunately there's no way I can afford to be drawing the playfield on odd rows as well. That scanline is going to be for A) drawing the current enemy, B) getting sprite and colour pointers for the next enemy or C) positioning the next enemy. With an asymmetric playfield I need to be setting PF2 on exactly cycle 48, as well as clearing PF1 before that, so that would come slap bang in the middle of the enemy code. 

You could always opt for the DPC+...😂

[Arlasoft]

Just now, Cris1997XX said:

You could always opt for the DPC+...😂

Haha - at that stage I might as well just go back to C64 or Unity

[Ecernosoft]

13 minutes ago, Arlasoft said:

Haha - at that stage I might as well just go back to C64 or Unity

No! Don’t do that!

[Ecernosoft]

52 minutes ago, Arlasoft said:

72 bytes = 26 rows with three bytes for each. Same as the arcade except rows are 6 pixels tall instead of 8.

Not much I can do about that without significantly changing the level designs, which are pretty integral to how the game plays. 24 rows might work like the single-screen stages in Mighty Bomb Jack but probably not worth it for the sake of 6 bytes, especially now I'm using Superchip RAM.

I hear the mountain king…..

[Arlasoft]

Finally got sprite multiplexing working reliably, had to do all sorts of gymnastics with my kernel. One more cycle on the last row of each block and the positioning code pushes it onto an extra scanline.

 

Also moved the level data to a separate bank and added a second level to test progressing to the next one.

 

Last job before coding some enemy behaviour is to find a place to perform the kernel loop exit check without a couple of junk scanlines being drawn.

 

 

bj_012.a26

Edited October 7, 2022 by Arlasoft

[Ecernosoft]

5 hours ago, Arlasoft said:

Finally got sprite multiplexing working reliably, had to do all sorts of gymnastics with my kernel. One more cycle on the last row of each block and the positioning code pushes it onto an extra scanline.

 

Also moved the level data to a separate bank and added a second level to test progressing to the next one.

 

Last job before coding some enemy behaviour is to find a place to perform the kernel loop exit check without a couple of junk scanlines being drawn.

 

 

bj_012.a26 8 kB · 3 downloads

Hey, can you provide a .a or .txt source file? Thanks!

[+x=usr(1536)]

Runs fine on a stock 7800 using a Concerto, and on a 2600 Jr. by way of a Harmony.

 

This is a really awesome start.  Looking forward greatly to the end result!

 

One small request: please don't give in to the temptation of fixing the game telling you that you're Lucy

[Arlasoft]

On 10/7/2022 at 8:40 PM, Ecernosoft said:

Hey, can you provide a .a or .txt source file? Thanks!

I'll share the source code when the game is finished.

[Ecernosoft]

1 minute ago, Arlasoft said:

I'll share the source code when the game is finished.

Ok!

 

I'm mostly curious about the kernal you are using and if it's possible to get a second PF1.

[Cisano]

Bravo! It can become a great port. Only one thing.

The background using shading colors, for me, penalizes the good graphic work you are doing.

Better uniform blu sky and ground.