Decent port of Street Fighter II possible?

[sandruzzo]

Originally Posted by Steril707

I think it depends on what can be achieved. If the game looks and plays reasonably similar, I don't see the problem in attempting a port, even if it looks a bit worse than in the arcade.
On the other side, games like Street Fighter 2 and Metal Slug are clearly over the A500s capabilities, and the result will probably be always unsatisfying.

SF2 even it seems impossible, with sprite redux can be made. Think about Elf mania

[ReadOnlyCat]

Originally Posted by Steril707

I think it depends on what can be achieved. If the game looks and plays reasonably similar, I don't see the problem in attempting a port, even if it looks a bit worse than in the arcade.
On the other side, games like Street Fighter 2 and Metal Slug are clearly over the A500s capabilities, and the result will probably be always unsatisfying.

Street Fighter II is perfectly within the capabilities of the OCS chipset.
Sure, there would be less colors and less background animations but characters sizes and animations can be identical to the arcade.

[Tigerskunk]

Originally Posted by ReadOnlyCat

Street Fighter II is perfectly within the capabilities of the OCS chipset.
Sure, there would be less colors and less background animations but characters sizes and animations can be identical to the arcade.

One fighter alone is around a couple of hundred of kilobytes.
I don't see how you could wrench this into the A500s meagre amount of RAM.

And when I talk OCS, off course i talk about the most typical config (A500 with 512k/512k).

[sandruzzo]

Originally Posted by ReadOnlyCat

Street Fighter II is perfectly within the capabilities of the OCS chipset.
Sure, there would be less colors and less background animations but characters sizes and animations can be identical to the arcade.

Think about with better copper usage, with less big enemies and screen area what could have been done!

[dlfrsilver]

Originally Posted by Steril707

One fighter alone is around a couple of hundred of kilobytes.
I don't see how you could wrench this into the A500s meagre amount of RAM.

And when I talk OCS, off course i talk about the most typical config (A500 with 512k/512k).

Sorry but no. Ryu SF2 alone is 800kb of data. on SSF2, Ryu is 1,5mb of data.

You need 4mb of ram at best to get the game with all the elements.

[Tigerskunk]

Originally Posted by dlfrsilver

Sorry but no. Ryu SF2 alone is 800kb of data. on SSF2, Ryu is 1,5mb of data.

You need 4mb of ram at best to get the game with all the elements.

I don't understand your "sorry but no". You are basically just restating what I wrote in my post.

Which is: the amount of RAM you need for a proper SF2 port is too big for an A500.

[saimon69]

Originally Posted by Steril707

I don't understand your "sorry but no". You are basically just restating what I wrote in my post.

Which is: the amount of RAM you need for a proper SF2 port is too big for an A500.

Or at least for an old-school, no-gotek no-HD no-A570 no-flashcard A500; if we store stuff in HD CD or flashcard then should be more doable with decently short loading times, however an optimization is definitely needed

[zero]

Originally Posted by Amigajay

Well yes, but no original console port had all the elements anyway, the Megadrive game came on a 3mb cartridge, whilst the PC Engine port was even smaller at 2.5mb, i believe without any bg anims you might be able to squeeze it into 2mb, well definitely if you reduce fighter sizes as we saw in SSF2TNC, but i guess any project like this is to prove fighter sizes could be full size whilst keeping anim frames?

Yep, the PC Engine port was the largest game ever made for that system at 2.5 megabytes, and it was damn near arcade perfect. Some slight reduction in graphical quality but all the gameplay was intact.

[Tigerskunk]

Originally Posted by saimon69

Or at least for an old-school, no-gotek no-HD no-A570 no-flashcard A500; if we store stuff in HD CD or flashcard then should be more doable with decently short loading times, however an optimization is definitely needed

Well, then why not simply use an 1200.

[ReadOnlyCat]

Originally Posted by Steril707

One fighter alone is around a couple of hundred of kilobytes.
I don't see how you could wrench this into the A500s meagre amount of RAM.

And when I talk OCS, off course i talk about the most typical config (A500 with 512k/512k).

Originally Posted by dlfrsilver

[snip]
Ryu SF2 alone is 800kb of data. on SSF2, Ryu is 1,5mb of data.

You need 4mb of ram at best to get the game with all the elements.

The raw memory size of the arcade data is not exactly representative of how much memory would be needed on the Amiga.

Taking the Chun-Li sprite sheet from the MegaDrive version as reference (cf attachment), there are multiple possible attack angles to reduce memory usage:

