Beats of Fire

[RichAplin]

Originally Posted by dlfrsilver

Rich, just for the record, i guess that the funny way of running of the enemies in FF amiga is due to the fact that you had to remove some sprite frames right ?

Yep, as I'm sure you're aware I had to drop quite a lot of frames; I was pretty gutted to have had them in all their original-color, full-framed splendor and then drop so much, but... c'est la vie. I vaguely recall that remapping them into the final shared palette was the saddest bit.

Originally Posted by dlfrsilver

Oh by the way, Final Fight is using 256 colors Rich, and not more
even with multiple palettes system the game use

Are you sure about that? According to everything I can find (nowadays) CPS1 supports 192 palettes of 16 colors each (according to Wikipedia and even the MAME driver) = 3072 colors total.

You made me curious so...

Then looking at the CPS1 driver on
http://sourceforge.jp/projects/atmam...e/video/cps1.c
line 1509 is the sprite drawing stuff (not counting the background layers) which clearly uses 5 bits per sprite for the 16-color palette select (32 palettes x 16 colors) (line 1550)
Then it's using a separate 5-bit palette selector for each background tile layer (e.g. line 1236, line 1252, line 1291)..
..in total the "palette_basecolor" array has 6 entries, each of which gets a 5-bit index added to it, and 6x5=192 which corresponds to the 192*16=3072 colors described.

So... I'm not sure you're right there; the CPS1 hardware supports 512 colors (16 per tile) just for the sprites (without using any raster split tricks), including backgrounds, 3072 onscreen total.

