Bruce Lee 2600 - Concept mockup

[+splendidnut]

1 hour ago, glurk said:

Have either of you actually played the Bruce Lee game?  It's not a fighting game.  The fighting is mostly incidental.  It's a "collecting" game with jumping, dodging, ducking, etc, etc...  And it NEEDS lots of screens to make it fun to get to the final boss.

 

The size of the game, # of levels, etc.  is really kind of the whole point.

Nope.  Never played it.  Interestingly enough, I hardly ever played BurgerTime before I made ChaoticGrill.  I did do some research earlier today on Bruce Lee (C64).... please don't make assumptions about what I may or may not know.

 

I understand that there are a quite a few screens involved... which is why I used my BCA project as a starting point.   The screen layouts of Bruce Lee seemed like they would fit in nicely with the way the screens are encoded in BCA.

 

I only posted a graphical mockup for people to enjoy.  Please enjoy it for what it is.

[+splendidnut]

5 minutes ago, Pat Brady said:

I always think it's a laudable goal to minimize cart hardware, but in this case, even if you're going for something that could have been done BITD, bankswitching (and also SARA/CBS/BurgerTime RAM, if that would help) would be totally appropriate.

Totally... I always like to see how far I get with 4k.  But I'm more than willing to go beyond that if need be.

 

I was probably being a little overzealous when I said "full game in 4k"... would probably be better stated as:  basic gameplay / playable demo in 4k.

[+splendidnut]

 

 

[Bomberman94]

On 1/30/2023 at 2:13 PM, splendidnut said:

 

 

So in „real“ the player sprites are half the size? 
 

Bruce Lee is and was my favorite game on the C64 - for me it must not be the same level design like in the original. If variations of 3 or 4 basic screens will help, it’s fine. 

[+splendidnut]

The sprites in my screenshot are 2.125 pixels vertically (9 pixels drawn per 4 in the sprite)... which is due to the display kernel.  I don't think it looks too terrible.  The player is 15 pixels tall (30+ on screen) and the black ninja is 16 (32+ on screen).

 

I've gone thru and tweaked the screen background graphics a bit.  I like how the lanterns turned out... that came out of a fortunate accident where they were using the player graphics data as the color values.  I copied that data and tweaked it a bit:

 

 

I've started work on player movement.  It's a bit rough, but the player can run, jump, climb up, and fall.  The fall feels a bit sluggish, but that actually seems to match other versions of the game.  The black ninja just runs back and forth.

 

I've focused mainly on this screen because it's symmetric. I wanted to work out movement code before tackling asymmetric playfields.  I think I need to get the fighting code in first so that I can see what's needed in the display kernel to handle the sprites kicking and punching each other.  Maybe NUSIZ tweaking or maybe MISSILEs.... not sure yet.

 

Enjoy!

 

BruceLee2600_wip_20230201_NTSC.BIN

[LatchKeyKid]

Nice!  It's looking great so far.  Are the sprites final or still a WIP?

[+splendidnut]

The current sprites are really just placeholders that I threw together to keep things progressing.  I started with @IanAjax's screen mockup for the first frame of each character.  From there, I've been sketching out all the other animation frames, partially referring back to the original ports of the game (C64, Atari XL/XE, Apple ][).   I've been using @kisrael's PlayerPal to draw things up.

[LatchKeyKid]

Thanks for the quick reply.  I'm curious to see what you do with the sprite animations though I'll have to take a look at the c64 version to see the original reference models.  Looking forward to seeing what you can do with this!

[lucienEn]

22 hours ago, splendidnut said:

The current sprites are really just placeholders that I threw together to keep things progressing.  I started with @IanAjax's screen mockup for the first frame of each character.  From there, I've been sketching out all the other animation frames, partially referring back to the original ports of the game (C64, Atari XL/XE, Apple ][).   I've been using @kisrael's PlayerPal to draw things up.

Looks great already. Just curious: how do you detect when climbing is available? Or just hardcoded for now to the middle when there is a PF collision?

[Phobos867]

This looks pretty cool! I'm looking forward for it

[+splendidnut]

16 hours ago, lucienEn said:

Looks great already. Just curious: how do you detect when climbing is available? Or just hardcoded for now to the middle when there is a PF collision?