• Compressing the data is extremely effective.
  If you use the basic

  DEFLATE

  algorithm to compress it, the whole sheet only takes 75 KiB!
• There is a very large amount of redundancy in the sprite sheet:
  - the head is re-used as-is on a lot of poses
  - legs and hips are also frequently re-used between poses with small to minimal changes and if accuracy is sacrificed a bit they could be replaced for one another.

This sprite sheet (taken from here) is not complete but it is quite representative.

SF II is not exactly CPU intensive so there is plenty of time to decompress the needed sprite data in the background while playing animations, especially given that animation frames usually last several frames.

All in all, frankly, I am willing to bet a full kitten school that storing all sprite data is not a problem at all.

[mcgeezer]

Originally Posted by ReadOnlyCat

The raw memory size of the arcade data is not exactly representative of how much memory would be needed on the Amiga.

Taking the Chun-Li sprite sheet from the MegaDrive version as reference (cf attachment), there are multiple possible attack angles to reduce memory usage:

• Compressing the data is extremely effective.
  If you use the basic

  DEFLATE

  algorithm to compress it, the whole sheet only takes 75 KiB!
• There is a very large amount of redundancy in the sprite sheet:
  - the head is re-used as-is on a lot of poses
  - legs and hips are also frequently re-used between poses with small to minimal changes and if accuracy is sacrificed a bit they could be replaced for one another.

This sprite sheet (taken from here) is not complete but it is quite representative.

SF II is not exactly CPU intensive so there is plenty of time to decompress the needed sprite data in the background while playing animations, especially given that animation frames usually last several frames.

All in all, frankly, I am willing to bet a full kitten school that storing all sprite data is not a problem at all.

That sprite sheet mixes down to 72Kb when I take it down to 16 colours.... so taking out the crap it would probably fit into 64Kb.

Now given that there'll be a second fighter we can double that making 128Kb... for performance reasons we'll be doubling that as well... so 256Kb for sprites in chip ram at any one time.

Now SF2 has a screen area of roughly 640x256 pixels... and using 32 colour mode.. that would be... 80x256x5 = 102Kb... now you need to treble buffer it as well... so thats' well.. lets say 300kb chip ram.

Add music and sound fx... say.. 300Kb chip ram)

Game code probably 150Kb (fast ram or chip ram)

So:
Sprites = 256Kb
Scenes = 300Kb
Audio = 300Kb
Code = 150Kb
------------------
Total 1006 Kb..

So you'd need an OCS Amiga with 1mb Chip ram, standard ECS or AGA.

Can it be done justice on OCS.... just... ECS or AGA... 100% arcade port.

Geezer

[Don_Adan]

Originally Posted by mcgeezer

That sprite sheet mixes down to 72Kb when I take it down to 16 colours.... so taking out the crap it would probably fit into 64Kb.

Now given that there'll be a second fighter we can double that making 128Kb... for performance reasons we'll be doubling that as well... so 256Kb for sprites in chip ram at any one time.

Now SF2 has a screen area of roughly 640x256 pixels... and using 32 colour mode.. that would be... 80x256x5 = 102Kb... now you need to treble buffer it as well... so thats' well.. lets say 300kb chip ram.

Add music and sound fx... say.. 300Kb chip ram)

Game code probably 150Kb (fast ram or chip ram)

So:
Sprites = 256Kb
Scenes = 300Kb
Audio = 300Kb
Code = 150Kb
------------------
Total 1006 Kb..

So you'd need an OCS Amiga with 1mb Chip ram, standard ECS or AGA.

Can it be done justice on OCS.... just... ECS or AGA... 100% arcade port.

Geezer

Music can be much smaller, if no standard Amiga tracker will bu used. Some Amiga soundformats sounds very good and need only 10-20KB chip memory for samples and replay routine. F.e. Battle Squadron music, Hybris music, Music Assembler musics, Toki music etc but of course good old style musician is necessary. Samples perhaps can be played from fast ram too, dependent how many CPU time is free.Then this is almost possible for 0.5MB chip and 0.5MB fast. And seems to be possible for 1MB chip. Many Amiga games has more music/sfx for 1MB chip ram.

[sandruzzo]

With some sprites and background reductions, all is possible, and since it will use only 16 colors, we'll have a lot of spare ram

[ReadOnlyCat]

Originally Posted by mcgeezer

That sprite sheet mixes down to 72Kb when I take it down to 16 colours.... so taking out the crap it would probably fit into 64Kb.

