Street Fighter 2 GFX Test

[Tigerskunk]

In my own experience, if stuff gets too complicated, I tend to abandon a project soon because it's just not fun at all anymore after a while.

Street Fighter 2 has a lot of frames where you'd need to adjust this. I feel this will grind you down very fast.

[idrougge]

Unless my calculations are off, triple buffering a scrolling bitmap eats up 240 000 bytes or so of chip mem. Add to that all the animation frames of the characters and some music and sound effects and you've used up every single byte of a standard Amiga's 512 kB chip memory.

If you want to demonstrate what US Gold did wrong, you'd have to demonstrate that under the same limitations as they had.

One nice thing about this kind of game is that there is max one or two enemies, which cuts down a lot on enemy logic processing overhead, where each Blitz calculation costs you a lot of CPU cycles. The amount of enemies is also limited, as is the environment you interact with, which is a further help as opposed to a shmup, a platformer or a beat'em up like Streets of Rage.

[idrougge]

Originally Posted by chb

Maybe fiddling around with CustomString could help, but I guess it would be very cumbersome. I do not have any experience with Blitz, does it allow to include also custom assembler/object code?

Indeed you can. Something like this is perfectly normal Blitz2 code:

NPrint "Hello world!"
NOP
SWAP d0
SWAP d0
NPrint "Goodbye world!"

Or you can INCBIN your object code:

NPrint "Hello world!"
JSR assembly
End
assembly:
INCBIN "code.o"

[roondar]

Originally Posted by idrougge

Unless my calculations are off, triple buffering a scrolling bitmap eats up 240 000 bytes or so of chip mem. Add to that all the animation frames of the characters and some music and sound effects and you've used up every single byte of a standard Amiga's 512 kB chip memory.

If you want to demonstrate what US Gold did wrong, you'd have to demonstrate that under the same limitations as they had.

It depends. If you wish to scroll while keeping the full bitmap in memory, then yes - it will take a lot of chip-memory. However, the optimal way of scrolling a screen horizontally (cork-screw scrolling) uses far less memory than that.

To be precise, scrolling up to 320 pixels horizontally (for 640 pixels total) on a 320x256x5 screen would require a 336x257x5 buffer when using cork-screw scrolling. A triple buffer version of this setup will cost 3x53970 bytes or 161910 bytes total. Which is still a lot, but should fit in 512kb with enough room for sounds & graphics.

It is possible, I suppose, that Blitz Basic doesn't support such a system natively. In which case you'd indeed need much more memory.

One nice thing about this kind of game is that there is max one or two enemies, which cuts down a lot on enemy logic processing overhead, where each Blitz calculation costs you a lot of CPU cycles. The amount of enemies is also limited, as is the environment you interact with, which is a further help as opposed to a shmup, a platformer or a beat'em up like Streets of Rage.

I tend to agree with this, but I do feel that a competent fighter AI will take a lot more cycles than a simple shmup enemy. Not too mention that collision detection is vital to do just right, which might mean doing quite a few more calculations than in simpler games.

[Master484]

Master484, i can work out my magic on SF2 WW arcade assets if you want

I can get you all the tiles for this game with perfect colors.

Thanks for the offer, this would of course be awesome and of great help.

But I think you should wait a little bit first. This is still just a demo, and there are no guarantees at this early point; I don't know if the end result of this will be anything more than a one level Blitz demo.

So we should wait until the playable demo is ready, and if it runs at solid 50 FPS with the largest and most complex characters and basic AI in place, only then I'll consider turning this from a demo into a full game.

About the arcade GFX, I think the character portraits and some stage graphics too are better in the SF2 "Champion Edition" version than in the original World Warrior. So maybe we should take at least some GFX from that version, rather than World Warrior. But it's still far too early to think this far, we first need a rock solid and powerful game engine, before planning any further than the demo stage.

---
---

But I have some great news: I managed to get 16 color sprites working in Blitz!

