Street Fighter 2 GFX Test

[Master484]

I can give you any arcade asset from the arcade if you need it Master484.

I know, but it's still better to wait before ripping any GFX from the arcade.

I already have the US Gold version graphics from Codetapper's website, and I can make the first playable demo with them. And I can easily "emulate" the drawing stress of the arcade character sizes by simply making the BOB image areas bigger; so the actual arcade graphics files aren't yet needed in this experimentation phase.

And when or if the playable demo is one day ready, then we can make more accuracte plans on what size gfx to use, and what stuff needs be ripped from the arcade.

---

Also 25 FPS, although an acceptable frame rate for 128 colors, isn't really ideal for a game like this. So I'll make further tests to see if I can make this run at 50 FPS, without sacrificing the color amount and screen size too much.

Yesterday I just noticed that using 32 pixel fetch mode instead of the 64 pixel fetch mode actually freed 4 sprite channels, which could be used for two 64 pixel wide 16 color sprites. Which is good, but if the characters are in 64 colors, then the 16 color sprites can't be used for them.

But I'll experiment more to see if more sprite channels can be made available somehow, and also I'll test how things would look in 64 color mode, with some kind of combination of 48 color backround and 16 color BOBs and sprites; that might even run at 50 FPS, which would be awesome.

[Samurai_Crow]

Fireballs could be sprites. They could be 7 foreground colors or so.

[Master484]

Fireballs could be sprites. They could be 7 foreground colors or so.

Yes that's one use for the sprites, especially if I can only display two or three of them on the screen.

Although I made some tests, and it seems that by disabling the larger AGA fetch modes and smooth scrolling, and decreasing the screen size to 288 pixels, I could display four 64 pixel wide sprites in 16 colors, in a 128 color mode screen.

But this had the side effect of being able to draw only 6 fireball BOBs at 50 FPS before slowdown. But of course the characters themselves could now be made with the sprites, because two 64 pixel wide sprites are enough for one character. Although this would mean a shared 16 color palette for all characters, while the backgrounds would be 64+ colors, but this might be OK if the game ran at 50 FPS, as it most likely would thanks to both fighters being sprites.

But I'll experiment further to see what would be the best solution.

Originally Posted by Master484

Yes that's one use for the sprites, especially if ...but this might be OK if the game ran at 50 FPS, as it most likely would thanks to both fighters being sprites.

Hi Master484, the demo ADFs looked great, anything playable at all would be really cool at this point - have you seem the MSX 8-bit version of SF2 done for a gamedev compo a couple of years ago? [ Show youtube player ]

As you can see it does without character shadows and no screen scrolling! MSX hardware has notorious shortcomings regarding screen scroll, so it was preferred to skip this part and even so, I have to say, the gameplay is solid enough and I dare say it plays more like SF2 than any of the official Amiga ports we had. So, at this point the mighty Amiga is behind a 8-bits computer regarding SF2... Something should be made regarding this.

[Faserone]

Hi,

Quite interesting work. I am pretty sure we can get close to the arcade version because honnestly Us Gold version doesn't honor the system. I hope a demo can be made to show what could have been done.

[ Show youtube player ]
[ Show youtube player ]
[ Show youtube player ]
[ Show youtube player ]

YS

[Retro1234]

This was a good project any news?

[Master484]

This was a good project any news?

Not really. This was just a simple SF2 graphics test for A500, and any attempts to make an actual game were abandoned.

However, some time ago I made another SF2 test, this time for A1200, using dual PF and sprites from the SNES version. If you haven't seen it yet, then check it out:
http://eab.abime.net/showthread.php?t=96990

[Retro1234]

Is it ok to poke around and maybe ask a few questions about the code?

What effect do you think it would have on speed vs memory to have the sprites stored split into pieces as they were on the original?

http://codetapper.com/amiga/rips/street-fighter-2/

:looking at these sprites it doesn't look like combining different combinations of Tops and Legs
creates more frames does it? and I thought this was the point to slice up the graphics

[roondar]

Storing sprites split into pieces that are aligned vertically (for instance a 16 pixel high strip of a sprite, followed by another 16 pixel high strip, etc) shouldn't have much of an impact. You might need a few more blits or a slightly more complicated hardware sprite setup, but that overhead should be pretty small.

Doing the same horizontally (i.e. 16 pixel wide strips) would be much worse for performance. This is due to the way the Blitter does it's drawing: it always draws on 16 pixel boundaries and needs to use shifts to draw on non-16 pixel boundaries. But those shifts mean the Blitter has to draw an extra 16 pixels. You can sometimes get around it, but most games just draw the extra 16 pixels all the time.