Final Fight may just possibly have for some reason decided to use less colors than the hw supported but that sounds unlikely (and isn't quite how I recall it)

[nobody]

Yes it supports 3000 colors on screen. More colors means more work on sprites animations that's why they never used all. I suppose they had plenty artists doing their graphics though, it needs a huge work to make all that animations.

[dlfrsilver]

Originally Posted by RichAplin

Yep, as I'm sure you're aware I had to drop quite a lot of frames; I was pretty gutted to have had them in all their original-color, full-framed splendor and then drop so much, but... c'est la vie. I vaguely recall that remapping them into the final shared palette was the saddest bit.

Well, i perfectly understand what you mean. The main problem was that back in the day, Capcom artists and engineers were using the X68000 as workstation for the CPS-1, because it was the only computer able to produce this colorful graphics. the PC-98XX series from Nec were not yet able to display 256 colors.

So yes, the sharp computer was the machine that made it all happen, and no computer was up to the task back in 1991 to get the graphics perfect in their original format.

You'd had this machine you could have transfered the original graphics....

Are you sure about that? According to everything I can find (nowadays) CPS1 supports 192 palettes of 16 colors each (according to Wikipedia and even the MAME driver) = 3072 colors total. [/quote@

Yes this information is of course true. But a computer doesn't use multiple palette, it uses a unified palette. And all in all, on a VGA 256 colors machine, you can have the graphics exactly like the coin-op

Because the tools japanese used to make coin-ops had the ability to use splitted palettes, but originally no game is using more than 256 colors.
The only exception to this is Forgotten Worlds. Even when you unify the palettes to one, you can see the game use 512 colors.

You made me curious so...

Then looking at the CPS1 driver on
http://sourceforge.jp/projects/atmam...e/video/cps1.c
line 1509 is the sprite drawing stuff (not counting the background layers) which clearly uses 5 bits per sprite for the 16-color palette select (32 palettes x 16 colors) (line 1550)
Then it's using a separate 5-bit palette selector for each background tile layer (e.g. line 1236, line 1252, line 1291)..
..in total the "palette_basecolor" array has 6 entries, each of which gets a 5-bit index added to it, and 6x5=192 which corresponds to the 192*16=3072 colors described.

So... I'm not sure you're right there; the CPS1 hardware supports 512 colors (16 per tile) just for the sprites (without using any raster split tricks), including backgrounds, 3072 onscreen total.

for most games, i'm right. Why ? Because i have worked out in my head what you wrote in 1991 what you said in the FF startup-sequence.
The machine displays a lot of colors, more than 512. BUT, it's the way it works. Converting the GFX to a computer NEVER means that you have to keep the way the CPS1 arcade hardware engine works.

You have to deal with the assets like if they were never implemented for CPS-1. And what i did proved that i was right. If you have to cheat to get 256 unique colors max on screen, then do it When i get all displayed characters + backgrounds layers for a level, i never get more than 130 colors. So you can guess that there are really possibilities to work out something nice for the 1200

However, the amount colors forbids to me a port on A500 that should make the game justice. It's not a game made for a simple A500, even with 1mb of ram.

Just for information, DAMND, which is not the biggest character, weights alone something like 400kb. multiply by each character, plus backgrounds, plus the music and sound, no it can't be done good enough.

Such a game needs 4mb of RAM on a computer to be done correctly.

originally sprites + background never go higher than 256 unique colors.

Just to prove and illustrate what i say, i have fully ripped the final fight intro sequence with the original colors. If leathered want to use it, the whole graphics screens and animations are contained in a unique 64 colors palette, with NO loss of color. What i got is exactly what the arcade hardware shows on screen. This to say that converted with computer in mind, final fight can be done in 256 colors, that's way enough to get all the original colors. The multiple palettes slots are just an hardware assistance feature for the graphists.

By the way, the CPS-A-01 is dedicated to the program code hardware assistance, when the CPS-B-01 chip is dedicated to the GFX animation function hardware assistance. That's what i discovered by looking in the mame driver, and the CPS-1 video driver.

Final Fight may just possibly have for some reason decided to use less colors than the hw supported but that sounds unlikely (and isn't quite how I recall it)

Most CPS-1 games are not using the maximum colors, because while it's superior to any computer of this era, this system lacks of "memory" and "power" to do so. I have read this from one of the ex-guys of capcom arcade team, this system has incredible abilities, but it's plagued by a lack of RAM. Since one tile ref is working on word boundary, the 65535 bytes of ram are really short. (Just to illustrate, Final fight use a 512kb ROM of tiledata for the whole game (sprites, background, tile layers, whatever).

Just look at SSF2T, the conversion from the CPS-2 arcade hardware on A1200. Out of the fact it was rushed and beta when sold, it shows that an A1200 can do a game such as SSF2T very faithfully (again, 256 colors max). SSF2T is superior to FF in every possible way (each character use each 400 sprite frames => 800 all in all not counting the animations on the background.

[RichAplin]

Originally Posted by leathered

@ Rich: I guess the guy that was doing gfx for you (and as such yourself) had to face a similar compromise, but that must have been gutting for a single 16 colour palette, or did you have more options for each stage?

I really can't remember whether I ran Amiga FF in 4 or 5 bitplanes - most likely 5; however it's quite probable that I used 16 cols for sprites and 16 for the background (the former would have been constant throughout game, the latter would have changed per-level).... probably... on the other hand that would have made the ST port a PITA so.. shrug, dunno someone would have to fire it up in an emulator and check :-)

Either way it sure was a bummer to map down to so few colors having extracted pixel-perfect gfx (both for sprites and backgrounds) for the entire game :-( IIRC there were some parts of the background maps that were never used in the arcade game; because they used a tilemap-of-a-tilemap the full-size backgrounds were huge (in some cases with large blank areas) . That's how I got Jessica in her underwear in the intro btw; was in a background tile map.

Originally Posted by leathered

Some of the frames I got from Denis were repeats - so the arcade may have stored the gfx in a very different manner than what I am accustomed to with Amiga gfx

Yeah sprites are all tilemapped which makes repeated frames etc very inexpensive

[dlfrsilver]

Originally Posted by leathered

From my perspective and although I'm not sure about the original hardware specifics:
What is immediately obvious is that a lot of similar colours are wasted down to having a 16 colour sprite palette seemingly for every individual sprite, on top of the background palette. We've managed to eliminate a lot of the extraneous colour and come up with a palette for the characters with 9 extra for the backdrops. We've been using the copper to get more colours on these - the latest is Steve T's work above.
Pretty darn good for 5 bitplanes =)

@ Rich: Obviously you had to drop a lot of the frames as such after managing to 'decipher'. Some of the frames I got from Denis were repeats - so the arcade may have stored the gfx in a very different manner than what I am accustomed to with Amiga gfx, and perhaps graphics in general.

truth to be said, the tool they used to get the graphics on screen touched up and colored where scanned with the help of a scanner, then it was uploaded in the proprietary GFX tool. The japanese were using cartoon technic, applied to the video games. That's why the animations are so sharp and realistic. Once scanned, they retouched each animation frame, this making awesomely done games like SSF2, where all the guys are real life animated.

To achieve such a smooth animation, as well as good to look at, needed repetition. This is not useless frames, they're here to make the animations "alive", and very realistic.

then, there is another hardware trick :

Most sprites are 128x128. Ok. The other reason why final fight amiga enemies running animation seems so wrong out of the frames Rich had to remove, is that the animation inside the "128x128 boxes" are made independently.

In clear, the box is moving at a variable speed, and the sprite displayed inside the "128x128 box" the speed is not the same as the one of the box.
That's the secret behind the incredible way the sprites are animated.

To replicate this, you need to make it like this : "4 sprites frames displayed and animated inside the 128x128 box THEN move the box itself 16 pixel right (or left). this makes you think the character is perfectly walking on the ground, exactly like how a human would do.

[dlfrsilver]

Either way it sure was a bummer to map down to so few colors having extracted pixel-perfect gfx (both for sprites and backgrounds) for the entire game :-( IIRC there were some parts of the background maps that were never used in the arcade game; because they used a tilemap-of-a-tilemap the full-size backgrounds were huge (in some cases with large blank areas) . That's how I got Jessica in her underwear in the intro btw; was in a background tile map.

Jessica's in underwear, and the tiles you say are unused, are used by the japanese code program, not the US or the WORLD release .

Nice for us, the japan version is the best ahah

By the way, which tool and how did you ripped all the background and sprites with their palettes on amiga ? Because when i see the time it took me to process just one sprite with all its frame (8 hours for only one !).

Can you hint me on this matter ?

Yeah sprites are all tilemapped which makes repeated frames etc very inexpensive

You bet it is the 68000 is churning 8kb of tiledata for one enemy sprite to the Video Display Processor. The 68000 never moves any graphic tile.
Tiles are positioned and moved by the VDP, so our dear 68000 never sweat, out of the game logic it has to deal with.

[nobody]

Originally Posted by dlfrsilver

truth to be said, the tool they used to get the graphics on screen touched up and colored where scanned with the help of a scanner, then it was uploaded in the proprietary GFX tool. The japanese were using cartoon technic, applied to the video games. That's why the animations are so sharp and realistic. Once scanned, they retouched each animation frame, this making awesomely done games like SSF2, where all the guys are real life animated.

Correct, draw large scale first, usually on hand then pass to PC, colorize and resize to whatever size needed.
Example with similar techniques but using modern programs.

http://2dwillneverdie.com/tutorial/t...g-of-el-zombo/

[leathered]

@ Rich Aplin and Denis: Thanks to both of you for resurrecting something that I had deleted out of apparent drunkenness! I kind of needed that verification that I'm not just talking rubbish I guess...

Originally Posted by RichAplin

That's how I got Jessica in her underwear in the intro btw; was in a background tile map.

Well done. =)

Originally Posted by dlfrsilver

In clear, the box is moving at a variable speed, and the sprite displayed inside the "128x128 box" the speed is not the same as the one of the box.
That's the secret behind the incredible way the sprites are animated.

To replicate this, you need to make it like this : "4 sprites frames displayed and animated inside the 128x128 box THEN move the box itself 16 pixel right (or left). this makes you think the character is perfectly walking on the ground, exactly like how a human would do.

For the last paragraph - I don't think there is any other way to animate a moving object?
However, moving an object at a variable speed according to the frame of an animation> is perhaps something I will look into. Even so, I'm not sure that's what you mean!

Originally Posted by dlfrsilver

Just to prove and illustrate what i say, i have fully ripped the final fight intro sequence with the original colors. If leathered want to use it, the whole graphics screens and animations are contained in a unique 64 colors palette, with NO loss of color.

Already done my friend, although I am interested in what you have to show!

Originally Posted by dlfrsilver

Just look at SSF2T, the conversion from the CPS-2 arcade hardware on A1200. Out of the fact it was rushed and beta when sold, it shows that an A1200 can do a game such as SSF2T very faithfully (again, 256 colors max). SSF2T is superior to FF in every possible way (each character use each 400 sprite frames => 800 all in all not counting the animations on the background.

The biggest difference between the 2 games (aside from the obvious) is that there are only 2 characters on screen for SF2. In fact I perceive that Final Fight is a far more difficult game to fit into the Amiga in this respect (of course I may be mistaken).

Each character for Final Fight using 400 animation frames - yes but these as such are not individual. Taking out the duplicates leaves more like 80 or less for most characters.
I do not store the gfx as tiles but rather the entire frame. It would take a real coder to sort that lot out! =) I'm animating according to the frame numbers once they have been allocated - remember that for blitz there are a total of 1024.

[dlfrsilver]

Yes, the multiple sprites are indeed the problem, you're right ^^. About FF intro scenes, you have my work already, don't you remember ?

and about the animations, you understood correctly what i said

[RichAplin]

Originally Posted by dlfrsilver

By the way, which tool and how did you ripped all the background and sprites with their palettes on amiga ? Because when i see the time it took me to process just one sprite with all its frame (8 hours for only one !).

Mmmm nothing super-special; I wrote a program (on A500+A590 HD+2mb ram) to do the background+sprite tile->bitmap processing and (later) color remapping; in fact I wrote a bunch of programs. I don't think any of it took a long time to run; not super processor-intensive. I did obvious stuff like automatically reframing the bitmapped versions of the sprites; in fact (again IIRC) I think I may have auto-sliced them horizontally into a few separate sections so that stuff like outstretched arms/legs didn't mean I ended up with tons of blank pixels in a giant bounding rectangle. Again this was like 25 years ago so it's a bit vague...

Most of the hassle was finding and decoding the tile maps (and maps of tile maps) in the code roms, which I recall took a good chunk of time; I seem to vaguely recall the background maps were runlength encoded as well... however once I got a few things working it became an addiction to get it all figured out. It was SO rewarding to get all the parallax layers pulled out and just scroll around them :-)

Obviously I couldn't display everything in its true full-color splendor on an A500 but IIRC I had a tool where I could switch it to display the right palettes for certain areas of the screen.

Yeah I'd totally forgotten about the animation positioning stuff; if I recall there was some extra metadata in the rom on how to move the hardware sprite blocks to make the feet stick to the ground properly(?) something a bit unusual about it anyway. Because I had to chop lots of frames out I think I just manually redid it by eye :-(


BTW my point earlier about how MAME would've been a godsend; I was referring to the ability to run & breakpoint the game code on memory accesses so you could see which bits of code were depacking/writing the sprite+bg tile maps to VRAM (and see where the palettes came from) - that would've saved me a bunch of time...

[dlfrsilver]

Final fight is not using at all any compression inside the code. I got access to the tiledata of sprites and background without doing any decompression operation on the arcade program code.

And while the CPS1 is a powerful hardware, NONE of the games running on it use compression. It's too tight already in RAM for that. In some games, the fun thing when you look at the game code, is that you can almost see some sprite patterns in tiledata words XD !

It's a shame however that you have nothing left out (nor amiga nor your programs )

[Steve T]

Interesting info about the walk cycles... walk animation recycles after 4 frames, and moves a character 16 pixels through the sprite, at which point it resets to the first frame, and moves the sprite 16 pixels in the direction of travel, so the animation will join up seamlessly with the previous cycle?

[dlfrsilver]

When i said 4 frames, it was to illustrate. It's maybe a bit more or a bit less in fact. But this is how it works. The sprites animation is decoupled from the box it's contained in.

[Steve T]

yes, it sounds like a very good approach, so the walk cycle can be implemented exactly as the animator intended.

[Shatterhand]

Hi! :-) Thought I'd swing by to see how it's going, maybe read some more abuse, that kinda thing.

It looks like you look at the abuse with some light-heart approach

It's always awesome to have people who were in the biz back at the time around here, even if it's a guy who worked in a game a lot of people hoped would be better

I've read a few interviews with you, I find funny how you seem to not enjoy scrolling beat'em ups but ended up working on the ports of both Double Dragons and Final Fight on Amiga

I've barely played Double Dragon 1, but I find funny that DD2 and FF on Amiga have similar control schemes and similar problems in the gameplay. I really think the fact you don't like this kind of game says a lot about it. If you can't grasp what makes those games good (And I can understand someone not liking this type of game, while loving Shinobi, which was an awesoem game ), you will easily miss it when doing a port for a lesser machine. I'd prefer smaller/less colorful graphics for better gameplay anyday. Golden Axe, for example, it's a game that isn't half as good as Final Fight on arcades, but the Amiga version kept most of its gameplay very close to the arcade one. I don't know if you've ever seen the port of Super Street Fighter 2 on Amiga. It looked a lot worse than the arcade version (and when I say I lot, I really do mean * A LOT * ), but the gameplay was very, very, very close to the arcade version, so I was very satisfied with it. It still felt like a lousy job, like it could have been done better, but as long as the gameplay is good, I am satisfied.

I never thought Final Fight was badly programmed at all, but I really do think it lost everything the arcade game had of good on its gameplay. It really felt as you didn't know how to make a good beat'em up (or, like I said before, didn't had the time to polish it). The lack of music was really bad too (even more when the Atari ST version actually had music), but I've recently read you actually wanted to put music on the game, but no one gave you music to insert into it.



I see a lot of talking about the CPC version of Shinobi. I never owned a CPC, so I don't know how good it is (The Amiga version was awful), but I promise I'll check it out on an emulator.

Just wanted to show some respect after the abuse. You guys working on developing games back at that time were heroes. I do work with game development nowadays ,and the tools we have today make everything a lot easier. I love to read experiences from people back at the time. I hope you didn't find anything I said about your Amiga games disrespectful. Even if I didn't like any of your Amiga games and used some harsh words to talk about Amiga Final Fight, I have all the respect for people working on games at that time, and I should've used better words to talk about your work.

[dlfrsilver]

the fact is that the japanese had already back in 1987 the tools that makes things easier for you today. They not only had 15 years ahead from us, but they also had superior hardware and superior tools.

When you look at a japanese shmup, the guy had already the ability to check the sprites patterns on screen ! He could then tweak it, modifiy it, and check it right away on his screen XD !

When in europe the coder had to modify the thing and generate a new assembled program each time a modification was done, the japanese did what he wanted on screen, outputed the new pattern, and the coder just had to incorporate those in the code, and then assemble it.

[leathered]

Originally Posted by dlfrsilver

Yes, the multiple sprites are indeed the problem, you're right ^^. About FF intro scenes, you have my work already, don't you remember ?

and about the animations, you understood correctly what i said

I don't appear to have any gfx from the intro in the main folder you sent or recall ever seeing them.
I got the gfx in my roughneck way and converted everything to 64 colours with a consistent palette for the fonts. Turrican3 later ripped the gfx better and used the palette to adapt elements of the megacd intro which I may use when I eventually get around to doing that.

By the way, the animation method you suggested is I'm sure an interesting and cool way to go about it, I've considered doing that before and may well try to implement it in the future! But it's definitely not the method used by Capcom for Final Fight. =)

[AnimaInCorpore]

IMHO Richard did a good job with the conversion. Except for some polishing the port is technically quite perfect in respect to the given limitations.

[dlfrsilver]

Originally Posted by leathered

I don't appear to have any gfx from the intro in the main folder you sent or recall ever seeing them.
I got the gfx in my roughneck way and converted everything to 64 colours with a consistent palette for the fonts. Turrican3 later ripped the gfx better and used the palette to adapt elements of the megacd intro which I may use when I eventually get around to doing that.

By the way, the animation method you suggested is I'm sure an interesting and cool way to go about it, I've considered doing that before and may well try to implement it in the future! But it's definitely not the method used by Capcom for Final Fight. =)

It's the method used in Final Fight by capcom. It's not evident first hand, but when you look carefully, you see that the animation and the box speed moving are decoupled. Look how different it is from any amiga or even console animation.

[leathered]

Originally Posted by dlfrsilver

It's the method used in Final Fight by capcom. It's not evident first hand, but when you look carefully, you see that the animation and the box speed moving are decoupled. Look how different it is from any amiga or even console animation.

Analyse the actual movement a little closer and you will see the animation frames are actually moving even when not 'animated', which would not be the case if what you were saying is true. In other words, they are being moved and animated at the same time. Virtually every game I've ever seen uses a similar method for animation.

Consider also this: If the technique you describe is true, the player sprites would need to be offset with every frame of animation as the background scrolls underneath them, or when they are stuck against an object and cannot move - where the animation continues. Consider also when the character walks up the screen - moonwalking all the way =).