Karateka 2600 - Mockups

[Robert M]

Hi,

 

I have always loved the game Karateka, and so I hve been dabbling with the possibility of a 2600 version. Below is my first attempt at a mockup of a 2600 screen. I am 99% confident I could get that screen on an actual 2600. I know the Mountain looks like crap, but I was getting tired. I will improve it in later mockups. To get the screen below to work on thte 2600, I had to raise the height of the arch and remove the middle cross beam. I also had to restrict the faces, hands, and feet to playfield graphic positions. It remains to be seen if that last restriction is fatal to the whole concept of a 2600 port with this graphic quality. I will update this thread as I complete more mockups. Comments/critcism is welcome.

I am attaching screenshots from the C64 version for comparison.

 

(edit) Whoops! I can see I forgot to put orange stripes inside the mountain, as I would have to do because of the 2 color per line restriction for playfield graphics. I told you I was tired (/edit)

 

(edit2) Image updated to be more correct. (/edit2)

 

Cheers!

[MegaManFan]

Normally I'd say "nice idea" and but the cynic in me tonight is rearing it's ugly head: (1.) This was already done on 7800 and (2.) The 7800 version is an abyssmal piece of shit so (3.) I can't hardly see how a 2600 version would be BETTER.

[Tempest]

Somewhere I think I have notes that state a 2600 version was planned. However I think it would look terrible. That mock up you made is way beyond the 2600's limitations.

 

Tempest

[Robert M]

Here's another one. (minus mountain, the mountain is just a 48 pixel sprite always in the same place, so I am assuming its a done deal and leaving out of the images for now). I converted the water to land/desert because its the easiest to be monochrome. It might be possible to put the water in as a sprite if the enemy never appears on the screen at the same time. Which would preclude the joy of being pushed off the cliff :wink:

 

This image is important because it stretches the TIA to its limits to draw the player. The player sprite is moving horizontally and varying in pixel width from 1 to 4 color clocks every scanline. The image is such that it could be drawn in reverse for the enemy sprite as well.

 

Enjoy

[Robert M]

 That mock up you made is way beyond the 2600's limitations.

 

Tempest

 

Actually its not that demanding of an image. It uses a technique similar to the one used in Dolphin to create the Dolphin and Octopus images to make the characters. The Arch is sprites at the top, and missles and playfield in the columns. The mountain will need to be retouched, but will most likely be a 48 pixel sprite, which is known technology.

 

The characters are demanding, I am expecting I would need to include 512 bytes of RAM on the cart to make it possible by buffering the character images in RAM for each frame.

 

Cheers!

[Tempest]

That second one is more like what the 2600 version would look like.

 

Tempest

[Robert M]

That second one is more like what the 2600 version would look like.  

 

Tempest

 

What part of the first image (besides the mountain which is too wide, but fixable) don't you believe. There may be a couple pixel level errors in the updated mockup for screen one but nothing critical. Notice that there are only 3 colors per line at the top which is doable because the playfield is blue and orange/black alternating with sprites and missles for all the white and some of the black details.

 

The bottom half has only black/orange (playfield) and white (sprites/missles) All of the pixel widths are valid (I think). Take a look at the sprites in Dolphin and then come look at these again. The display is nicely banded into horizontal strips of detail. The players never leave the ground so in the upper screen space the sprites are free to draw other things.

[Goochman]

The 800 version just for comparision

[Paul Slocum]

I don't see how you would display the two fighters (without flicker).

[bcprs1]

I, for one, think that this would be possible to do. I think the graphics would not be as great as in the mockups though. Then again, you could do something similar to Kung-Fu Masters which looks pretty good.

[Robert M]

I don't see how you would display the two fighters (without flicker).

 

Paul, that's a fair question. I am doing something kinda new here, but I was inspired by the game Dolphin. The character images are a combination of playfield (orange) and a single sprite (white).

 

This technique requires a relaxation of the idea that a sprite needs to have the same resolution and horizontal position or each visible scanline. There is no such requirement on the 2600 since each scanline is rendered largely independently from the previous line (as allowed by HMOVE -7 to +8 color clocks).

 

So when you look at the sprites in the mockups the question for each scanline is: can I shift the sprite via HMOVE from the previous line position to the leftmost visible pixel (usually but could possibly overshoot to allow further movement for next scanline) and what is the width of each sprite pixel 1, 2, 4 or 8 clocks. For example in the second mockup the player sprite is 1 color clock wide for the hair, 2 color clocks wide for the torso and lower leg, and 4 color clocks wide where the leg is kicking out.

 

I am restrained by the use of playfield graphics for skin, as I stated in thte first post. This would restrict players to 40 horizontal positions on the screen. which may or may not work for this game. Investigation is required. I may be able to share the Ball between the players to generate (with some flicker) skin between the rigid playfield resolution.

 

As stated earlier I think I will need to include RAM (256 or 512 bytes) in the cart to buffer a frame for display because to get the image above the players cast shadows and such would require to much calculation to do in frame.

 

I need to come up with a Java utility for editing these sprites with variant width and position. That will make the concept easier to see and implement.

 

Look at Dolphin for proof of concept. How did the programmer generate the Dolphin, Octopus, and Sea Weed without flicker?

 

Cheers!

[ZylonBane]

(2.) The 7800 version is an abyssmal piece of shit so (3.) I can't hardly see how a 2600 version would be BETTER.

