Bruce Lee 2600 - Concept mockup

[IanAjax]

Hi, yesterday i watched the C64 version of Bruce Lee on Youtbe to bring back memories.

I just though if it would be possible to port it decently to 2600?

 

This mockup is propably not technically correct but I thought anyway to check if you think this game could be ported.

 

Best

 

 

[Prizrak]

I think it's technically possible with the current banking schemes. I look at it this way, of Space Taxi is possible then certainly Brue Lee is within the real of being a reality as well. I think we may be entering a time where C64 parts are possible and will be comparative to it's counterpart and be done really well. 

[lucienEn]

I was thinking same thing recently whether it's possible to port that great game to 2600 since the gameplay is relatively generic (but not sure enough for 2600).

Some challenges I see:

 

• You would have flickering sprites in the example above since you can only have 2 sprites
• On 1 scanline it would be all this below which is tough one potentially:
  • Asymmetric playfield
  • up to 3 players (alternating with flickering)
  • extra sprite for the ladder (or ball but then you have to switch PF color)
• Elevator Action shows you can do some trickery to achieve the diff. ladder color in middle using background switch. So might be possible but will take a lot of optimizations

[IanAjax]

14 minutes ago, lucienEn said:

 

• • extra sprite for the ladder (or ball but then you have to switch PF color)
• Elevator Action shows you can do some trickery to achieve the diff. ladder color in middle using background switch. So might be possible but will take a lot of optimizations

Ah ok I though that the ball/missile had different color than the 2 player sprites. Here in the mockup I used two missile sprites, doubled, then normal, etc.

[Prizrak]

I am always amazed by the wizardry that is @johnnywcand if he can pull off what he can than anything is possible.

[+johnnywc]

2 hours ago, IanAjax said:

Hi, yesterday i watched the C64 version of Bruce Lee on Youtbe to bring back memories.

I just though if it would be possible to port it decently to 2600?

 

This mockup is propably not technically correct but I thought anyway to check if you think this game could be ported.

 

That looks pretty feasible to me:

• Standard 48 pixel sprite for the score
• The mountain tops could be a combination of PF and a 48 pixel sprite for the tops, plus you could use the missiles (3 copies each) to smooth things out a bit.  You would have HMOVE lines on the left though.
• The grey mountain could just be PF again with a little less resolution (again you could use the ball to smooth it out if needed).
• The red/black/white structures could all be PF with the background grey color.
• The ladder you would want to also use PF so you don't use up a sprite, so I would change it so it would line up with the PF boundaries.  You could in theory change the PF color right before the ladder is drawn and again right after it's drawn (the minimum spacing between color changes is 9 pixels).
• The enemies can be drawn as is (look great btw!) but you would have flicker.  My recommendation would be to have Bruce never flicker and have the enemies flicker at 30hz, or you could flicker all 3 at 40hz.  Of course they would only flicker when all 3 are on the same line.
• Repositioning and reusing sprites would be a bit challenging with an asym playfield but not impossible.
• I would recommend using CDFJ+ with the ARM to maximize the graphics.  🦾

Admittedly I did not own a C64 (Atari 800) but my buddy did and I do recall playing this at his house a few times but don't remember the game play.  I assume there are a bunch more screens?  This screen seems like it would translate well but I would have to check out the rest of the game to see what other compromises would have to be done.

 

I may spend a little time and whip up a POC if I have some free time between Elevator Agent, Turbo Arcade, Champ Sports Baseball and the dozen other projects I have (although I must admit the POC part of a project is always my favorite   ).

 

Great job!

Thanks,

John

 

 

[glurk]