Thanks!

 

The current code for handling ladders / climbing is a hard-coded software-based collision routine.  Since this project currently uses a row based graphics engine (9-scanlines per row), detecting the ladder is done by checking to see if the current row under the player's head contains a ladder.  If it does, then the X coordinate is checked to see if the player is actually at one of the ladders.   If so, the player is switched into the climbing state.  When the player is in the climbing state, the code still uses the same X coordinate check, but also does Y-coordinate check to see if the player is still on the ladder.

 

To implement more ladders, I'll need to move the hard-coded data into a table and come up with some scheme to identify the individual ladders.

 

Similarly, the ground detection is also software-based and does a row check.  If it's a ground row, the code then reads from the playfield graphics table using the player's X coordinate to determine if the player is on solid ground OR needs to fall.

 

[lucienEn]

I'm not planning to work on Bruce Lee but thought it was interesting to test drawing that with my unfinished screen editor (added all object types but code gen is only finished for COLUBK/PF). Specifically if you could draw the mountains that way. Didn't spent a lot of time on mountains but I think you can make it look fairly decent with bit more work. Now having 20+ screens would be huge amount of work besides the general optimizations.

 

[alfredtdk]

Until I got to this topic, I was completely unaware of Bruce Lee's game, and what an amazing game it is. A pearl forgotten by time, best defining it. I'm sorry that 2nd and 3rd generation consoles haven't received a port of this game, restricted to A800, C64 and other computers. I'm playing the C64 version through emulation. At first I found it a boring game, facing ninjas and sumo wrestlers to collect just a lamp. But that's the secret that I only understood later, by collecting the lamps you unlock paths that were previously inaccessible. They are real little puzzles. And I love the kind of games that involve puzzles. Anyway, I'm happy that this game is being ported to the Atari 2600, within its limitations, which will be possible or not. I hope if the game is actually finished that the infinite lives option feature will be added please. This option is presented in the C64 version. 

[+splendidnut]

Here's another update:

  - All of the player movement has been roughly implemented.  The player can walk, jump, climb, duck, punch and kick.  Everything seems to work fairly well.

  - Player is able to collect the bottom row of lanterns on the first screen.

  - The Black Ninja, and the Yamo, the Green sumo, are still in the initial stages of development.  They run around in a set pattern and Yamo does a jump-kick.  They share the same player object, so they flicker.

  - Also did up a PAL60 version.

 

At this point, I've crossed the 3.5k ROM mark, so I'm starting to run out of room for things in a 4k demo.  The player movement code alone is pretty close to 1k (~0.8k).  There are some areas where I could probably optimize some things.  BUT, I'll probably be looking into implementing a bank-switching scheme in the near future.

 

I really wanted to try and get the first 3 screens fully running in 4k... but just the way the screens are laid-out, at this point, I don't think it's quite doable.  There's enough asymmetry that I need a couple of kernel variations to handle those situations appropriately.  It could potentially be done, but at the expense of simplifying the playfield graphics... which is a non-starter for me. 

 

Enjoy!

 

NTSC:

 

BruceLee2600_wip_20230211_NTSC.bin

 

PAL60:

 

BruceLee2600_wip_20230211_PAL60.bin

[+Gemintronic]

I wonder if you could get the title screen music in with skilled timing and extra ROM?

 

 

[+splendidnut]

18 minutes ago, Gemintronic said:

I wonder if you could get the title screen music in with skilled timing and extra ROM?

It sounds like it could probably be accomplished with just a straight TIA music player.

[+Gemintronic]

2 minutes ago, splendidnut said:

It sounds like it could probably be accomplished with just a straight TIA music player.

 

I was curious if going the PC speaker / Bruce Lee Apple II route would produce more accurate notes.  But, fair enough

[+splendidnut]

2 minutes ago, Gemintronic said:

I was curious if going the PC speaker / Bruce Lee Apple II route would produce more accurate notes.

Certainly would, but that would require cycle counting ALL of the code.  Not something I want to do.  The easiest way to avoid that is either (A) use the TIA as is, or (B) switch the game logic to ARM code, where the ARM will run the waveform music driver in the background.

[Bomberman94]

