13 January 2015, 23:33 | #421 | ||
Registered User
Join Date: Oct 2008
Location: san francisco/usa
Posts: 176
|
Quote:
Quote:
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) |
||
13 January 2015, 23:43 | #422 |
Registered User
Join Date: Dec 2013
Location: GR
Age: 47
Posts: 1,416
|
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.
|
14 January 2015, 00:35 | #423 | ||||
CaptainM68K-SPS France
|
Quote:
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.... Quote:
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. Quote:
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. Quote:
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. |
||||
14 January 2015, 00:37 | #424 | |
Registered User
Join Date: Oct 2008
Location: san francisco/usa
Posts: 176
|
Quote:
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. Yeah sprites are all tilemapped which makes repeated frames etc very inexpensive |
|
14 January 2015, 00:44 | #425 | |
CaptainM68K-SPS France
|
Quote:
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. |
|
14 January 2015, 00:51 | #426 | ||
CaptainM68K-SPS France
|
Quote:
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 ? Quote:
Tiles are positioned and moved by the VDP, so our dear 68000 never sweat, out of the game logic it has to deal with. |
||
14 January 2015, 00:51 | #427 | |
Registered User
Join Date: Dec 2013
Location: GR
Age: 47
Posts: 1,416
|
Quote:
Example with similar techniques but using modern programs. http://2dwillneverdie.com/tutorial/t...g-of-el-zombo/ |
|
14 January 2015, 00:54 | #428 | ||||
Registered User
Join Date: Oct 2011
Location: UK
Age: 47
Posts: 304
|
@ 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...
Quote:
Quote:
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! Quote:
Quote:
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. Last edited by leathered; 14 January 2015 at 01:35. |
||||
14 January 2015, 01:38 | #429 |
CaptainM68K-SPS France
|
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 |
14 January 2015, 02:26 | #430 | |
Registered User
Join Date: Oct 2008
Location: san francisco/usa
Posts: 176
|
Quote:
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... |
|
14 January 2015, 03:29 | #431 |
CaptainM68K-SPS France
|
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 ) |
14 January 2015, 10:05 | #432 |
Registered User
Join Date: May 2013
Location: UK
Age: 44
Posts: 351
|
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?
Last edited by Steve T; 14 January 2015 at 10:17. |
14 January 2015, 12:52 | #433 |
CaptainM68K-SPS France
|
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.
|
14 January 2015, 13:09 | #434 |
Registered User
Join Date: May 2013
Location: UK
Age: 44
Posts: 351
|
yes, it sounds like a very good approach, so the walk cycle can be implemented exactly as the animator intended.
|
14 January 2015, 14:23 | #435 | |
Warhasneverbeensomuchfun
Join Date: Jun 2001
Location: Rio de Janeiro / Brazil
Age: 41
Posts: 3,450
|
Quote:
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. |
|
14 January 2015, 16:01 | #436 |
CaptainM68K-SPS France
|
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. |
14 January 2015, 16:29 | #437 | |
Registered User
Join Date: Oct 2011
Location: UK
Age: 47
Posts: 304
|
Quote:
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. =) |
|
14 January 2015, 18:55 | #438 |
Registered User
Join Date: Nov 2012
Location: Willich/Germany
Posts: 232
|
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.
|
14 January 2015, 19:53 | #439 | |
CaptainM68K-SPS France
|
Quote:
|
|
14 January 2015, 20:38 | #440 | |
Registered User
Join Date: Oct 2011
Location: UK
Age: 47
Posts: 304
|
Quote:
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 =). Last edited by leathered; 14 January 2015 at 20:53. |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Beats of Rage engine for OCS/ECS. | Toni Galvez | Amiga scene | 17 | 12 January 2015 01:58 |
Absolutely NOTHING Beats The Real Thing | Amiga1992 | Retrogaming General Discussion | 24 | 18 February 2014 11:35 |
Beats of Rage OS4.x | fitzsteve | Retrogaming General Discussion | 1 | 23 December 2011 00:09 |
You know it really beats the hell out of me !! | synchro | Amiga scene | 6 | 11 May 2006 16:01 |
WinUAE - HD, and WinUAE Beats me | Mr.B | support.WinUAE | 19 | 26 October 2003 17:49 |
|
|