You can test this yourself, adding the code piece below to the source will make 16 color sprites appear.

; --- Add these lines to "LOADER"

BitMap 8,20,60,4  ; 16 color temporary bitmap
Use BitMap 8

; Draws 16 lines to bitmap in 16 colors

a = 0
Repeat
 Line a,0,a,50,a
 a + 1
Until a = 15

GetaShape 17,0,0,16,50
GetaSprite 1,17

; --- Add these lines to "GFXDRAW"

ShowSprite 1,50,50,0
ShowSprite 1,80,60,2
ShowSprite 1,110,70,4
ShowSprite 1,150,90,6

The above code works with Slice Library at least, and makes four 16 color sprites appear, as is shown in this screenshot:



And this is great news: On ECS configuration, Guile + Ken + 2 shadows + all those four 16 color sprites run at 50 FPS.

With these four 16 color sprites we can now cover any 48*Unlimited Y area in 16 colors, which means that one of the two fighters can be a mostly replaced with 16 color sprites. Ryu and Ken are exactly 48 pixels in the standing pose, so they and a few others can be almost totally sprites, and the bigger character BOBs can also be made considerably smaller.

And if we use the system that I described in my previous post; the other character always getting all the sprites and being a sprite + BOB combination, and the other being a 100% BOB, and the "best case" for the sprite user being always automatically chosen, then this means that the game should run at solid 50 FPS even on ECS.

It's a LOT easier to make those BOB + sprite combinations with 16 color sprites than 4 color sprites; I can basically just make four 16*unlimited Y areas of each character frame with sprites. Only the character palette needs to be 16 instead of 20, but this is 100% possible to do, and with a clever palette swap system for different characters the quality doesnt need to suffer either.

---

I can't believe that it was this easy to get 16 color sprites to work in Blitz.

I think the manual mentions 16 color sprites just once, in a side sentence that says something like "and 16 color sprites require extra channels also".

But that's all, the manual doesn't actually directly tell how to make sprites appear in 16 colors, and doesn't tell that the Slice library's "ShowSprite" command seemingly automatically determines whether the sprite that you're trying to display is 4 colors or 16 colors, and this seemingly depends on the color depth of the "Shape" from which you "GetaSprited" the sprite in question.

And when the sprite GFX data is 16 colors, you can then seemingly display it in both 4 color and 16 color mode, and Blitz seems to automatically decide the color mode, depending on the sprite channels you use in the "ShowSprite" commands. So putting a 16 color sprite to channels 0 and 2 causes two 16 color sprites to appear, because 16 color sprites use two consequtive channels, and when Blitz sees that you put a sprite to channel 0 but leave channel 1 empty, then it assumes that you want the sprite to appear in 16 colors.

But if you put this same 16 color sprite to channels 0, 1, 2 and 3, this causes four 4 color sprites to appear instead, because there are no free channels for a 16 color sprite to appear.

This is a genius system actually, and very flexible and easy, now that we know how it works. And this is how it works in the Slice Library, I don't know if sprites behave differently in the Display Library. (for those who don't know, Blitz has two separate graphics libraries, older "Slice" library and newer "Display" library, each with their own set of exclusive commands, and Blitz coders must choose which one of these to use. I use Slice, because it's easier.)

---

If you want to demonstrate what US Gold did wrong, you'd have to demonstrate that under the same limitations as they had.

True, even this small demo here needs 1 MB of chip, with 2 MB being a likely requirement. Us Gold probably did an OK job back then, especially when we consider the complexity and size of the game, and the low quality of most other arcade conversions on the Amiga.

It's very easy to instantly use up the whole 512K, and even 1 MB. But for me, 2 MB is the final limit that I won't cross...because as long as it's under 2 MB I know that the game could have run at least on A1200 back then, even if not A500, and that's good enough for me. A Street Fighter 2 conversion made with Blitz, running at 50 FPS on A1200, would have still been pretty awesome back in the day, and for me that thought is enough to motivate small hobby projects like this.

