Decent port of Street Fighter II possible?

[Tigerskunk]

Not so sure about blitting two 64x80 wide objects in 5bpl and flipping them in real time in one frame, to be honest.

I think you are too optimistic here..

[trixster]

If the stipulation is it must only work with one or two button joysticks then you may as well not bother. SF2 without 4 (preferably 6) buttons is a woeful experience.

[Tigerskunk]

I'd rather prefer porting Yie Ar Kung Fu (which would be easy), or creating something completely original that works within the Amigas technical boundaries.

But this is not the topic of this thread....

add/edit: had something cooked up three years ago, when I started coding for the Amiga. But then went for creating a shmup instead:
[ Show youtube player ]

[viddi]

We already have a very good Street Fighter 2 port on the Amiga: SSF2 AGA.

Boo Boo (Retro1234) and I managed to edit the original background pics.
Check out these threads:

http://eab.abime.net/showthread.php?t=40447

http://eab.abime.net/showthread.php?t=41499


Why not replace the old backgrounds once again with even better ones?

[mcgeezer]

Originally Posted by Steril707

Not so sure about blitting two 64x80 wide objects in 5bpl and flipping them in real time in one frame, to be honest.

I think you are too optimistic here..

Totally agree... potentially byte flipping 3.2Kb every frame would make an Amiga cry.

In my calculations I didn't realise it was only one set of sprites in a direction, double my sprite estimates then so this makes it AGA only.

alpine9000 is right though... the buttons available would hamper the game.

[alpine9000]

Originally Posted by Amigajay

Another Commodore muck-up imo, their Amiga gaming bundles (always their biggest sellers) from 1991 onwards should have included at least a joypad with 2-3 buttons with a new revision to 7 buttons in 92/93 to push developers to support more buttons, a factor that was always maligned in the gaming press, when it came to Amiga games still using up for jump in 1994, and something Commodore should got behind, they wanted bigger sales but never really got ‘it’ and expected some magical 3rd party to supply the whole userbase with one.

The fact they bundled games like Dangerous Streets and Dennis in later bundles when their earlier gaming bundles were so much better proved they were stuck in 1990/1991 with their one button joysticks!

And as zero mentioned above, even when they did create a multi button pad, it’s a massive pain to read it. Reading all buttons for two cd32 pads is something like 10 scan lines.

[Master484]

Where is the challenge on AGA?

Indeed, I think one could easily port this game to AGA, even with Blitz Basic.

Just released a new Blitz SF2 graphics demo:
http://eab.abime.net/showthread.php?t=96990

[chb]

Originally Posted by mcgeezer

Totally agree... potentially byte flipping 3.2Kb every frame would make an Amiga cry.

I'd tend to disagree. First, while character movement is at steady 50 Hz, the animation is not, so flip to a buffer and blit from that buffer multiple times. Maybe store most often used frames in both directions (walking, jumping, block etc.), or even the first frame of every special move to reduce latency. Second, you can store one half of the sprite (e.g. the lower) in one direction and the second half in the other, halving the time needed for the worst case (average case stays the same). Third, using a 128k flip table flipping a word needs 38 cycles, so even flipping at 50 Hz would just about be possible in 16 colors without much else going on (3200*50*38 = 6.08e6 1600*50*38 = 3.04e6 cycles) - but as said above, there's no need to flip at 50 Hz.

Don't get me wrong, I do not think that's easy with all the other stuff going on, but not completely out of reach for an A500 with some compromises.

[roondar]

I've thought about a better SFII port a while back and my idea was to have a number of 'key frames' for the fighter animations and pre-calculate the delta between these frames and the next ones in sequence. Either on a 16x16 grid base, or on a complete fighter base*.

Then, during the game you'd 'unpack' those delta's in real time. This might be a complicated affair, but it seemed doable to me from a Blitter/CPU overhead. Mind you I was targetting an A1200 AGA version using Dual Playfield.

In my idea, I reserved 1 playfield for the background and 1 for the 1st fighter. The second fighter plus 'foreground objects' would be done using sprites. The background layer would either not have parallax or soft parallax only. It would occasionally be required to mask parts of the sprite out to show the opponents fists or feet, but this is generally limited to a small portion of the fighter.