7800 Karateka was terrible because it was written by a terrible programmer. Not that complicated, is it?

 

Robert, all the talk about combining sprites with the playfield and line-by-line HMOVE and width tweaking will just drive you to insanity. I did some experimenting a while back and found that the Karateka sprites can be represented quite nicely in 48 pixels. So accept up front that each character will have a steady 30-Hz flicker, keep your colors somewhat low-contrast, and run with it!

[King Atari]

Yeah, 7800 Karateka was a victim of the infamous management at Atari at the time. I'm confident a 2600 version could be succesfully pulled off. I know an Intellivision version was planned back in the day, since the 2600 was built for better playability, I think it would turn out pretty well.

[Brad2600]

If you can make it play better than 7800 Karateka, that would be a plus.

 

If a version of Kung Fu Master can be done on the 2600...why not Karateka.

 

And as I stated, you could always tweak the gameplay and put the 7800 version to shame.

[Paul Slocum]

I'm not sure how well that method would work for a game. I used similar tricks for the Marble Craze title screen and character pictures in the Homestar Runner demo, but it would be really complicated for animated moving characters. And that's a lot of register writes in one line. Asymetric playfield (usually 6 writes), NUSIZ0&1, GRP0&1, HMP0&1. Assuming 7 cycles per load/write (LDA addr,x STA addr), that's 84 cycles, and you still have to do an HMOVE and handle looping.

[Room 34]

Normally I'd say "nice idea" and but the cynic in me tonight is rearing it's ugly head: (1.) This was already done on 7800 and (2.) The 7800 version is an abyssmal piece of shit so (3.) I can't hardly see how a 2600 version would be BETTER.

 

Others have already made this point, but since I always like to restate things in my own way, I still have to give it a try...

 

The only reason the 7800 version sucked was the horrible controls, which were solely due to lame programming. The 7800 could have produced a KILLER version of this game in the right programmer's hands. And I bet it IS possible to produce a 2600 version that, while it doesn't look as good as the 7800 version, would be far more fun to play...

[Tempest]

7800 Karateka was terrible because it was written by a terrible programmer

 

Very true. If you want to see some of his other work just take a look at Choplifter and Hat Trick. Ugh! Not only that, but the games were written in FORTH! Double Ugh!

 

Tempest

[Room 34]

I kind of like Hat Trick.

 

And Choplifter... well... it's better than Karateka!

[ZylonBane]

the 2600 was built for better playability

Uhhh... and this means what?

[Robert M]

I'm not sure how well that method would work for a game.  I used similar tricks for the Marble Craze title screen and character pictures in the Homestar Runner demo, but it would be really complicated for animated moving characters.  And that's a lot of register writes in one line.  Asymetric playfield (usually 6 writes), NUSIZ0&1, GRP0&1, HMP0&1.  Assuming 7 cycles per load/write (LDA addr,x STA addr), that's 84 cycles, and you still have to do an HMOVE and handle looping.

 

Your numbers are correct, so that leaves 3 options:

 

1. Reduce the horizontal resolution. (Reflected asymetrical playfield with PF0 never used saves 14 cycles per line.)

2. Reduce the vertical resolution (2 line kernal)

3. Hardware acceleration [ Work in progress ]

 

Cheers!

[Paul Slocum]

Another option would be to make it a Supercharger game and use self modifying code to display the fighters. That would drop it to 60 cycles per line. It would probably take 1k for the kernal, but I think it would be doable. You could have a load between each section of the game.

 

Seems like you need PF0. Otherwise you don't really have any way to display any of the scenery on the same horzontal lines as the players (like the cliff, gate, doors).

 

-Paul

[King Atari]

the 2600 was built for better playability

Uhhh... and this means what?

 

Bad choice of words. I just meant the 2600 moves much smoother than the INTV, if the INTV could have a port, I can't see why the 2600 can't, graphical differences aside.

 

But then, the INTV version wasn't released, so who knows.

 

Anyways, I wasn't trying to hate on the system or anything, I'm sorry if it came off that way.

[Room 34]

I just meant the 2600 moves much smoother than the INTV.

 

Is that really due to the capabilities of the machine though, or those of the programmers? (I'm not trying to be a smart ass... it is an honest question.)

 

Granted, I personally feel that the purported superiority of the Intellivision was largely on paper, and nullified by later advances in technology for the 2600 (i.e. larger ROMs), but I think the main reason that the 2600's games are, on average, better than those for Intellivision is just that all of the best game programming talent was being focused on the 2600. That's where the money was. Plus, you had people building off of the knowledge and experience of others... meaning that due to the massive amount of collective programming time that went into its games, the 2600's capabilities were more fully realized over time than those of the Intellivision.

[King Atari]

That's a good point, I always thought the smoothness of the 2600 was due to its technical specs, though the right programmer could certainly work miracles.

 

I have little knowledge of the technical specifications of the systems, maybe someone would know better?

[Paul Slocum]

I think the reason 2600 games are so responsive is because of the way the hardware forces you to structure your program around the display kernal which must be executed every frame. This is mostly a result of the 2600 having no graphics RAM, no automated graphics processing, and no interrupts.

 

When you are required to update everything 60 times a second, games are rarely sluggish. Also, since there's so little RAM and no video RAM, you don't ever have long graphics copying routines that take several frames to finish.

 

On the Commodore 64 for example, you can just let the display chip do the work for you and run your game program independently of the display timing.

 

-Paul