It depends. If you wish to scroll while keeping the full bitmap in memory, then yes - it will take a lot of chip-memory. However, the optimal way of scrolling a screen horizontally (cork-screw scrolling) uses far less memory than that.

I had already forgotten the cork-screw scrolling techique, I have tested this in the past and it is indeed possible with Blitz, although I remember some small problems too. But maybe this scroll method could be considered if RAM usage starts to get too high (knocking the 2 MB limit in this case).

[chb]

Originally Posted by idrougge

Unless my calculations are off, triple buffering a scrolling bitmap eats up 240 000 bytes or so of chip mem. Add to that all the animation frames of the characters and some music and sound effects and you've used up every single byte of a standard Amiga's 512 kB chip memory.

If you want to demonstrate what US Gold did wrong, you'd have to demonstrate that under the same limitations as they had.

Yep, memory (especially chip mem) would be critical. But you need a possibility to x-flip animation frames anyhow because players can switch sides. This is fastest done with the CPU, using a 8-bit look up table. So you can use fast ram for animation frames, too (mirroring to chip mem in a buffer, then blitting or setting sprite pointers). Unfortunately, this will take some additional toll on performance, but having all frames in both directions in chip mem is impractical I guess.
Another idea to save ram could be using real-time compression on animation frames, it was discussed on EAB some time ago here. If you're amazingly clever, you might be able to bake the mirroring into the decompression algorithm at little cost, e.g in LZ77 or LZ4, you'd need to only flip the literals, but the matches are copied from the decompressed stream that is already flipped. You'd need to store the bytes in vertical order, though (8 pixel columns going from top to bottom, then start next column at the top). And I might have overlooked a serious issue with this . But would be interesting to see, depending on the data it could be even faster than a simple byte-per-byte mirror in extreme cases, when there's a high number of matches that have to be simply copied...

[dlfrsilver]

Originally Posted by Master484

Thanks for the offer, this would of course be awesome and of great help.

But I think you should wait a little bit first. This is still just a demo, and there are no guarantees at this early point; I don't know if the end result of this will be anything more than a one level Blitz demo.

So we should wait until the playable demo is ready, and if it runs at solid 50 FPS with the largest and most complex characters and basic AI in place, only then I'll consider turning this from a demo into a full game.

About the arcade GFX, I think the character portraits and some stage graphics too are better in the SF2 "Champion Edition" version than in the original World Warrior. So maybe we should take at least some GFX from that version, rather than World Warrior. But it's still far too early to think this far, we first need a rock solid and powerful game engine, before planning any further than the demo stage.

---
---

But I have some great news: I managed to get 16 color sprites working in Blitz!

You can test this yourself, adding the code piece below to the source will make 16 color sprites appear.

; --- Add these lines to "LOADER"

BitMap 8,20,60,4  ; 16 color temporary bitmap
Use BitMap 8

; Draws 16 lines to bitmap in 16 colors

a = 0
Repeat
 Line a,0,a,50,a
 a + 1
Until a = 15

GetaShape 17,0,0,16,50
GetaSprite 1,17

; --- Add these lines to "GFXDRAW"

ShowSprite 1,50,50,0
ShowSprite 1,80,60,2
ShowSprite 1,110,70,4
ShowSprite 1,150,90,6

The above code works with Slice Library at least, and makes four 16 color sprites appear, as is shown in this screenshot:



And this is great news: On ECS configuration, Guile + Ken + 2 shadows + all those four 16 color sprites run at 50 FPS.

With these four 16 color sprites we can now cover any 48*Unlimited Y area in 16 colors, which means that one of the two fighters can be a mostly replaced with 16 color sprites. Ryu and Ken are exactly 48 pixels in the standing pose, so they and a few others can be almost totally sprites, and the bigger character BOBs can also be made considerably smaller.

