Devin

I just noticed that Tomato Ken is not compliant. I've attached a compliant version.

Those look excellent! Very expressive and funny. Thank you, but they are practically all Espire's work!

I'll be able to move the ball quite well with the next update. It won't have to be centered. I worked on some pictures of my own for the characters normal and angry faces. The ball is always 4 pixels, but can move left, right with ease. I will use a XOR trick using a lookup table for movement commands.

I'm glad you enjoyed that. Hee hee. I only have that hooked into Tomato Ken. Each of the boxer's can have up to 8 "stances" which control which macros are executed - simply a group of event handlers! Anyway, when Tomato Ken does his super, he changes stance to one that has the "Fly Knockdown" linked from the "knockdown" event. It actually works anytime after he throws the punch and before he resets after the delay expires.

I should have something new Friday or Saturday.

Question: Is it possible to flip only the head sprites and not the balls? If the case be yes, then why not solve the clock-cycles issue by just keeping the ball gfx for all 3 heads centered and fixed symmetrically as with the hit face? --that way none of the ball gfx need to be flipped for any of the heads. Flipping only the head sprites would use less clock-cycles as I would think. Actually, I gave a ton of thought to this.... and the answer came to me in my dreams - brought to me ny the terrifying sprites from No Escape. j/k. I looked the images and I am sure I can added flippable faces. The trade-off is that the ball will be fixed at 4 pixels. Fortunately, with only a few exceptions, all the faces can be drawn using the fixed width ball. This includes the ones in this release and the characters are drew for sequels already. The formula I showed above relies on knowing the width of the ball in the prior position. XReverse = Widthprevious - Widthcurrent - Xnormal If the ball is kept at the same width, the formula simplifies to: XReverse = -Xnormal Which is now possible.

Looks great! Great points. I'll incorporate both in the next binary - which I shall call "RC 3 feature creep 1". :-) I can also change the color of the player to red or something like that. Looks great! I might not keep the socks. I'm trying to keep the visual noise to a minimal - so we can't be too artistic with the player graphic. Admittedly, it looks great. I'll keep it 16k for this release. The only way to get more boxers is to create redundant copies of the kernal screen. The graphics are just too integrated to chop the screen into different parts.

I can determine the ball's reverse motion based on this formula: XReverse = Widthprevious - Widthcurrent - Xnormal Unfortunately, I don't have the clock-cycles available to compute this.

Actually, let me give some more thought to this....

I will go 32k in the next version. The trick is the graphics, The kernal code plus the boxer sprites almost fills the 4k bank. I might have to create different banks that contain different sets of boxers... ugh. That looks painful!

You played it on a handheld? I'm frightened.. very frightened! Looks good. Here's a version I created based on your suggestion. Good?

There are two challenges with the faces that I would have to overcome. During the part of the kernal where I draw the faces, I switch between updating the face and background/human every other scanline. As a result, everything gets nice square pixels. When I update the face, I change the player0 color, player0 graphics, ball color, ball enable, and ball size. When I update the line, I'm actually way over horizontal blank time - but since the computer's head is, at least, 8 pixels (4 HMOVE hidden + 4 shoulder), it all works timing-wise. The trick is getting all the data ready to be updated. The timing is so close, that I use a single indexing variable that directly accesses 4 tables - all at the same time. HeadPixel,X HeadColor,X BallColor,X etc... Flipping faces would require a different ball set of instructions. I can't just flip player 0. ... which brings up the second issue. I store all the heads, bodies, etc... into data-aligned table. Each head takes 12 bytes in each. This allows at total of 21 heads. Each player takes at least three which gives 7 heads. There isn't enough room in the buffer for 4 a piece. I could keep the ball centered, but that would require a non-aligned table and another index. I'm not sure I can spare the cycles... I love the designs. I'll try to draw one for Russ and Wally. If I can get this to look good, they are in! You are a master hacker... and an 8-bit Picasso. I love the Roo too! However, all the characters in this version were characters in my never-completed Commodore 64 version. So, I kinda of fond of the crazy Australian! But not is all lost, I plan to have a ton of sequels. In particular, K.O. Homebrew! (maybe called K.O. Atari Age). Anything goes in that release!

I am curious to get everyone's feedback one last-minute change I can make. I leaning away from this, but what about displaying the computer and player spirit? I've attached a mockup.

Both the player and the computer have a variable called spirit. When you land a punch, you gain 1/4 the punch power in spirit. When you are hit, you lose 1/2 of the punch power. When you are knocked down, the system uses the spirit variable to determine the difficulty. Basically, each time you hit the button, you add to a recover variable. When Spirit + Recover = 255, then you can get up. The idea is that it is harder to get up if your spirit is lower. When you get up, or a round starts, your health increased to your spirit (if spirit is larger). Overall, the idea is that you can a great comeback. If you are knocked down twice, for instance, your health and spirit will be pretty low. If you make a epic comeback and land a ton of punches (maybe even knock down the computer), your spirits will be high. If you are knocked down, it will be easier to get back up.... and if the round ends, you will recoup the health. The clock doesn't use the 48-pixel trick. I also don't have the space.

I don't have a binary yet, but the final release candidate will make the following changes: Better recovery logic for the computer Updated player sprites You have one rematch against each opponent. The last version only let you have one rematch per game. Some minor changes to sound

Don't make me knockout punch you!

That is simply amazing.

