Ninja Kombat release .03.1 latest update, WORK IN PROGRESS, full collisions, magics, working movesets, spacing.

[freshbrood]

Timing and possibly some magic damages are off and need to be tweaked. 

 

This is nowhere near complete. PLEASE DON'T MESSAGE ME WITH BUG UPDATES! - I know it's still very glitchy and buggy and I am aware of all of them!  

Please don't ask me why I programmed it this way instead of that way, etc.. It's the Atari 2600. Compromises had to be made and what you see is the best I know how to give you.

 

I apologize for all the false alarms and taking so long to release this latest update. I got sidetracked with trying to survive and put this off for a while.  

 

 

 

There is a 4 count beat and then a melody ONLY at the character select screen. The volumes are completely off and player 2 glitches the timing. Pressing fire on joypad two will allow player 2 to enter after player 1 is selected. 

 

There is no cpu ai programmed yet. This engine is based on MK2. The good news is because this is mostly in BBasic when I do release it, it should essentially be the MUGEN of the Atari 2600 and easily customizable by non coders. 

 

I really want to squeeze it down to 32k if possible for compatibility on all cartridges and consoles, without needing to emulate, but that is to be determined. 

 

Before I forget special thanks to Karl G particularly with the scanline counts being controlled by .05% assembly plugs and for figuring out a routine to duplicate color tables for full pallete swaps that saved a ton of memory, and for Maggie Vogel for helping with the chiptunes and for Chris Spry for helping me to understand the sounds, and to Albert & co. for running such a cool page. (And to the many other homebrewers who have inspired.)

 

I hope you enjoy! I love you my fellow Atarians!

 

Ninja Kombat wip v03.1 DEMO.bas.bin

Edited April 18 by freshbrood
MUGEN not MAME

[+Living Room Arcade]

Is this really happening or am I dreaming?  MK for the Atari 2600???!!!  

Edited April 18 by Living Room Arcade

[masschamber]

aw man that's awesome

[alfredtdk]

My friend, this is simply incredible. The opening telling the story of the tournament with the figure of Goro, I am speechless.
The descent of the fighter icons across the screen, the tournament and the battlefield are all very beautiful, faithful to the Arcade. It's incredible that you're managing to compress everything, the logic, to work on the 2600.
I congratulate you and those involved in this project. It's too good.

[freshbrood]

Thanks! 

 

Fun fact: Raiden's body torpedo is actually only 7 pixels wide- the fewest horizontal pixel count in the game!.. but the VCS has 2 very rudimentary scaling options that let each pixel be stretched twice or four times as wide. All other sprites are 8 pixels wide- but they stretch double when attacking. Goro is fixed at double stretched for proper proportion. As a result I've altered some of his melee attacks to be a Shao Khan like shoulder smash instead. (because quad stretching him lost too much detail and looked awful) 

 

Also when doing Raiden's flying torpedo against the edge of the screen he will push through the opponent instead of going off screen. This is because the 2600's memory is so limited there is no room to "hide" sprites off screen, they just wrap around. So he pushes faster until the opponent is at his hands then matches speed, always ending up in the correct position. It was the most elegant solution I could come up with and I think it works.

Edited April 18 by freshbrood

[LatchKeyKid]

Very nicely done!  I love the sprite work.   I've had a pipe dream for a while now to make a samurai game but wasn't sure if the single button controller was enough to map all the combat moves I wanted to include (basic stuff like block/attack up and down plus jump and crouch).   If you don't mind me asking, how did you decide on the control scheme?   How many frames does each animation last and what kind of a delay did you institute for the jump forward/back feature?

[freshbrood]

The jump forward/back is just a straight line up, then up+over, then over, then over+down, then down. Basically 5 straight lines approximating the arch as closely as possible. This saves a lot of memory and allows for just simple intergers. The delay on arching jump- just a variable counter that decides how long to move up, then up plus over, then over plus down, etc.. There is also a separate variable to delay the up/down jump. 

 

The frames are ALMOST as many as in MK2 on Genesis. But not quite, so to make up for lack of frames and telegraphing an attack (aka seeing it coming and having time to block it before the final frame of animation) the punch (for example) will instantly appear with arm fully extended, but damage is delayed a split second so it can be blocked if the opponent is fast enough. This way it feels like a responsive input for the attacker while being fair to the blocker. 

 

I think sprites are totally maxed out or else I'd try to squeeze one more frame of the starting punch. So for now that's how it works. 

Edited April 18 by freshbrood

[doctorclu]

So cool I had to pause work, hook up my 7800, load this up (Harmony) and play it.  Really awesome.

[freshbrood]

Holding down+fire in the air performs a jump punch. 

 

Simply pressing fire without moving performs a low kick. During the knee bend animation press up for a high kick or away for a round house. 

 

I wanted standing block to be a hybrid of SF2 but without locking you in place, so you continue to walk away but upon hit it becomes a block. 

 