This would allow 15 colours per fighter, plus a 'decent' looking background. Crucially, using the Dual Playfields + sprites like this makes for a very low overhead for displaying the fighters (essentially all blitting required for the fighters could be done in copy mode - cookie cut mode would only be needed for the small masking areas).

Even two 192x256 fighters should easily be doable in a frame this way.

I got sidetracked so never actually put the idea to the test, but I'm pretty certain it would've worked from a performance point of view.

*) Alternatively, make a bunch of 16x16 tiles to build the fighters from. This will also lower memory pressure significantly.

[sandruzzo]

Why don't start from GBA version?

https://www.spriters-resource.com/ga...ance/sfalpha3/

https://www.spriters-resource.com/ga...fighter2turbo/

[Tigerskunk]

I often read in these "Street Fighter 2 remake" threads that people want to use sprites and bobs mixed up for the two fighters.

Wouldn't you basically need a "sprite" and a different "bob" sheet for that?
I mean, you usually keep your BOB data (for 16 colours) 4bpl interleaved, and the sprite data would need to be 2x 2bpl interleaved.

How do you circumvent to need to juggle two different sprite/bob sheets in that case?

[roondar]

Originally Posted by Steril707

I often read in these "Street Fighter 2 remake" threads that people want to use sprites and bobs mixed up for the two fighters.

Wouldn't you basically need a "sprite" and a different "bob" sheet for that?
I mean, you usually keep your BOB data (for 16 colours) 4bpl interleaved, and the sprite data would need to be 2x 2bpl interleaved.

How do you circumvent to need to juggle two different sprite/bob sheets in that case?

Well, like I said, I haven't actually made it but my idea on this is as follows:

You keep just one sheet (for bobs is probably easiest) and convert to sprite data in real time when loading. Should be fairly easy to do.

[Tigerskunk]

Sounds reasonable...

[LaBodilsen]

Originally Posted by chb

Second, you can store one half of the sprite (e.g. the lower) in one direction and the second half in the other, halving the time needed for the worst case (average case stays the same). Third, using a 128k flip table flipping a word needs 38 cycles

I like the Idea of flipping top and bottom, so worst case will always only need to flip half the sprite.

Using a table, would that mean you will flip the sprite with the Cpu?, why not use the blitter, flipping a wordstrip can be done in 4 passes with the blitter.

[chb]

Originally Posted by LaBodilsen

I like the Idea of flipping top and bottom, so worst case will always only need to flip half the sprite.

It's from some thread on eab, I didn't come up with it. But I like it, too.

Originally Posted by LaBodilsen

Using a table, would that mean you will flip the sprite with the Cpu?, why not use the blitter, flipping a wordstrip can be done in 4 passes with the blitter.

Yep, I think blitter is slower than using a word table - depends on available dma time. It's four passes with two sources, so for every word 12 memory accesses or 24 cpu cycles in the best case*, but slower when e.g. display dma is taking its share. CPU is 38 cycles, but only 7 memory accesses and is less affected by dma, and no blitter setup time. But needs 128k table. Hmmm. Best choice probably depends on whether you have rather cpu or memory cycles to waste. And 128k is maybe more than you save by not storing both directions.

*http://eab.abime.net/showpost.php?p=...&postcount=248 - not sure if it's 100% correct.

[Tigerskunk]

Originally Posted by chb

And 128k is maybe more than you save by not storing both directions.

Sounds so.

[sandruzzo]

What about IK+ 2019? Would be great pushing amiga at is limit!

[chb]

Originally Posted by Steril707

Sounds so.

Yeah, but it's not chip ram.

[Tigerskunk]

Originally Posted by chb

Yeah, but it's not chip ram.

Plus, this would work on both sheets. So in the end you are probably ending up with less needed RAM in the end.

[mcgeezer]

Originally Posted by sandruzzo

What about IK+ 2019? Would be great pushing amiga at is limit!

What about it? I wouldn't be using an Archer Maclean game as an experiment.