I will have one more release candidate. I made a few minor changes to the computer recovery logic. I won't upload it until I am positive it is the last, final, done, complete, never-to-be-updated version.

Thank you! After this project is in the books... it is sequel time! I spent a long, long time working on a "Fight Engine" that it used to control all the computer's behavior. Really, its kind of a byte-code virtual engine with branching, looping and a various commands. The game doesn't contain any 6502 code that is dedicated to a character. Anyway, we just need to update the graphics, sounds (also byte tables), and the scripts that run the boxers and *poof* we can have a new game with all new characters! I would like to create "K.O. Homebrew" where yourself and other on these boards can create their own characters, moves, etc...

Release Candidate 3 This release candidate contains one bug fix (forgot to assign a pointer for TKOs) and an improved player input system. At this point, I cannot imagine anywhere I can make a change unless a bug is found. Fixed a bug that occurred when the player was TKO'd. I combined the color schemes for the "human knockdown" and "computer knockdown" for all the characters. The color schemes control the colors at the top of the fight screen - in particular, the clock and health bars. The new versions contain the same blue and red text. The health bars are grayed out. This also saved some bytes, though I don't need them. I decreased the amount of health the computer loses when hit. This makes it a tad more fun since you can't knock the computer out in 30 seconds. Before the average hit damage was about 18. Now it is about 12. I changed how the computer regains health after been knocked down. The game maintains a "spirit" variable for the computer and player. When the either lands a punch, it increases. It drops when hit. This all depends on a percentage of the punch power. Before, the computer recovered to this value alone. The game also used a "recovery bonus" to make it easier for the computer to recover - depending on the character. In this new version, the computer also gains the bonus as part of their spirit - and therefore their recovered health. The result is that the computer recovers just as it did before - but with more health. The input system was revised slightly. Before you had to hold the button before hitting left, right, or down. The new version allows you to hit them at the same time. RC3_2009_02_26d.bin

To punch, hold down the button and press left or right. To block, hold the button and press up or down. Remember to block then counter punch. It took me a few games to figure this out, too. I was trying to press fire and left or right at the same time. Basically, you just want to hold the fire button down, then punch and block with the joystick. Let go of the button only when you need to move your boxer. Release candidate 3 (which I will have out later) will fix this issue.

To punch, hold down the button and press left or right. To block, hold the button and press up or down. Remember to block then counter punch. The clock is at x2 speed. Boxer games rarely (if never) have a clock based on a 1-to-1 ratio. Mike Tyson's Punch-out uses x3.

Release Candidate 2 I added some fun features to the game. I still have the select screen in this test version. It is the same as the last release candidate except I tied it into the joystick rather than the Select/Game switch. The punch graphic for the player was updated. The new version was inspired by Inspire8. I kept the design pretty simple, but got the streamline look. It actually looks quite nice when the player is advancing. I added victory animations for each character. When you are knocked down, the computer now has idle animation. I changed some of the background shades to create a 3D look. Again, Inspire8 inspired me! Wally B. was slowed down a bit. When you hit the computer, they now move a tad more to the left and right. EDIT: A bit of a bug snuck in when TKO'd. I will fix this KO_Cruiser___RC2___2009_02_26.bin

You could explicitly align all the players and missiles during vertical blank. Here is some excellent assembly code that I found on these boards a while ago. I don't know the original authors name. This subroutine will position any of the graphical objects on the screen in the specified column. You just need to assign the registers and JSR. Just note that the HMOVE is not cleared after the call. You need to clear it after horizontal blank is over. ;--------------------------------------------------------------- ; Subroutine: PosSprite ; ; In : a = position. ; x = sprite (0 = player 0, 1 = player 1, ; 2 = missile 0, 3 = missile 1, 4 = ball) ; ; Out : None ; ; Destroyed: A ;--------------------------------------------------------------- PosSprite STA HMCLR SEC STA WSYNC ; begin line 1 PosSpriteLoop SBC #15 BCS PosSpriteLoop ;+4/5 4/ 9.../54 EOR #7 ;+2 6/11.../56 ASL ASL ASL ASL ;+8 14/19.../64 STA.wx HMP0,X ;+5 19/24.../69 STA RESP0,X ;+4 23/28/33/38/43/48/53/58/63/68/73 STA WSYNC ;+3 0 begin line 2 STA HMOVE ;+3 RTS ;+6 9

No, I don't mind at all. I consider it a compliment that you think its worth hacking the game! I'll incorporate some of your modified player sprites into the final release. Wow! You turned a Wally B intro a Kangaroo! Sorcerer! SORCERER! Thank you. I might not be able to do that in the space allowed. All the behavior in the game is controlled by a virtual machine that that reads commands from a buffer. The Fight Engine can command the computer to move to X points: left of player, lined up with player, right of player, and half way between the current position and the current player. The Y points include back of ring, toe-to-toe, half back and right out of hit range. The player doesn't have this control. When the player is knocked out, the Fight Engine has the ability to add/subtract to target position of each. So, the script basically just subtracts from the computer's Y and adds to the Human Y and then loops to get the walking affect. I might be able to solve this, however, my one last-minute change. When the computer gets hit - he moves to the left and right. I plan to increase this number. I will do this! I have the primitives written already. Well, the ball control might get a tad difficult. The timing is incredibly tight during the face drawing logic. In fact, all 4 buffers (player0 pixel, color, ball control, color) read using the same index value.