I chose the moveset based on what hand movements felt more natural to the sprite animations. E.g. while I really wanted Scorpions spear to be down, back, fire, it felt too unnatural to do down, forward, fire for his ghost punch which moves in the opposite direction. The jump punch has the character sprite leaning down/forward in the air and jump kick seemed to be used more during play so that's how I went with the controls.

 

I left a DEBUG in the game, so doing a straight up jump punch will change to the next character for testing. (forgot to remove it for the demo)

Edited April 19 by freshbrood

[][UNREAL][]

Awesome!!!

[+Living Room Arcade]

@freshbrood, The fighting movements are really excellent!  Arms and legs extending waaaaaaayyy out past the body!    (unlike say Popeye )  You must have done some pretty fancy sprite work there!  

[LatchKeyKid]

Indeed!   My favorite is Goro in the beginning opening animation. 

[freshbrood]

On 6/17/2024 at 7:37 PM, Living Room Arcade said:

@freshbrood, The fighting movements are really excellent!  Arms and legs extending waaaaaaayyy out past the body!    (unlike say Popeye )  You must have done some pretty fancy sprite work there!  

To be fair, Popeye is fixed at the double stretched scaling- just like Goro, which is why his limbs don't extend past his body- the same as Goro, hence why Goro's melee attacks were altered to shoulder smashes instead. But thanks. If you'll notice, idle standing sprites have square pixels while attacking sprites have rectangular shaped horizontal pixels. 

 

There are always 8 horizontal pixels in either case, they are just square or rectangular.  I think Popeye looks pretty good and I'm not sure I could have done better. 

 

When I draw sprites I use MSPaint and create 3 grids. 1) 1x1 wide pixel. 2) 1x2 wide then 3) 1x4 wide individual pixels. Then I'll import the original hires game sprites and drop one of these three grids over the hires sprite- whichever matches closest, then just shade the whole pixel in. So the sprites in Atari are basically literally "traced", with some minor adjustments. 

 

Later on I will upload a sample of how I use the grids to show you. The trick is then to use the NUSIZ0/1 instruction to stretch those pixels wider. 

Edited June 22 by freshbrood

[+Living Room Arcade]

@freshbrood   Yes, please.  When you have time.  I'd be interested to see how you do the grid thing.  

[+Lewis2907]

Played this a few times today on my cell. Wish we had this in the 80s. I was curious on how you did the sprites for the characters with that much detail. Meaning the part where you have to select your player. I'm assuming DPC and some asm.

 

This is a great game and flows really good as well for the movements and attacks.

[freshbrood]

6 hours ago, Living Room Arcade said:

@freshbrood   Yes, please.  When you have time.  I'd be interested to see how you do the grid thing.  