On 2/11/2023 at 7:27 PM, splendidnut said:

Here's another update:

  - All of the player movement has been roughly implemented.  The player can walk, jump, climb, duck, punch and kick.  Everything seems to work fairly well.

  - Player is able to collect the bottom row of lanterns on the first screen.

  - The Black Ninja, and the Yamo, the Green sumo, are still in the initial stages of development.  They run around in a set pattern and Yamo does a jump-kick.  They share the same player object, so they flicker.

  - Also did up a PAL60 version.

 

At this point, I've crossed the 3.5k ROM mark, so I'm starting to run out of room for things in a 4k demo.  The player movement code alone is pretty close to 1k (~0.8k).  There are some areas where I could probably optimize some things.  BUT, I'll probably be looking into implementing a bank-switching scheme in the near future.

 

I really wanted to try and get the first 3 screens fully running in 4k... but just the way the screens are laid-out, at this point, I don't think it's quite doable.  There's enough asymmetry that I need a couple of kernel variations to handle those situations appropriately.  It could potentially be done, but at the expense of simplifying the playfield graphics... which is a non-starter for me. 

 

Enjoy!

 

NTSC:

 

BruceLee2600_wip_20230211_NTSC.bin 4 kB · 10 downloads

 

PAL60:

 

BruceLee2600_wip_20230211_PAL60.bin 4 kB · 4 downloads

I tried your WIP version of Bruce Lee and I must say very promising! I played this on the C64 very very often (still today) and I can clearly detect the characteristic graphics. Only the playing sprites are far too long and should be adjusted to fit and interact correctly with the background. Personally we don’t need a 1:1 copy of the original game regarding the specific screens but we can do a Bruce Lee 2600 with as many screens as possible with little and clever variations. I have a good feeling with this 😊

[cd-w]

The mockup looks great - this game should definitely be doable on the 2600 with some graphical compromises.

I recommend reading this thread in the 8-bit forum: https://forums.atariage.com/topic/288392-two-bruce-lee-sequels/

 

The map data from the game was extracted and can be loaded in the open source tiled editor - see the attachment on this post.

https://forums.atariage.com/topic/288392-two-bruce-lee-sequels/?do=findComment&comment=4236353

 

Chris

Edited February 20 by cd-w

[Phobos867]

On 2/11/2023 at 3:27 PM, splendidnut said:

Here's another update

This looks better and better everytime, I love it! Looks like a new Activision title

[+splendidnut]

Welp, got some initial AI / movement code implement for the enemies.  AND, I've basically filled 4k at this point.  Here's a breakdown of where it all went:

 

Spoiler