Just FYI.  This WAS an Atari 800 game first.  And later ported to C64 and Apple ][.

 

[+johnnywc]

5 minutes ago, glurk said:

Just FYI.  This WAS an Atari 800 game first.  And later ported to C64 and Apple ][.

 

Cool, I did not know that! I wish I owned it back in the day - I just watched a video on YT and it looks like a lot of fun!   

[lucienEn]

2 hours ago, johnnywc said:

That looks pretty feasible to me:

• Standard 48 pixel sprite for the score
• The mountain tops could be a combination of PF and a 48 pixel sprite for the tops, plus you could use the missiles (3 copies each) to smooth things out a bit.  You would have HMOVE lines on the left though.
• The grey mountain could just be PF again with a little less resolution (again you could use the ball to smooth it out if needed).
• The red/black/white structures could all be PF with the background grey color.
• The ladder you would want to also use PF so you don't use up a sprite, so I would change it so it would line up with the PF boundaries.  You could in theory change the PF color right before the ladder is drawn and again right after it's drawn (the minimum spacing between color changes is 9 pixels).
• The enemies can be drawn as is (look great btw!) but you would have flicker.  My recommendation would be to have Bruce never flicker and have the enemies flicker at 30hz, or you could flicker all 3 at 40hz.  Of course they would only flicker when all 3 are on the same line.
• Repositioning and reusing sprites would be a bit challenging with an asym playfield but not impossible.
• I would recommend using CDFJ+ with the ARM to maximize the graphics.  🦾

Admittedly I did not own a C64 (Atari 800) but my buddy did and I do recall playing this at his house a few times but don't remember the game play.  I assume there are a bunch more screens?  This screen seems like it would translate well but I would have to check out the rest of the game to see what other compromises would have to be done.

 

I may spend a little time and whip up a POC if I have some free time between Elevator Agent, Turbo Arcade, Champ Sports Baseball and the dozen other projects I have (although I must admit the POC part of a project is always my favorite   ).

 

Great job!

Thanks,

John

 

 

Does CDFJ+ with ARM run on any original 2600 without requiring special cartridge HW?

 

The ball can only be drawn once per scanline unless it's gets retriggered, but easier I think p0 and p1 can be used to smoothen 6 mountain tops (more with retriggering), don't think it has to be a exactly same as the original.

 

There are lots of screens but with bankswitching maybe possible. Or do smaller version. I wonder how licensing works here if this would be released...

Edited January 27, 2023 by lucienEn

[Sohl]

1 hour ago, lucienEn said:

The ball can only be drawn once iirc per scanline? I think p0 and p1 can be used to smoothen 6 mountain tops (more with retriggering), don't think it has to be a exactly same as the original.

Cool look so far!
 

The ball is only available once per scanline, and is the same color as the playfield foreground (COLUPF), but can be a few different widths.  Ball width of one or two color clocks (= 1 or 2 sprite pixels) can help smooth out playfield "pixels", which are 4 color clocks wide each.

Missiles do allow repeats like the player graphic sprites, but are the same color as the corresponding player sprite (COLUP0 or COLUP1), so can be tricky to use in some cases.

A lot of game ports made back in the 2600 heyday took a lot of liberties with look and layout (arguably too much liberty, in the cases of Donkey Kong and Pac Man), but I would encourage you to simplify the look a bit more to more naturally fit the rendering capability of the 2600.  

CDFJ+ can help make more complex graphics possible by streaming data from an ARM processor in the cart to the same memory location visible to the 2600's CPU so you don't need as much code on the 2600 to jump around and manage pointers and offset indices, etc.  But if the 2600 is producing the picture, it needs to be done through the TIA's graphics objects and color registers.

[IanAjax]

7 hours ago, johnnywc said:

• The mountain tops could be a combination of PF and a 48 pixel sprite for the tops, plus you could use the missiles (3 copies each) to smooth things out a bit.  You would have HMOVE lines on the left though.

Actually its a bit funny, Bruce Lee on Atari 800 / 64 have rather chunky background. Normally games using fat pixel modes still use the full Y resolution, but in Burce Lee they decided to make pixels square so the BG is basically 160x100 is resolution so I think just repeated sprites would be spot on. Worst case even just 40x resolution could work for the mountains to fit with the rest of the BG amd not oddly "stand out"

 

But of course your suggestions would allow 1:1 conversion from the original almost

 

7 hours ago, johnnywc said:

• The red/black/white structures could all be PF with the background grey color.

Yes I tried to make it "real" so pretty happy that the original BG actually fitted pretty well with those "bands" of colors across the screen

 

7 hours ago, johnnywc said:

• The ladder you would want to also use PF so you don't use up a sprite, so I would change it so it would line up with the PF boundaries.  You could in theory change the PF color right before the ladder is drawn and again right after it's drawn (the minimum spacing between color changes is 9 pixels).

That would be amazing and PF resulution/alignment woud be perfect. Actually most ladder in the game have "space" to the left and right of them. And as in some screens there is 2 ladders at the same X pos that would allow it (ok it could be using sprites interlaces also)

 

7 hours ago, johnnywc said:

• The enemies can be drawn as is (look great btw!) but you would have flicker.  My recommendation would be to have Bruce never flicker and have the enemies flicker at 30hz, or you could flicker all 3 at 40hz.  Of course they would only flicker when all 3 are on the same line

Yes that is exactly how i saw it. Keep Bruce stable. Also often they are not on the same line. And many levels have not even enemies its just platform jumping.

 

The conversion was so easy. I just took them directly from the game. Made them into one color each and then added the scanline color banding switching and moved some few pixels.

When Bruce is jump kicking it would need to double the sprite in X but it would look ok as it would almost create a speed/motion blur effect.

 

For the ninja when it attacks with its katana, if we are not using sprites for the ladders then those could be used for the Katana, or there would need to be flicker for 4 sprites potentially.

 

 

7 hours ago, johnnywc said:

• I would recommend using CDFJ+ with the ARM to maximize the graphics.  🦾

I may spend a little time and whip up a POC if I have some free time between Elevator Agent, Turbo Arcade, Champ Sports Baseball and the dozen other projects I have (although I must admit the POC part of a project is always my favorite   ).

I might to clarify that I justed posted this as inspiration for someone to take on the project. I am just an humble old pixel artist that did my first try on the 2600 (needed to read up a little on the hardware yesterday  ) Did a litttle 6502 ASM around 86 on C64 for Demoscene stuff but that was basically just starting and editing some scroller/FD routines I got from other people.

 

 

7 hours ago, johnnywc said:

Great job!

Thank YOU Legend  

 

[IanAjax]

5 hours ago, Sohl said:

A lot of game ports made back in the 2600 heyday took a lot of liberties with look and layout (arguably too much liberty, in the cases of Donkey Kong and Pac Man), but I would encourage you to simplify the look a bit more to more naturally fit the rendering capability of the 2600.  

Yeah for sure. Its already simpified a bit. Just wanted to see what could theoretically in some form be possible  

 

Must say though that Donkey King is not THAT bad. I had the cart and I really enjoyed it as the gameplay was still rather intact (which I cant say on Pacman)

Funny you mention those as DK was the first arcade game I ever played (or well it was Crazy Kong - it took me a mindfuck the realize many years later on that Mario did not say "Hoya" in the original - luckily that fixed that error on Mario 64 with a "ho"), followed by Pacman just after (first visit at the local Arcade in 81 as 8y old) I got a blister on my midle fingers that day and my who life pespective changed (and the content of my pockets) it was that day that I thought "Wow games are amazing, I also want to do this things - and I decided that I wanted to make games and well that is what I then did up to now  )

[+johnnywc]

6 hours ago, IanAjax said:

Funny you mention those as DK was the first arcade game I ever played (or well it was Crazy Kong -

 

I had the same situation!  My first exposure to DK was Crazy Kong that was at our local donut shop 🍩 😋  It wasn't until years later that I realized that Donkey Kong was the original and CK was the clone (I always assumed it was the other way since Crazy Kong sounded like a better name than "Donkey" Kong  )

6 hours ago, IanAjax said:

 

it was that day that I thought "Wow games are amazing, I also want to do this things - and I decided that I wanted to make games and well that is what I then did up to now  )

Same here!  (although I just make games for a hobby, I wish it was my full time job  )

[Metal Jesus]

Wow! That looks really good. I LOVED Bruce Lee on C64 as a kid

[+johnnywc]

13 hours ago, lucienEn said:

Does CDFJ+ with ARM run on any original 2600 without requiring special cartridge HW?

No, it requires the ARM chip to be inside the cartridge to run on a stock 2600 or compatible.  Of course the CDFJ+ cartridges sold through AtariAge all have the required hardware to run on *any* 2600.  Additionally, the Harmony and Harmony Encore multicarts also have the special cartridge hardware to allow the ROM for these types of games to be played off of an SD card on real hardware.  Lastly, there are many emulators (Stella, Gopher2600, etc) that emulate the special hardware that allow you to run the games on other devices as well.

13 hours ago, lucienEn said:

The ball can only be drawn once per scanline unless it's gets retriggered, but easier I think p0 and p1 can be used to smoothen 6 mountain tops (more with retriggering), don't think it has to be a exactly same as the original.

Agreed.  I was thinking the player graphics would be perfect here for the 6 mountain tops since you would just need to have both P0 and P1 triplicated with the same image.  Of course that is just eye candy and not necessary for the game since you could just do the mountain tops with plain ol' playfield graphics at a lower resolution.  If you do use the player sprites, the mountain tops would have to be closer together of course (48 pixels wide max for all 6 copies total).

13 hours ago, lucienEn said:

There are lots of screens but with bankswitching maybe possible. Or do smaller version.

I would suspect 32K might be enough, especially if you use compression for the screen data as most of it is just static playfield.  However, the time needed to decompress the data on the fly would most likely require the ARM chip since you would run out of cycles during VBLANK and OVER SCAN pretty quick.

13 hours ago, lucienEn said:

I wonder how licensing works here if this would be released...

Well, you have a double-whammy hear since there is an IP on the game itself (does Datasoft still own it or would that go to the creator Ron Fortier?) and then another one on the name "Bruce Lee".  I would recommend if the game gets made to rename it to something like "They Call Me Bruce!" , but then you'd have the movie rights to contend with or even the song by Rick Springfield.   

 

11 hours ago, Sohl said:

CDFJ+ can help make more complex graphics possible by streaming data from an ARM processor in the cart to the same memory location visible to the 2600's CPU so you don't need as much code on the 2600 to jump around and manage pointers and offset indices, etc.  But if the 2600 is producing the picture, it needs to be done through the TIA's graphics objects and color registers.

Well said!   I would also add that the 'fast fetch' mode and 4K of data streams in CDFJ+ will also allow for more complex graphics since you only need 5 cycles to update a TIA register (player graphic, color, PF value, etc).  If you go with straight assembly you'll need more cycles so you'll either have to reduce your playfield width (maybe exclude PF0), maybe go with a mirrored playfield, single color and/or 2 line sprites, etc.  Of course you could always use a 128K or 256K bank switching with straight assembly and possibly "hard-code" most of your backgrounds and achieve similar graphics without the ARM.  

6 hours ago, IanAjax said:

Actually its a bit funny, Bruce Lee on Atari 800 / 64 have rather chunky background. Normally games using fat pixel modes still use the full Y resolution, but in Burce Lee they decided to make pixels square so the BG is basically 160x100 is resolution so I think just repeated sprites would be spot on. Worst case even just 40x resolution could work for the mountains to fit with the rest of the BG amd not oddly "stand out"

 

But of course your suggestions would allow 1:1 conversion from the original almost

Agreed, I would start off with just PF and then you could add the sprite copies later if you have the ROM.

6 hours ago, IanAjax said:

Yes I tried to make it "real" so pretty happy that the original BG actually fitted pretty well with those "bands" of colors across the screen

 I watched a YT video and it seems like there are *a lot* of screens for this game!  Each one would have to be examined to determine how best to covert them to comparable 2600 screens.  👀  This one screen seems to suit the 2600 strengths and avoid most of it's weaknesses, so it's a good start!  

6 hours ago, IanAjax said:

That would be amazing and PF resulution/alignment woud be perfect. Actually most ladder in the game have "space" to the left and right of them. And as in some screens there is 2 ladders at the same X pos that would allow it (ok it could be using sprites interlaces also)

Yes, there are options here.  For Elevator Agent, I kept the playfield color constant for an entire scanline and changed the background color to achieve up to 8 colors per line (the PF color plus up to 7 background color changes).  The caveat is that the color changes require specific timing so custom 'kernels' would need to be written based on when the color changes take place.  All possible for sure, but it took me a couple months to write all of the kernels for Elevator Agent, including the mid-screen reposition routines.  Those are always a challenge if you don't have 'less busy' scanlines where you have time to reposition a sprite, set it's properties (size, reflect, HMOVE values).  

6 hours ago, IanAjax said:

Yes that is exactly how i saw it. Keep Bruce stable. Also often they are not on the same line. And many levels have not even enemies its just platform jumping.

Agreed, watching the video most of the time Bruce is by himself or just one enemy.  The lamps he is collecting (or whatever those are) you could use the multi-sprite copies as well and make sure your playfield lines up properly (similar to how I positioned the lights in Elevator Agent).

6 hours ago, IanAjax said:

The conversion was so easy. I just took them directly from the game. Made them into one color each and then added the scanline color banding switching and moved some few pixels.

  Looks good!

6 hours ago, IanAjax said:

When Bruce is jump kicking it would need to double the sprite in X but it would look ok as it would almost create a speed/motion blur effect.

You *may* be able to just use a sprite and it's missile here instead of a 2x sprite.  It would require shifting/resizing the missile, or you may be able to just shift the player.  I would recommend that an HMOVE be done on each line so you have the Activision standard 8 blank pixels on the far left so you could use the missiles or per-line shifting of the sprites without having HMOVE bars show up in random places.

6 hours ago, IanAjax said:

For the ninja when it attacks with its katana, if we are not using sprites for the ladders then those could be used for the Katana, or there would need to be flicker for 4 sprites potentially.

Is the katana the sword-like thing he's swinging around?  If so, you may be able to use a missile here as well, similar to how they used the missile for the hockey stick in Activision's hockey. 🏒  Of course there are limits on how many cycles are available for each scanline so most likely not all of these ideas would be feasible, especially all together.

6 hours ago, IanAjax said:

 

I might to clarify that I justed posted this as inspiration for someone to take on the project. I am just an humble old pixel artist that did my first try on the 2600 (needed to read up a little on the hardware yesterday  ) Did a litttle 6502 ASM around 86 on C64 for Demoscene stuff but that was basically just starting and editing some scroller/FD routines I got from other people.

That's how all great projects are started, with an idea and a bit of inspiration!   I may take a stab at getting a screen displayed to see how it looks while I'm in between projects, or if any one else is interested, I could certainly provide guidance and suggestions (maybe even some sample CDFJ+ code  ).

6 hours ago, IanAjax said:

 

Thank YOU Legend  

 

You are too kind sir! 😊

[lucienEn]

Thanks very much for the info on CDFJ+ and ARM: and licensing-). Not familiar with bankswitching much yet, but I noticed Circus Convoy is 128KB and no special HW so maybe it could be avoided. But not sure which scheme that is using. Personally if I would create something similar to this game, I'd try keep it pure 2600 given there are so many ports already. And then perhaps reduce it to 10-15 screens (and have small variations to expand) and simplify animations. Game would still be fun I think.

 

Regarding the wider sprite with the forward jump kick, certainly some ports just don't show it that wide so that's an option to keep things simple. But I guess the missile should work as well for that.

 

 

Edited January 28, 2023 by lucienEn

[+Philsan]

I would love Bruce Lee on Atari 2600.

It's a game designed considering A8 specs (two sprites for Bruce Lee, two sprites for Yamo, one sprite for ninja = 5 A8 sprites).

 

Nowadays a lot of homebrew games use DPC+ CDFJ+, the most popular multicart supports it, emulators too.

Therefore I would use it. But it will be up to the programmer to decide. Only my two cents because I would love a state of the art conversion.

 

 

[+splendidnut]

13 hours ago, lucienEn said:

Personally if I would create something similar to this game, I'd try keep it pure 2600

Throwing down the gauntlet!  So, 4K ROM only, no RAM, no bank-switching? 

 

Jokes aside, it's a good starting point.  I always start there.  You could probably get the game working within 4k... with multiple screens.

 

On 1/26/2023 at 6:30 PM, lucienEn said:

On 1 scanline it would be all this below which is tough one potentially:

• Asymmetric playfield
• up to 3 players (alternating with flickering)
• extra sprite for the ladder (or ball but then you have to switch PF color)

 

I agree.  A blended approach could work: 2-line kernel, with 1-line resolution for the asym PF, and 2-line resolution for two-multicolored players (P0 + P1).

 

It could potentially be done with a single kernel.  But, multiple kernels could be created to handle the different PF situations (mirrored, repeated, asymmetric) depending on the background graphics in certain areas of a screen.  At that point, you'd probably be pushing beyond 4k though.

 

 

[lucienEn]

22 hours ago, splendidnut said:

Throwing down the gauntlet!  So, 4K ROM only, no RAM, no bank-switching? 

 

Jokes aside, it's a good starting point.  I always start there.  You could probably get the game working within 4k... with multiple screens.

 

I agree.  A blended approach could work: 2-line kernel, with 1-line resolution for the asym PF, and 2-line resolution for two-multicolored players (P0 + P1).

 

It could potentially be done with a single kernel.  But, multiple kernels could be created to handle the different PF situations (mirrored, repeated, asymmetric) depending on the background graphics in certain areas of a screen.  At that point, you'd probably be pushing beyond 4k though.

 

 

I thought you don't need special HW to go beyond 4k? I only read on basics for bankswitching. Circus Convoy is 128kb and I believe no special HW mentioned other than maybe the cartridge ROM itself?

[+splendidnut]

You need to better define what you mean by special hardware.  Bank-switching requires extra hardware in the cartridge OR a custom (special) ROM chip with the bank-switching logic embedded to accomplish.

 

Anything beyond 4K requires some sort of bank-switching as the cartridge ROM only has a 4k address space to work with.

 

 

 

 

[lucienEn]

5 hours ago, splendidnut said:

You need to better define what you mean by special hardware.  Bank-switching requires extra hardware in the cartridge OR a custom (special) ROM chip with the bank-switching logic embedded to accomplish.

 

Anything beyond 4K requires some sort of bank-switching as the cartridge ROM only has a 4k address space to work with.

 

Got it, that's what I meant above with "other than maybe the cartridge ROM itself". I don't mind with that enhancement since several bank-switching schemes were used in the 80's for official published 2600 games.

[+splendidnut]

I was inspired... So, here's a running graphical POC using a highly-changed BCA codebase, so it's a blended kernel (single-res PF, double-res Sprites).  A bit rough graphics-wise, but it's a start.  Note that the playfield is NOT asymmetric, ladder/items are missing, and I just duplicated the player sprite for showing a single enemy.

 

I was able to get the ROM usage under 2k with 2 screens.  Might be possible to get a full game within 4k.... depends on how much gameplay logic is needed and how much graphics is needed.  BUT, I'm thinking it would probably end up needing 8k or more.

 

 

Enjoy!

 

brucelee.bin

 

[glurk]

@splendidnut and @lucienEn ---  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.

[lucienEn]

I have played it a lot on the c64...

Hallmark feature is the jumping kick.

 

10-15 base screens with variations could be about 30 perhaps (never counted original but likely close to that and they have some similar screens as well sharing common elements).

Edited January 29, 2023 by lucienEn

[+Pat Brady]

2 hours ago, splendidnut said:

I was able to get the ROM usage under 2k with 2 screens.  Might be possible to get a full game within 4k.... depends on how much gameplay logic is needed and how much graphics is needed.  BUT, I'm thinking it would probably end up needing 8k or more.

 

The original came out in 1984, for more-powerful systems, and only on disk and cassette. 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. By 1984 bankswitching was the norm for new 2600 games.