I am about to give away all my secrets. The trick is the NUSIZ0/1 command that allows 2 levels of horizontal sprite scaling, double wide and quadiriple wide pixels. (attacks/Goro and Raiden's torpedo)

 

First I wanted to know what the largest possible sprite character I could draw at the 1x1 pixel resolution would be. I settled on the MK3 ninja sprites as they were the slimmest. I downloaded the spritesheet from MKWarehouse and then resized them to 320 by 360. (Just a little bit taller than wide, this number was arbitrary and I kept guessing until the standing sprite filled out the 8 1x1 pixels wide by about 22 tall. 23 with Raiden's hat)

 

Then (for ANY game I work on) I start with a simple 2d drawing app like MSPaint and I make 3 grids. 1x1, 1x2 and 1x4 wide, all 8 pixels across by whatever number tall. (I think it can go past 180ish before screen roll)

 

See the lower right corner of my attached notes. The defaul 1x1 pixels, set with the NUSIZ0=$0 command. 

And then the double wide 1x2 pixels, set with the NUSIZ0=$36 command. (Used for all attacks and Goro's idle and attack sizes)

And finally the quadriple wide 1x4 pixels, set with the NUSIZ0=(I forget the number but you can find it on RevEng's BBasic page) command. (Only used once for Raiden's torpedo)

 

With the imported orginal game sprites, resized to 320x360 in MSPaint (The size that best filled out the Atari 2600's 8 x 22 chunky resolution, this will be different depending on your spritesheet. The point is to resize the NARROWEST hires sprites to fill in the 8 1x1 pixels at the best proportions).

 

Now those resized sprites should fit nicely, more or less, within one of those 8 pixel wide grids. Figure out which grid it fits in with the best resolution, then drop that grid on top of the hi res sprite. Now take an empty grid and "trace" or approximate those hi res pixels as best you can into chunky Atari pixels. (See the far right upper corner, the high kicking sprite). 

 

Voila. Now observe the top far right last sprite in that grid. See how it's too skinny? That's how ALL the sprites are drawn in memory. But using the NUSIZ0=$36 command will stretch that sprite to twice the width, so it looks correct in game.

 

Popeye and Goro are both permenently set to NUSIZ0=$36 whereas the human NK sprites toggle between =$0 for 1x1 and =$36 for 1x2 stretching. But always with 8 pixels (or less with Raiden's torpedo) across. But the code always stores the "skinny" 1x1 sprites regardless. You just need to figure out how they will look unstretched, hence my method above. It's really that simple!

 

I hope this helps!

 

 

Edited June 23 by freshbrood

[freshbrood]

6 hours ago, Lewis2907 said:

Played this a few times today on my cell. Wish we had this in the 80s. I was curious on how you did the sprites for the characters with that much detail. Meaning the part where you have to select your player. I'm assuming DPC and some asm.

 

This is a great game and flows really good as well for the movements and attacks.

 

Believe it or not the character select screen sprites actually came to me the easiest. The devs for Zevious(?) kinda used my same technique but for the background sprites. It's basically player0 and player1 sprites, set one and then player0 and player1 sprites, set 2 flickering over each other, but I use the flicker to get 6 colors per scanline via blending. Please don't ask me how my brain figured out the colors, I wish I could tell you.. But the gist is each scanline has 1 color, so you have 1, 2 colors for the player0 toggles and then 1,2 colors for the player1 toggles, and then 3,4 colors for the blending/non blending of these that overlap each other or not and then 5,6 for pixels that allow the background to act as a color or not. I think. If that makes sense. This nearly took up an entire bank and I would not use it again on a different fighting game if the players movesets weren't so similar minus a few magics. But it looks neat. It would work really well for something like NBA Jam. 

 

There's actually no DPC+ used, only the standard kernel, intentionally. DPC+ is not well suited for large colorful sprites as it literally uses at least twice the memory with half the size. For this project I needed the exact opposite, half the memory and double sized sprites. And there's no ASM at all in the graphic engine. Just some tiny plugs to control cycle counts at the end. DPC+ is not necessarily better, just different more suited to smaller multiples sprites with less moves. Each kernel has pros and cons. It's important to understand how they work and how graphics are drawn. Also, a lot of newer BBasic users may not know this but basically regardless of game logic size, graphics always take up one and only one bank.

 

So if you have a graphically intensive game keep this in mind. It's easier to juggle 5 balls in crazy ways than it is to add more than 5 balls. If that makes sense. I am not a coder so this is how it makes sense to me. 

 

I hope you appreciate how accurate I am trying to keep the gameplay. As you can see despite the chunky super low res it's more or less pixel accurate.

 

In the case of Liu Kang's flying kick, it was a bit too wide so I recycled the ninja slide, placed him just one pixel above a low block so his head wasn't too high in the air, and it more or less keeps with the original zoning and hit box. 

Edited June 23 by freshbrood

[+Lewis2907]

Thanks, makes more sense now. My next guess was the Multisprite since it seems like the play field mirrors each other. I plan to tinker with the way you explained the sprite. So far in the standard kernel I have been able to get 4 sprites to work at once per say. As mentioned Yea dpc does have its drawbacks on being smaller and stuff.

[freshbrood]

Just now, Lewis2907 said:

Thanks, makes more sense now. My next guess was the Multisprite since it seems like the play field mirrors each other. I plan to tinker with the way you explained the sprite. So far in the standard kernel I have been able to get 4 sprites to work at once per say. As mentioned Yea dpc does have its drawbacks on being smaller and stuff.

 

I pretty much had to write a new 4 multisprite sub for the projectiles. I'm still working on it but it's nearly done. It drove me absolutely crazy that as soon as one projectile landed, blocked or not the other projectile disappeared. I wanted persistent projectiles (even if only for a few tenths of a second) so I basically re-wrote half the game engine. My next update should have this fixed. It just threw off gameplay so much. I was running out of memory so the compromise was, if you melee attack a player their projectile will vanish, but if your projectile hits them while they have one out, the one that's out will still linger a bit, so you can tag each other without worrying about being spammed or the AI/opponent always being a bit faster than you and cheaping you. (Like SubZero trading a hit with Goro in order to freeze and uppercut. That should be possible soon)

[+Living Room Arcade]

@freshbrood  It's totally awesome!  You're capturing the fighting motions of the actual MK characters to make your game!  

[freshbrood]

Just now, Living Room Arcade said:

@freshbrood  It's totally awesome!  You're capturing the fighting motions of the actual MK characters to make the sprites to make your game!  

 

Thanks buddy! Yeah this is pretty much an exact graphical conversion/copy converted as close as I know how to make it to the 2600 resolution. I'm sure there's tons of room for improvement but this was literally my first learning attempt at an Atari game. I bit off more than I could chew, but I'm still chewing!

[+Living Room Arcade]

1 hour ago, freshbrood said:

 

Thanks buddy! Yeah this is pretty much an exact graphical conversion/copy converted as close as I know how to make it to the 2600 resolution. I'm sure there's tons of room for improvement but this was literally my first learning attempt at an Atari game. I bit off more than I could chew, but I'm still chewing!

Keep chewing, my friend!  Life is a journey, not a destination as they say.  So enjoy the ride!