And if we use the system that I described in my previous post; the other character always getting all the sprites and being a sprite + BOB combination, and the other being a 100% BOB, and the "best case" for the sprite user being always automatically chosen, then this means that the game should run at solid 50 FPS even on ECS.

It's a LOT easier to make those BOB + sprite combinations with 16 color sprites than 4 color sprites; I can basically just make four 16*unlimited Y areas of each character frame with sprites. Only the character palette needs to be 16 instead of 20, but this is 100% possible to do, and with a clever palette swap system for different characters the quality doesnt need to suffer either.

---

I can't believe that it was this easy to get 16 color sprites to work in Blitz.

I think the manual mentions 16 color sprites just once, in a side sentence that says something like "and 16 color sprites require extra channels also".

But that's all, the manual doesn't actually directly tell how to make sprites appear in 16 colors, and doesn't tell that the Slice library's "ShowSprite" command seemingly automatically determines whether the sprite that you're trying to display is 4 colors or 16 colors, and this seemingly depends on the color depth of the "Shape" from which you "GetaSprited" the sprite in question.

And when the sprite GFX data is 16 colors, you can then seemingly display it in both 4 color and 16 color mode, and Blitz seems to automatically decide the color mode, depending on the sprite channels you use in the "ShowSprite" commands. So putting a 16 color sprite to channels 0 and 2 causes two 16 color sprites to appear, because 16 color sprites use two consequtive channels, and when Blitz sees that you put a sprite to channel 0 but leave channel 1 empty, then it assumes that you want the sprite to appear in 16 colors.

But if you put this same 16 color sprite to channels 0, 1, 2 and 3, this causes four 4 color sprites to appear instead, because there are no free channels for a 16 color sprite to appear.

This is a genius system actually, and very flexible and easy, now that we know how it works. And this is how it works in the Slice Library, I don't know if sprites behave differently in the Display Library. (for those who don't know, Blitz has two separate graphics libraries, older "Slice" library and newer "Display" library, each with their own set of exclusive commands, and Blitz coders must choose which one of these to use. I use Slice, because it's easier.)

---

True, even this small demo here needs 1 MB of chip, with 2 MB being a likely requirement. Us Gold probably did an OK job back then, especially when we consider the complexity and size of the game, and the low quality of most other arcade conversions on the Amiga.

It's very easy to instantly use up the whole 512K, and even 1 MB. But for me, 2 MB is the final limit that I won't cross...because as long as it's under 2 MB I know that the game could have run at least on A1200 back then, even if not A500, and that's good enough for me. A Street Fighter 2 conversion made with Blitz, running at 50 FPS on A1200, would have still been pretty awesome back in the day, and for me that thought is enough to motivate small hobby projects like this.

I had already forgotten the cork-screw scrolling techique, I have tested this in the past and it is indeed possible with Blitz, although I remember some small problems too. But maybe this scroll method could be considered if RAM usage starts to get too high (knocking the 2 MB limit in this case).

Well, basically SF2 was built around the Atari ST which gave the game a handicap right from the start. Next, all the graphics where ripped with a genlock or either a framegrabber system, giving the shittiest graphics you'd ever want.....

However, it has to be noted that the arcade program of SF2 is 1mb ALONE.

each character use 255 frames. Ryu weight is 800kb, Honda is approximately the same. SF2 is basically a game made for AGA machines, and not ECS.

Even in ECS, if you want to make a good version, you will need between 500-1000kb of fast, and 2mb of chip ram will be a minimum.

Only the X68000 needs 2mb of ram to make SF2 running, that's because it has a tile system and this make it use less ram.

The Amiga will require more ram in this respect.

[Codetapper]

Originally Posted by Master484

Just in case you hadn't already considered it, the status panel at the top could be quite heavily optimised aswell.

The energy bar could be a single pixel high drawn in 4 colour mode with KO made up with a couple of sprites. A negative modulo for the height of the energy bar means you'd only have to plot a single line and repeat it for 8 lines or whatever it is.