Perhaps this example makes it more clear:
To draw a 64x16 bob at any given coordinate you like, you make the Blitter draw 80x16 pixels. The extra 16 are for the shift I mentioned.
To draw 4 bobs of each 16x16 (which is the same size), you make the Blitter draw 128x16 pixels. The extra 64 pixels are the 16 pixels for shifting each of the four separate objects.

So, if you split up a bob/sprite in multiple segments, it's best to do this so that you have the full width every time.

[Rochabian]

As there is many people who dreams about a decent SSF2T on amiga ,many threads about this game, and there is such talented coders with lots of ideas, what about making an open source contest for the best SSF2T tech demo ( or full game ) .
I think ideas or code parts could be better known for those who are interested in and can motive some guys who have left their projects because they where stuck on some parts .

It could also be a starting point to know wich language and tricks to use to do such a game, and can motive to begin a new project

[DamienD]

Personally I just don't think it's worth the trouble, or indeed the many, many years it would take for very competent programmers who knew the system inside out...

Street Fighter II, or any in the series will never be good on the Amiga for various reasons; mainly the controls / lack of buttons but also regarding just how difficult it would be to get arcade perfect, even on ultra high spec Amigas.

This is never going to happen in reality, sorry guys.

Just play via MAME; end of

[roondar]

The lack of buttons is essentially a fixed problem these days - just attach a Mega Drive or Playstation to Amiga adapter and use CD32 pad mode. That should be enough buttons

As for playability - I think that's were the real challenge lies and I'm inclined to agree with DamienD on that. Too much time needed to get it right.

Hardware wise: if you can accept a compromise or two (i.e. target AGA and run it in Dual Playfield mode, accept the 15+16 colour graphics), it should be doable even without super in depth Amiga knowledge. An AGA Amiga such as the A1200 can display two Street Fighter 2 character sized objects and update them each frame with plenty of raster time to spare.

So, if you want arcade perfect down to the pixel: DamienD is right, the Amiga won't manage. If you can accept a "console level port", it's probably feasible. Is this worth it? Depends on who you're asking. Some think ports that are less than perfect are useless, others like the idea of seeing how far the hardware can be pushed to get as close as possible. I lean towards the second of those two.

[Master484]

What effect do you think it would have on speed vs memory to have the sprites stored split into pieces as they were on the original?

If the sprites are split like that, then they take less Chip ram, but drawing speed is somewhat slower.

The amount of memory saved by this would vary depending on the character, but I would estimate around 20 % memory save, maybe slightly more in some cases.

And the speed loss would be maybe 5 % to 10 %, depending on how the splits are done, and how many pieces there are. But having just 2 big pieces like the US Gold SF2 has would still be fast.

And sometimes the splitting can actually speed things up. For example look at the Balrog "super punch" frame: it would be a huge blit if drawn as a whole, but when split the overall bob size is a lot smaller, saving both memory and making it faster to draw.

looking at these sprites it doesn't look like combining different combinations of Tops and Legs
creates more frames does it? and I thought this was the point to slice up the graphics

It can be hard to notice, but they do create more frames.

For example look at the E.Honda sprite sheet: he has many different punch animations, many of which use the same leg parts.

Also some of these splits simply make big frames smaller: for example hands, feet or heads are "cut" from the main image to make the frame smaller, or torsos are separated from the bigger leg parts.

[saimon69]

Originally Posted by DamienD

Personally I just don't think it's worth the trouble, or indeed the many, many years it would take for very competent programmers who knew the system inside out...

Street Fighter II, or any in the series will never be good on the Amiga for various reasons; mainly the controls / lack of buttons but also regarding just how difficult it would be to get arcade perfect, even on ultra high spec Amigas.

This is never going to happen in reality, sorry guys.

Just play via MAME; end of

They said that also of Outrun, and then FedePede04 happened - ok, is recovering from an injury now and not working on it, but whatever will come out from that remix will be better than the US Gold original!

At the end i think what we want is a playable version, has not necessarily to be one-frame-super-wonder!

[Retro1234]

Originally Posted by Master484

If the sprites are split like that, then they take less Chip ram, but drawing speed is somewhat slower.

The amount of memory saved by this would vary depending on the character, but I would estimate around 20 % memory save, maybe slightly more in some cases.

And the speed loss would be maybe 5 % to 10 %, depending on how the splits are done, and how many pieces there are. But having just 2 big pieces like the US Gold SF2 has would still be fast.

And sometimes the splitting can actually speed things up. For example look at the Balrog "super punch" frame: it would be a huge blit if drawn as a whole, but when split the overall bob size is a lot smaller, saving both memory and making it faster to draw.

It can be hard to notice, but they do create more frames.