The PNG was only 16 colors and compression usually takes very well care of unused bits per pixel so I doubt this would diminish that much.
Moreover, compression also likely eliminates redundancies across poses (as long as they are aligned on the same pixel boundaries).

Finally, keep it mind that this is the MegaDrive version and that it lacks a few animations. I think it would be reasonable t o expect a compressed size for the full sprite sheet of around 80Kb.

Originally Posted by mcgeezer

Now given that there'll be a second fighter we can double that making 128Kb... for performance reasons we'll be doubling that as well... so 256Kb for sprites in chip ram at any one time.

I suppose that by "performance reasons" you mean "flipping", right?
We actually do not need to store flipped versions of the sprites since one frame is more than enough to flip the currently used sprite on the fly. Moreover, as said before, the sprite change occurs over several frames anyway so we have ample time to flip by hand.
We could reserve a 128Kb flip table, but even that is not really necessary IMO.

So, we are at 80 * 2 = 160Kb.

Originally Posted by mcgeezer

Now SF2 has a screen area of roughly 640x256 pixels... and using 32 colour mode.. that would be... 80x256x5 = 102Kb... now you need to treble buffer it as well... so thats' well.. lets say 300kb chip ram.

Note: the screen resolution is 384×224 (so that would require horizontal overscan, and vertical overscan in NTSC but not in PAL). The screen scrolls horizontally and vertically so your numbers seem reasonable.
If some form of parallax scrolling is implemented (aside from the ground, which is trivial) that would also add to the requirements.

However, triple buffering does not seem warranted since the rendering budget of each frame should be relatively stable. Moreover this would add one frame of input latency which is very undesirable for a fighting game.

So, all in all I would also go for 300Kb of graphic RAM.

Originally Posted by mcgeezer

Add music and sound fx... say.. 300Kb chip ram)

The music is FM synth based so that would require relatively little memory but the samples are very likely to require a lot of space. It might be possible to compress them with ADPCM and decompress them on the fly though.

I will go with your figure but this might require more consideration.

Originally Posted by mcgeezer

Game code probably 150Kb (fast ram or chip ram)

Could be less since the main menu code can be quickly expunged from RAM once the fighters are selected and can be reloaded very quickly from disk if needed.

The total would be only slight lower than yours: 910 Kb. So ECS 1Mb indeed.

Originally Posted by mcgeezer

Can it be done justice on OCS.... just... ECS or AGA... 100% arcade port.

Where is the challenge on AGA?

Originally Posted by sandruzzo

With some sprites and background reductions, all is possible, and since it will use only 16 colors, we'll have a lot of spare ram

I do not think that 16 colors are enough to reproduce the quality of the original, even with Copper driven color changes.

At least 32 colors per scanlines seem required... at the minimum.

[Solo Kazuki]

All is about OCS/ECS "force reduction" instead AGA. Let's say about AGA version - it is possible to made game with much less reductions. After all, there is already ECS/OCS version of Street Fighter II, and obstinate fixing about OCS/ECS requirements will end with similar game...

[alpine9000]

In my opinion the biggest problem with a SF2 port for the Amiga is the woeful state of controllers on our platform. Must work with a one button controller!

[Solo Kazuki]

@alpine9000
Street Fighter II support 2 button joys, Super Street Fighter II Turbo even requires CD32 joypad. I don't understand what You mean...

[zero]

Originally Posted by alpine9000

In my opinion the biggest problem with a SF2 port for the Amiga is the woeful state of controllers on our platform. Must work with a one button controller!

Also the CD32 controller is a pain to read. It's very slow, requiring multiple slow operations to read all buttons. If it was back in the day and I was expecting big sales I'd think about using a parallel port adapter for Megadrive 6 button pads.

[Doma]

Originally Posted by Solo Kazuki

@alpine9000
Street Fighter II support 2 button joys, Super Street Fighter II Turbo even requires CD32 joypad. I don't understand what You mean...

To properly play SF2, you need a 4-button gamepad (plus shoulderpads, think snes). Most people (me inluced) played it with the standard zipstick back in the day.

Thats probably what he is talking about.

I did not know it supported a 2 button joy though. Might have to chech that out

[alpine9000]

Originally Posted by Solo Kazuki

@alpine9000
Street Fighter II support 2 button joys, Super Street Fighter II Turbo even requires CD32 joypad. I don't understand what You mean...

I guess what I’m saying is that the majority of people have one button sticks. A small percentage have two button sticks and a smaller still percentage have cd32 compatible pads.

This really limits the audience for an OCS game.