The negative modulo trick for the bottom line of white pixels could "point back" to the top line of white pixels too and be drawn in 1 bitplane mode.

Chunks of the energy bar itself could disable bitplane DMA completely since it's all black pixels. The bottom section can be turned off completely and just use sprites for the time remaining digits.

All these tricks would buy you a little more horsepower to play the game if you hadn't considered them!

[Master484]

Well, basically SF2 was built around the Atari ST which gave the game a handicap right from the start. Next, all the graphics where ripped with a genlock or either a framegrabber system, giving the shittiest graphics you'd ever want.....

However, it has to be noted that the arcade program of SF2 is 1mb ALONE.

each character use 255 frames. Ryu weight is 800kb, Honda is approximately the same. SF2 is basically a game made for AGA machines, and not ECS.

Even in ECS, if you want to make a good version, you will need between 500-1000kb of fast, and 2mb of chip ram will be a minimum.

Only the X68000 needs 2mb of ram to make SF2 running, that's because it has a tile system and this make it use less ram.

The Amiga will require more ram in this respect.

Interesting that the arcade code alone takes 1 MB. I suppose it's the character combat AI routines that take the most space. Because other than the AI and the big animated graphics system, the game itself seems quite simple.

For the 2 MB goal I made a quick RAM usage calculation like this:

300 KB - Triple Buffering the three bitmaps. This includes the current level background GFX being held in the 3rd buffer.
200 KB - Program Code
100 KB - Someone said that the operating system eats this amount
100 KB - Sound, should be enough for most battle sounds for 2 characters
100 KB - Music, one music plays during a level.

That adds up to 800 KB, and leaves us 1200 KB. Let's also save 200 KB as a "reserve RAM" for random purposes.

So about 1000 KB can be used for graphics, for each fight.

If we think of all the animation frames of one character, how many 320 * 256 bitmaps would they take, if we tried to split them into smaller parts, and cram as much as possible into each 320 * 256 bitmap?

Because I counted that one 320*256 screen in 32 colors takes just 52 KB when using the formula (320/8)*256*5. So we could fit 19 this size 32 color bitmaps into that 1000 KB. When transparency mask cost is added to the bitplane amount it's (320/8)*256*6 which makes 62 KB and 16 bitmaps fitting into 1000KB.

Could 16 screens full of frames be enough to hold 2 fighters in the 1000KB of RAM that we reserved for GFX in this scenario? And the background GFX cost is already counted for; it's in the triple buffer.

Just in case you hadn't already considered it, the status panel at the top could be quite heavily optimised aswell.

The energy bar could be a single pixel high drawn in 4 colour mode with KO made up with a couple of sprites. A negative modulo for the height of the energy bar means you'd only have to plot a single line and repeat it for 8 lines or whatever it is.

The negative modulo trick for the bottom line of white pixels could "point back" to the top line of white pixels too and be drawn in 1 bitplane mode.

Chunks of the energy bar itself could disable bitplane DMA completely since it's all black pixels. The bottom section can be turned off completely and just use sprites for the time remaining digits.

All these tricks would buy you a little more horsepower to play the game if you hadn't considered them!

Thanks for the advice. Right now the status panel is just a placeholder image and should indeed be optimized...in fact this area of the screen should be as optimized as possible to boost speed. I don't know if the negative modulo trick works in Blitz, but using a 4 color / 2 color mode combo + sprites for the panel should work fine, I'll try them out.

[dlfrsilver]

1mb of fast for the code and 2mb of chip are the minimum for such a game.

The arcade code is big for many reasons :

It contains 2 state machines, 1 for each character. The AI tables are i guess quite big. And the tiledatas are also big.

About the sprites, just one is 600-800kb, so how are you going to do ?

EDIT : on a 320x256 screen, i can put 8 ryu frames. For some characters, this will be less, like blanka and E.Honda.