For example look at the E.Honda sprite sheet: he has many different punch animations, many of which use the same leg parts.

Also some of these splits simply make big frames smaller: for example hands, feet or heads are "cut" from the main image to make the frame smaller, or torsos are separated from the bigger leg parts.

Thanks for the reply ok so it does save frames I'll try at some point to find the data in the original game to piece them together.

Also saving chip ram these frames could be stored in reverse? Is there enough memory for that 1mb only

I'm only interested in the ECS version but as you found out from your AGA tests I believe an AGA version could be very very good because the Characters can be displayed as "sprites* not Bob's.
And Super Street Fighter 2 already shows that the gameplay is possible.

It might be possible to rip the AI from the Arcade version or Amiga Super Street Fighter 2

[Master484]

Also saving chip ram these frames could be stored in reverse? Is there enough memory for that 1mb only

The short answer is no. Storing both left and right versions of characters of this size would still take too much Chip RAM, even if they are split to smaller pieces.

Even with an ECS Amiga of 1 MB of true chip RAM (A600 and A500+), it would still be hard to squeeze both left and right versions of sprites into that 1 MB. Maybe doable with 8 color sprites, but with 16 or 32 color sprites it's hard.

1 MB sounds like a lot, but it needs to hold everything: the program executable, double buffer bitmaps, background graphics, music, sound effects, and so on.

So to make it fit, in all likelyhood you would still need a real time mirroring routine for the sprites.

---

If you want to store both left and right versions of every frame, then 2 MB of chip is the minimum. For my AGA demo I counted that the SNES sized graphics would fit into 2 MB, both left and right versions, and there would still be enough space for everything else. But almost the full 2 MB Chip would be used, and even then some animation cuts were needed.

[Retro1234]

Bummer,

Originally Posted by DanScott

Store the sprites/objects with the top half facing left, and the bottom half facing right (ie... a 64 pixel high sprite, the top 32 pixels are facing left, the bottom 32 facing right)

Then you only have to flip one half depending on if you want the left or right facing version.

If The top Body was stored Right and Legs Left this should nearly half the time it takes to Flip stuff. - what Dan Scott said basically.

[dlfrsilver]

As said earlier, going for ecs is a nonsense. Aga + fastram + hard drive + 68030 is the only way to go at minimum.

[Galahad/FLT]

Originally Posted by Master484

The short answer is no. Storing both left and right versions of characters of this size would still take too much Chip RAM, even if they are split to smaller pieces.

Even with an ECS Amiga of 1 MB of true chip RAM (A600 and A500+), it would still be hard to squeeze both left and right versions of sprites into that 1 MB. Maybe doable with 8 color sprites, but with 16 or 32 color sprites it's hard.

1 MB sounds like a lot, but it needs to hold everything: the program executable, double buffer bitmaps, background graphics, music, sound effects, and so on.

So to make it fit, in all likelyhood you would still need a real time mirroring routine for the sprites.

---

If you want to store both left and right versions of every frame, then 2 MB of chip is the minimum. For my AGA demo I counted that the SNES sized graphics would fit into 2 MB, both left and right versions, and there would still be enough space for everything else. But almost the full 2 MB Chip would be used, and even then some animation cuts were needed.

You could use a basic RLE packer to get the size of the frames down and depack in realtime. Pretty sure thats how Mortal Kombat was done on Amiga.

[Master484]

If The top Body was stored Right and Legs Left this should nearly half the time it takes to Flip stuff. - what Dan Scott said basically.

Yes, this trick has been suggested before, and I think it might work.

Although in Blitz Basic both the Leg and Body parts would be Shape objects. And when a Shape is flipped with the "Flip" command, it stays that way.

And so this happens:

1. Player walks right.
2. We flip all leg Shapes to right.
3. All walking frames, both body and leg parts are now facing right.
4. Then fighters jump over each other and switch sides.
5. And now we need to flip all walking parts to left, both body and leg Shapes.

And so we end up with Flipping the full frames anyway.

Although now that I think about it, there is a workaround to this, and that is to have all frames stored in a Bitmap instead of Shapes, and then every frame we use GetaShape to grab the correct Leg and Body parts, and then Flip one of them.

But I think "GetaShape" is quite slow in real time use, and so is "XFlip".

It would work, but it would still be slow, thanks to the slowness of the Blitz commands involved.

But with a faster horizontal flipping routine this is certainly a good idea. And yes, this way the animation frames have hope of fitting into 1 MB.

You could use a basic RLE packer to get the size of the frames down and depack in realtime. Pretty sure thats how Mortal Kombat was done on Amiga.

Yes, that is the other way to make it fit.

Or maybe both mirroring and unpacking could be used at same time, as some people have mentioned in other threads.