Output layout:
Block Name                        addr   end    size  bank  size (bytes)
--------------------------------------------------------------------------
numberGfx                         0000 - 0080   0081   00    129 bytes
score_kernel                      0081 - 0133   00B3   00    179 bytes
RIOT_init                         0134 - 0143   0010   00     16 bytes
startFrame                        0144 - 0158   0015   00     21 bytes
endDisplay                        0159 - 0173   001B   00     27 bytes
endFrame                          0174 - 017C   0009   00      9 bytes
positionSprite                    017D - 018E   0012   00     18 bytes
EnemyHeights                      018F - 0190   0002   00      2 bytes
bitmapPF0                         0191 - 01E0   0050   00     80 bytes
bitmapPF1                         01E1 - 0238   0058   00     88 bytes
bitmapPF2                         0239 - 0280   0048   00     72 bytes
ladderGfx                         0281 - 0290   0010   00     16 bytes
bitmapColors                      0291 - 02E0   0050   00     80 bytes
lanternColors                     02E1 - 02E8   0008   00      8 bytes
pfBitmask                         02E9 - 02F8   0010   00     16 bytes
level                             02F9 - 0334   003C   00     60 bytes
levelBg                           0335 - 0370   003C   00     60 bytes
bgType                            0371 - 037B   000B   00     11 bytes
bruceGfx                          037C - 040D   0092   00    146 bytes
ninjaGfx                          040E - 0485   0078   00    120 bytes
yamoGfx                           0486 - 04C9   0044   00     68 bytes
bruceColors                       04CA - 0512   0049   00     73 bytes
maskZone                          0513 - 0532   0020   00     32 bytes
ninjaColors                       0533 - 0544   0012   00     18 bytes
yamoColors                        0545 - 0556   0012   00     18 bytes
drawKernelASM                     0557 - 0759   0203   00    515 bytes
levelPtrs                         075A - 075F   0006   00      6 bytes
levelBgPtrs                       0760 - 0765   0006   00      6 bytes
loadLevel                         0766 - 07B5   0050   00     80 bytes
nextScreenRight                   07B6 - 07CC   0017   00     23 bytes
nextScreenLeft                    07CD - 07E1   0015   00     21 bytes
isBackgroundUnderSprite           07E2 - 086B   008A   00    138 bytes
initPlayer                        086C - 0878   000D   00     13 bytes
bruceRunningFrames                0879 - 0880   0008   00      8 bytes
handlePlayer                      0881 - 0B96   0316   00    790 bytes
killSprite                        0B97 - 0BAA   0014   00     20 bytes
initYamo                          0BAB - 0BB7   000D   00     13 bytes
moveEnemy                         0BB8 - 0C8B   00D4   00    212 bytes
blackNinjaRunningFrames           0C8C - 0C93   0008   00      8 bytes
blackNinjaAttackFrames            0C94 - 0C9C   0009   00      9 bytes
YamoRunningFrames                 0C9D - 0CA4   0008   00      8 bytes
enemyWaitTimer                    0CA5 - 0CA6   0002   00      2 bytes
enemyRunTimer                     0CA7 - 0CA8   0002   00      2 bytes
enemyInitAttackTimer              0CA9 - 0CAA   0002   00      2 bytes
enemyAttackDist                   0CAB - 0CAC   0002   00      2 bytes
waitAndPickEnemyDirection         0CAD - 0CE8   003C   00     60 bytes
handleEnemyRunning                0CE9 - 0D8F   00A7   00    167 bytes
initBlackNinja                    0D90 - 0DA0   0011   00     17 bytes
handleBlackNinja                  0DA1 - 0E3A   009A   00    154 bytes
handleYamo                        0E3B - 0EE7   00AD   00    173 bytes
lantBumpPfTbl                     0EE8 - 0EF1   000A   00     10 bytes
checkLanterns                     0EF2 - 0F5D   006C   00    108 bytes
main                              0F5E - 0FEF   0092   00    146 bytes

 

At this point, I'm at a bit of a road block... This is written in my Neolithic "C" and the compiler doesn't quite support bank-switching yet; there's a chicken and egg problem I still need to work on with that.

 

I'm probably going to split my development efforts between working on:

  - a version with just the level layouts / level trap code (w/o enemies) for display kernel development

  - another version with just the player/enemy code (w/o multiple screens) to work on fighting mechanics

  - continuing compiler development in the area of banking and bankswitching to be able to merge the above two efforts.

 

I've also thought a bit about porting what I've got to bBasic... it would be an interesting experiment.  But I'm not sure if it would be worth the effort.

 

At some point, I'll probably be seeking outside help in regards to sprite graphics, sounds, music, and level graphics.

 

Anyways, here's some binaries to try out containing the new enemy AI / movement code (also, improved the lantern collision detection):

 

NTSC:

BruceLee2600_wip_20230224_NTSC.bin

 

PAL60:

BruceLee2600_wip_20230224_PAL60.bin

 

 

Enjoy!

[+Gemintronic]

I bet you could "port" it by turning your graphic kernel into a bB mini kernel and call it instead of DRAWSCREEN.  Recreate the game logic.  Dunno how hard it would be to avoid memory internal to bB though.

[+splendidnut]

IF I went the bBasic route, THEN I'd probably just "replace" one of the bBasic kernels like 1942 does.  That's relatively easy to do and it would allow memory to be reconfigured, since memory layout in bB is basically tied into the display kernel used.  There's quite a lot of customization that bB allows just by how it was designed.

 

Game logic would be a little tricky since the enemies currently use an array of structs and a couple of shared functions (C-style OOP).  But I was already thinking of switching up how things are structured a bit to optimize the code.  And as I write this, other things are popping in my head that I could optimize.  Hmmm...