Question about the Amiga data management, is it better if i put for example Ryu per animation bank in horizontal row, or better in vertical row ?

[Amigajay]

The console versions didn't have 3mb+ of ram, it all doesn't need to be in memory all at once only what is needed.
As much as a fast ram version would be better, i think the whole point you started was to better the awful US Gold version in the same limitations was it not Master484?

[dlfrsilver]

Originally Posted by Amigajay

The console versions didn't have 3mb+ of ram, it all doesn't need to be in memory all at once only what is needed.
As much as a fast ram version would be better, i think the whole point you started was to better the awful US Gold version in the same limitations was it not Master484?

Console coin-ops and computers are not using the same system.

The Amiga is a planar system, and the console/coin-ops tile systems.

SF2 arcade assets are stored inside the machine in maskroms in chunky Format, converted and prepared by the machine to be processed as planar graphics.

The arcade machine has 6mb of graphics, 1mb of arcade code, and 256kb of music and digital voices/sfx.

Even by using only 2 enemies, 1 background, maybe animations/parallax, music and sound on a computer (even like the amiga, yes!), you need 3mb of ram.

a background takes 150kb, one enemy 600-800k (count 800k...)+program 500kb a minima, and you're there ! This all without even talking about the audio !

150
+ 800x2
+ 500
-----------

2mb of ram without music or SFX !

[dlfrsilver]

EDIT : I did a try with 36 sprite frames of Ryu in 16 colors, IFF format.

The file size is 137kb already !

After a little calculation, Ryu all frames stored in IFF format will be 840kb !

[Retro1234]

In some ways Amiga is better suited because these games dont usually use any tiles and Amiga is good at displaying large pictures but a cartridge can just load new graphics every frame if it wanted no extra ram need to load them into.

But I think it would be very hard to match the game play of Super Street Fighter 2 it might even be a direct port of the lodic.

What was Street Fighter 2 instanbul made in?

[dlfrsilver]

Originally Posted by Retro1234

In some ways Amiga is better suited because these games dont usually use any tiles and Amiga is good at displaying large pictures but a cartridge can just load new graphics every frame if it wanted no extra ram need to load them into.

But I think it would be very hard to match the game play of Super Street Fighter 2 it might even be a direct port of the lodic.

What was Street Fighter 2 instanbul made in?

The problem on such a game is the amount of ram needed.

the size for ryu is for 16 colors without a mask in 4BPL. I guess it will be more in 5 bpl.

[Retro1234]

Yeah really US Gold didnt do such a bad job it runs on 512kb doesnt it? But World Warriors or waht ever the first basic version was, was a bit shit anyway and the disk swapping was rubbish until I got JST HD install.

Street Fighter 2 didnt become good until it was hacked and then Turbo released if it wasnt for that it was not a match for King Of Fighters.

[dlfrsilver]

Originally Posted by Retro1234

Yeah really US Gold didnt do such a bad job it runs on 512kb doesnt it? But New Challengers was a bit shit anyway and the disk swapping was rubbish until I got JST HD install.

Street Fighter 2 didnt become good until it was hacked and then Turbo released if it wasnt for that it was not a match for King Of Fighters.

They did the job for the game to run on ST. Read smallish characters, and a low amount of colors. And the game is not 512k but 1mb only !

Making games with a framegrabber, was really the lamest possible way.

[Retro1234]

When you think how long it would of taken back then with a framegrabber and everthing else its pretty amazing, the man hours are huge.

[dlfrsilver]

Originally Posted by Retro1234

When you think how long it would of taken back then with a framegrabber and everthing else its pretty amazing, the man hours are huge.

Yes i'm sure they spent tons of hours when if they had the original assets, it would have been only days !

[Codetapper]

For a comparison of how the Amiga sliced up the various graphics, have a look at an early rip entry for Street Fighter 2 containing the graphics for 5 of the characters.