Street Fighter 2 GFX Test

[Master484]

Here is another small side project that I put together last week.

I took some GFX from the Amiga version of Street Fighter 2 World Warrior, improved some of them, re-designed the palette, made a Copper plan for the Guile level background, and then coded a small Blitz Basic demo to test 32 color big BOB drawing speed.

The image above is just a mock-up, and there is no proper gameplay yet. But there are some cool Copper tricks and reasonably fast 32 color BOB drawing, using re-colored GFX taken directly from the Amiga Street Fighter 2. And because the demo runs so well and looks much better than the original Us Gold version, I thought that it's worth sharing.

The ADF is in the attachment, and Blitz source is included in the disk; you can use the code freely in your own projects.

Minimum Requirements: ECS + 1 MB of Chip RAM should be enough (that means pure Chip RAM, 512K Chip + 512K Slow combination wont work). And if it doesn't start just give it more RAM.

CONTROLS:

- Use Joystick to scroll the level.

- Press and hold down Numbers 1 2 3 4 5 6 7 to create objects and character BOBS. There are 5 characters: Honda, Guile, Chun Li, Ken and Ryu, and also a fireball and a "ground shadow" bob are included.

- Press 8 and 9 to switch between 25 FPS and 50 FPS mode.

- Press and hold down Space to delete objects

---

The screen has two Slices: a 8 color status panel on top, and a 32 color mode 288*212 main playfield below it.

The 288 px wide display size boosts speed, and also Triple Buffering is used: In addition of having 2 bitmaps for double buffering, a third clean level map is held in memory, and QBlits with "Unbuffer Source" are used, which greatly improves speed, although at the cost of higher RAM usage.

Performance is pretty good for Blitz; thanks to Triple Buffering, the drawing stress of the 32 color BOBs is about the same as if we were drawing 16 color BOBs instead.

On A600 / ECS two smaller charcter BOBS (such as Ryu and Chun Li) with ground shadows added, run at 50 fps. But bigger BOBS, such as Honda + Guile + 2 shadows causes slowdown. But when frame rate is switched to 25 FPS, 2 Hondas + 2 shadows + 1 fireball run at 25 FPS, but one more fireball and slowdown starts. But still pretty good considering that this is Blitz Basic, and that the original Amiga SF2 runs at 17 FPS with frequent slowdowns.

And on A1200 / AGA the results are about 20 % faster, if we just compare the amount of 32*32 fireball BOBs at 50 FPS, but two 86*86 Honda BOBs with shadows causes slowdown even for A1200. I guess bigger BOBs like this should be split into smaller segments. And surely sprites too could be used for something.

But at 25 FPS this game would be certainly doable with Blitz, and maybe even 50 FPS on AGA with some tricks and optimizations.

---



In this demo Copper is used a lot to add more colors to screen: the background color amount alone is 61 colors, and to this we then add a separate status panel palette and BOB palettes for some 70-80 colors on screen at any time.

The game itself runs in 5 bitplane mode (32 colors), with 12 colors reserved for the backgrounds, and 19 colors + transparency for the BOBS. The BOB colors can be freely used in the backgrounds too, but background colors cant really be used in BOBs because of the heavy Copper changes present across the screen.

Most of the extra colors are done by changing a few "free colors" at certain Y points...the sky copper is basic stuff, it's just one color gradient. But the other coppers needed careful planning that took me two days of experimenting, but the end result looks great: we got a 64 color display "for free".

If you take a look at the level, you'll notice that certain colors only appear on certain "Y zones". The yellows for the hairs and the danger sign is one such zone, and the crate browns and the womens shoe colors is another one. And the pink letters in the planes tail, the orange cloth parts, and the lime green details in the ground objects is just one color changing several times. The image that I posted includes the original picture and the copperized version, from it you can get an idea of what is going on.

And also notice how the level scrolls both horizontally AND vertically, but still the colors don't "move" as you often see when coppers are in effect in vertically scrolling games.

The trick that I used is this: the vertical scrolling amount is only 12 pixels at maximum (in the game jumping causes this amount of Y scroll), and I designed the copper lists to take this potential Y movement into account. So when a color changes to another, one just have to leave at least 12 pixels in the bitmap between the last line where current color is present and the first line where new color starts. This way the vertical scroll can never "reach" the copper change points.

Some colors like the grays can't be changed at all, because they're present on almost every line in the image. But most of the other colors are "free for the copper", and they're the ones that are changed through the whole screen several times. In fact all copper changes are done with just 8 colors, so with copper magic we turned 8 colors to 32...so it's 24 "static" colors + 32 "bling" colors, and that's just the game area itself, status panel has it's own 8 color palette, and to it too we add colors with the Copper.

---
---

Compare this with the original Us Gold Street Fighter 2:



The US Gold SF2 World Warrior actually uses a similar divided palette system like this demo has. It too runs in 32 color mode, and the characters all share the same 16 color palette, which makes the first half of the 32 color palette, and then each level has it's own unique 16 color palette, which makes the second half of the 32 colors. The character colors are never used in the backgrounds, and also BG colors are not used in the characters.

But for some reason (Atari ST) the Us Gold game has a complete lack of Copper usage, even though this sort of divided palette set-up + horizontal only scrolling game = 100 % perfect scenario for the Copper. They could have freely copperized the 16 background colors for each level, just as is done in this demo, without affecting the 16 BOB colors. With good planning, the Amiga version could have easily been a 64 color game, and that would have been free both RAM and CPU wise, because copper lists are cheap.

---

Maybe I should actually put together a small playable level of this, to see how well it runs with some AI and additional animations. Because this looks so good already, that it would be interesting to see this in action with 50 FPS character animations. Blitz is known to be well suited for limited play area games, so let's see if it can handle Street Fighter 2 at 50 FPS.

[Amigajay]

looks good, though unfortunately you cant polish a turd, and the US Gold game is just crap way more than just graphics and sound.

The Amiga had 3 SF games, the first i.e crap, the 2nd (SF2 NC) looked crap but played the best, and the last (SSF2T) looked great in still shots, but the animation was cut to the point it was unplayable.

If you can get the playability of New Challengers with your new remixed gfx, then it could be the best version to date!

[dlfrsilver]

Originally Posted by Amigajay

looks good, though unfortunately you cant polish a turd, and the US Gold game is just crap way more than just graphics and sound.

The Amiga had 3 SF games, the first i.e crap, the 2nd (SF2 NC) looked crap but played the best, and the last (SSF2T) looked great in still shots, but the animation was cut to the point it was unplayable.

If you can get the playability of New Challengers with your new remixed gfx, then it could be the best version to date!

SSF2T has not its animation cuts, the problem lies inside the program, they have ported the PC code with the hack they use to make it run on PC. this hack force 60 fps, the engine doesn't allow the amiga to refresh the needed parts on screen, it results with undisplayed frames and color palette problems.

[Amigajay]

Originally Posted by dlfrsilver

SSF2T has not its animation cuts, the problem lies inside the program, they have ported the PC code with the hack they use to make it run on PC. this hack force 60 fps, the engine doesn't allow the amiga to refresh the needed parts on screen, it results with undisplayed frames and color palette problems.

Well i suppose it amounts to the same thing, SF relies heavily on animation and timing to pull off the moves, because its been severely compromised its totally ruined the gameplay.

[s2325]

There was some graphic hack for Amiga with corrected and improved backgrounds, maybe you should use these.

[Shatterhand]

On A600 / ECS two smaller charcter BOBS (such as Ryu and Chun Li) with ground shadows added, run at 50 fps. But bigger BOBS, such as Honda + Guile + 2 shadows causes slowdown. But when frame rate is switched to 25 FPS, 2 Hondas + 2 shadows + 1 fireball run at 25 FPS, but one more fireball and slowdown starts. But still pretty good considering that this is Blitz Basic, and that the original Amiga SF2 runs at 17 FPS with frequent slowdowns.

Fireballs and/or shadows could flash on screen instead of staying there all the time. I think this could cut some blitter time and maybe make it work at 25 fps all the time...

[dlfrsilver]

Originally Posted by Master484

Here is another small side project that I put together last week.

I took some GFX from the Amiga version of Street Fighter 2 World Warrior, improved some of them, re-designed the palette, made a Copper plan for the Guile level background, and then coded a small Blitz Basic demo to test 32 color big BOB drawing speed.

The image above is just a mock-up, and there is no proper gameplay yet. But there are some cool Copper tricks and reasonably fast 32 color BOB drawing, using re-colored GFX taken directly from the Amiga Street Fighter 2. And because the demo runs so well and looks much better than the original Us Gold version, I thought that it's worth sharing.

The ADF is in the attachment, and Blitz source is included in the disk; you can use the code freely in your own projects.

Minimum Requirements: ECS + 1 MB of Chip RAM should be enough (that means pure Chip RAM, 512K Chip + 512K Slow combination wont work). And if it doesn't start just give it more RAM.

CONTROLS:

- Use Joystick to scroll the level.

- Press and hold down Numbers 1 2 3 4 5 6 7 to create objects and character BOBS. There are 5 characters: Honda, Guile, Chun Li, Ken and Ryu, and also a fireball and a "ground shadow" bob are included.

- Press 8 and 9 to switch between 25 FPS and 50 FPS mode.

- Press and hold down Space to delete objects

---

The screen has two Slices: a 8 color status panel on top, and a 32 color mode 288*212 main playfield below it.

The 288 px wide display size boosts speed, and also Triple Buffering is used: In addition of having 2 bitmaps for double buffering, a third clean level map is held in memory, and QBlits with "Unbuffer Source" are used, which greatly improves speed, although at the cost of higher RAM usage.

Performance is pretty good for Blitz; thanks to Triple Buffering, the drawing stress of the 32 color BOBs is about the same as if we were drawing 16 color BOBs instead.

On A600 / ECS two smaller charcter BOBS (such as Ryu and Chun Li) with ground shadows added, run at 50 fps. But bigger BOBS, such as Honda + Guile + 2 shadows causes slowdown. But when frame rate is switched to 25 FPS, 2 Hondas + 2 shadows + 1 fireball run at 25 FPS, but one more fireball and slowdown starts. But still pretty good considering that this is Blitz Basic, and that the original Amiga SF2 runs at 17 FPS with frequent slowdowns.

And on A1200 / AGA the results are about 20 % faster, if we just compare the amount of 32*32 fireball BOBs at 50 FPS, but two 86*86 Honda BOBs with shadows causes slowdown even for A1200. I guess bigger BOBs like this should be split into smaller segments. And surely sprites too could be used for something.

But at 25 FPS this game would be certainly doable with Blitz, and maybe even 50 FPS on AGA with some tricks and optimizations.

---



In this demo Copper is used a lot to add more colors to screen: the background color amount alone is 61 colors, and to this we then add a separate status panel palette and BOB palettes for some 70-80 colors on screen at any time.

The game itself runs in 5 bitplane mode (32 colors), with 12 colors reserved for the backgrounds, and 19 colors + transparency for the BOBS. The BOB colors can be freely used in the backgrounds too, but background colors cant really be used in BOBs because of the heavy Copper changes present across the screen.

Most of the extra colors are done by changing a few "free colors" at certain Y points...the sky copper is basic stuff, it's just one color gradient. But the other coppers needed careful planning that took me two days of experimenting, but the end result looks great: we got a 64 color display "for free".

If you take a look at the level, you'll notice that certain colors only appear on certain "Y zones". The yellows for the hairs and the danger sign is one such zone, and the crate browns and the womens shoe colors is another one. And the pink letters in the planes tail, the orange cloth parts, and the lime green details in the ground objects is just one color changing several times. The image that I posted includes the original picture and the copperized version, from it you can get an idea of what is going on.

And also notice how the level scrolls both horizontally AND vertically, but still the colors don't "move" as you often see when coppers are in effect in vertically scrolling games.

The trick that I used is this: the vertical scrolling amount is only 12 pixels at maximum (in the game jumping causes this amount of Y scroll), and I designed the copper lists to take this potential Y movement into account. So when a color changes to another, one just have to leave at least 12 pixels in the bitmap between the last line where current color is present and the first line where new color starts. This way the vertical scroll can never "reach" the copper change points.

Some colors like the grays can't be changed at all, because they're present on almost every line in the image. But most of the other colors are "free for the copper", and they're the ones that are changed through the whole screen several times. In fact all copper changes are done with just 8 colors, so with copper magic we turned 8 colors to 32...so it's 24 "static" colors + 32 "bling" colors, and that's just the game area itself, status panel has it's own 8 color palette, and to it too we add colors with the Copper.

---
---

Compare this with the original Us Gold Street Fighter 2:



The US Gold SF2 World Warrior actually uses a similar divided palette system like this demo has. It too runs in 32 color mode, and the characters all share the same 16 color palette, which makes the first half of the 32 color palette, and then each level has it's own unique 16 color palette, which makes the second half of the 32 colors. The character colors are never used in the backgrounds, and also BG colors are not used in the characters.

But for some reason (Atari ST) the Us Gold game has a complete lack of Copper usage, even though this sort of divided palette set-up + horizontal only scrolling game = 100 % perfect scenario for the Copper. They could have freely copperized the 16 background colors for each level, just as is done in this demo, without affecting the 16 BOB colors. With good planning, the Amiga version could have easily been a 64 color game, and that would have been free both RAM and CPU wise, because copper lists are cheap.

---

Maybe I should actually put together a small playable level of this, to see how well it runs with some AI and additional animations. Because this looks so good already, that it would be interesting to see this in action with 50 FPS character animations. Blitz is known to be well suited for limited play area games, so let's see if it can handle Street Fighter 2 at 50 FPS.

I have a question about the slowdowns. Something is really questioning me, i mean how a single background and 2 big sprites + fireball can slowdown an A1200 ? You have basically 255 frames per characters, ok, but since those characters are made of tiles, you assemble them when needed and the move the whole box were the tiles are sticked, no ?

each sprite frame is mostly build of 64 tiles of 16x16 pixels. Well, is that too much even for an A1200 ?

[Shatterhand]

1 - Everytime you move something with the Blitther, you have to take those 4 steps:

1-Copy the background to where the sprite is going to move to the memory
2-Cut the Sprite from screen
3-Copy it to the new position
4-Restore the background from the previous sprite position.

I am calling it "sprite" here, but it's actually a BOB (Blitter OBject).

This takes some time to do, and the A1200 blitter AFAIK is still the same as the A500/A600 one and not a very fast one.

I understand people say the blitter is awesome, and it indeed is. but I still don't get why the Amiga doesn't have more HW sprites... it could had made a lot of stuff easier/faster to do. (Probably not in the case of Street Fighter anyway... )

Fireballs could be sprites, couldn't them?

-

Also, you have to consider Dhalsim. Dhalsim could give be really troublesome to do.

[Samurai_Crow]

The AGA blitter is as slow as the 16 bit chipsets but using a better fetch rate frees up bandwidth on the Chip RAM.

[Master484]

There was some graphic hack for Amiga with corrected and improved backgrounds, maybe you should use these

Interesting, I've never heard of an improved version. Is it available for download somewhere?

I have a question about the slowdowns. Something is really questioning me, i mean how a single background and 2 big sprites + fireball can slowdown an A1200 ? You have basically 255 frames per characters, ok, but since those characters are made of tiles, you assemble them when needed and the move the whole box were the tiles are sticked, no ?

each sprite frame is mostly build of 64 tiles of 16x16 pixels. Well, is that too much even for an A1200 ?

The slowdowns bother me too, and I wish that AGA could do better than this.

Right now in this demo the big Honda BOBs are drawn as whole images, and their image size is 86*86, and a fireball BOB is 32*32. And two 86*86 BOBs + one 32*32 BOB together are enough to create slowdown.

Counted on 32*32 fireballs alone, on A500 we can have about 8 fireballs without slowdown, and on AGA we can have 10 fireballs.

So one 86*86 Honda BOB is equivalent to about 5 fireballs, because 2 of them still run at 50fps, but one fireball added to that and slowdown starts.

A part of this slowdown is caused by the relative slowness of Blitz itself; blitting BOBs in Blitz is about 30% slower than in Assembler. Although this could be hard to believe if you compare the speed of this demo with the Us Gold version.

Also, in some cases speed could be improved by blitting big BOBs in smaller parts. But as a general rule is better to make one big Blit than many small Blits, because the blitting operations themselves are costly. For example it's better to blit one 64*64 BOB than four 32*32 BOBS.

But in a game like this, just for RAM reasons alone big animation frames will need to be split into smaller BOBs, and yes, it works like you described, one character is assembled from many smaller parts.

And with 5 bitplanes to draw every time, and with the additional slowdown from Blitz, this seems to be too much even for A1200. This despite the fact that Triple Buffering is used here, so the "background copy" step for each Blit is not needed.

There was some interesting talk about blitting speed in this thread: http://eab.abime.net/showthread.php?t=84546

That thread also has some comparison between ASM and Blitz blitting speed, where I managed to blit just six 32*32 BOB at 5 bitplanes...but in this demo I can blit eight BOBs, because Triple Buffering is used.

Fireballs and/or shadows could flash on screen instead of staying there all the time. I think this could cut some blitter time and maybe make it work at 25 fps all the time...

Yes, I also thought about flashing the shadows to boost speed. It would save a lot of power, because shadows are constantly on screen.

Maybe a trigger could be used; when there is much to draw; shadows and projectiles could start flashing. And also background animations could stop when things get busy; this trick is used in Elfmania.

And yes, fireballs and other projectiles most likely should be sprites.

Also, you have to consider Dhalsim. Dhalsim could give be really troublesome to do.

True, I guess the stretching hands and legs just have to made with many smaller blits.

Luckily there are only 4 skin tones in addition to white, so I think that some leg / hand parts can be made with 4 color sprites, which lessens the load of the Blitter. I can already see that Honda could be made 16 pixels thinner by using just 1 sprite to draw the rightmost hand/leg part. And thankfully sprite Y height is unlimited, which really helps here.

So I think four 4 color sprites could use the 3 skin colors (+1 transparent color), and each of the 2 characters would be made out of two sprites + smaller BOB blits. And the remaining 3 sprites will use two blue colors + white, and these are used for fireballs etc. If other colored projectiles are needed, then a BOB is used instead. And one more sprite channel remains, but the 8th sprite is not available because hardware scrolling is used.

Also using 16 color sprites for at least one of the two characters on screen would theoretically be one possibility, but I don't have a clue how to use 16 color sprites in Blitz. And the character palette is actually 20 colors now, so it might not work so well anyways. And I like 4 color sprites, so I'll use them.

---

So I think that when 2 sprites are added to both fighters, they'll be smaller and faster to Blit, and so on A1200 at least this should mean a reasonably stable 50 FPS, with occasional slowdown happening when something crazy happens. Might even run 50 FPS on ECS, if also screen size was reduced for ECS version.

[roondar]

If you're using AGA and can accept a 15 colour character, you could also try to create one out of hardware sprites (AGA sprites can be 64 pixels wide so even Dhalsim should fit) - this would effectively give you a 'free' character. For the A500/600, you could do the same, but for the fireballs instead. That would give you two 'free' fireballs.

[s2325]

It was Super Street Fighter 2, sorry http://eab.abime.net/showthread.php?t=41499 http://eab.abime.net/showthread.php?t=48633

[chb]

Hi,

that's a very nice effort you've made here! It indeed looks much better than the old US Gold version!

I was thinking about ways to improve that game quite some time ago, too, and some of my ideas might be useful or not for you (I most definitely will not find time for such a project) :

• The shadows stay always in the same vertical position. So one could switch to EHB for this 16 or so scanlines. On the plus side: the shadow becomes a single bitplane blit (to the 6th plane which is empty otherwise), transparency looks much nicer, and it works with copper colors, too. Needs a bit more DMA during that 16 lines, but blits are faster. Minus side: Needs some moderately tricky logic to do cookie cutting with the player bobs, as the shadows should not affect them
• I'd rather use a different palette organization - 16 colors + copper for the background and 8 colors per player, individual palette for every player sprite. Or maybe 6 per player + 4 common ones for all player sprites (skin tones e.g.). This can also speed up blitting a little bit, as some planes are always zero or one. I think the original has 16 colors per sprite, so 8 is probably acceptable.
• Trying to make good use of hardware sprites. I think giving every player 4 sprites that can be used as 15- or 3-color-sprites as needed would give the best results. 15 color sprites have the upper 16 colors (one transparent), so the palette does not interfere with the background. If 3-color sprites are used, things get more complicated, but tricks like using attached, non-overlapping sprites may help. Would need quite a bit of manual work and/or a good converter.
• Icing on the cake: The 3D-scrolling floor. Below the players it can be simply scrolled by setting the scroll register per line, the other region is trickier - we don't want to shear the players. One idea was to reduce background colors in this area to 4 plus copper gradients and use the blitter to scroll per line. Maybe use the copper to setup the blitter to keep the overhead low. As said, would just be the icing on the cake if there's enough time left, but it's not that much data - two planes, maybe 50 pixel high, simple A-D-copy. On AGA simply doable with HW scrolling by either using HW sprites for the players or by using the 8-plane-dual playfield mode.

As said, I'm just couch coaching here, so feel free to ignore all of this . But I'd be glad if it was of some use.

[Master484]

It was Super Street Fighter 2, sorry http://eab.abime.net/showthread.php?t=41499 http://eab.abime.net/showthread.php?t=48633

No worries, I didn't know about this Super Street Fighter 2 project either, until now.

---
---

Thanks for the ideas and suggestions everyone.

For the playable demo, I think I'll be targeting both ECS and AGA, and try to fit it into 2 MB of RAM, with space left for music and sound.

I'll experiment with different BOB + sprite combinations to see what works best.

I noticed that the fireballs actually flash in the arcade version too, so actually I might use the flashing BOBs idea for them. That still looks good in 50 FPS at least, making the fireballs look partially transparent.

And also in a typical SF2 gameplay screen, most of the time there are no fireballs shown at all, and when there are it's usually just 1 fireball, unless you play Ryu vs Ken. So I think all available sprites should be used for the characters instead, because they are constantly shown on screen.

But as mentioned before, 16 color sprites may not be possible to do in Blitz, or with the normal Blitz commands at least. So I can only use 4 color sprites.

---

So I think I'll use the following system: One of the characters will always be a 100% BOB created with Blits. And the other character will always be a BOB + Sprite combination, and it will get 6 four color sprites which are used to reduce the size of the BOB as much as possible.

By putting 2 four color sprites on top of each other to the same XY, I can use 6 sprites to create three 16*Unlimited Y "sprite zones" into the character, and 6 colors from the BOB palette will be available for these zones (because 4 color sprites are 3 colors + transparent, and even numbered sprites use one set of 3 colors and odd numbered another 3 colors).

So all 4 skin tones + white and black can be used for these sprite zones. I looked through the characters, and these 6 colors work fine for most of them; the entire characters can't be drawn with these colors, but it's enough to make them smaller, and BOB blits handle the rest.

And before each fight, there would be a logic system that chooses which one of the two characters gets to be a sprite + BOB combination, and the best case is always chosen.

This system should work well at least for:

Honda - The best case of all, almost the whole character can be made with sprites

Zangief - many parts can be sprites, although the red wounds in the body have to be made dark brown, but it's not a big deal, trousers and boots will still be red BOBs

Sagat - same as above, only the yellow hand and leg tapes have to be white. Trousers need to be blue, so they're a BOB.

Dhalsim - almost same as Sagat, just the yellow leg bracers have to be white. Trousers need to be yellow so they're a BOB. During the leg/hand stretch attacks 48 pixels lenght can be covered by sprites, or alternatively used for the body part and make the hands/legs BOBs.

---

For all other characters good sprite uses are hands and legs during attack frames, many of them fit into the "48 X pixels * unlimited Y" zone that our 6 sprites can cover. Worst character case is Blanka, because of the all yellow body color, so I think it wont get a sprite version at all.

This system means that every character needs to have 2 versions: a "100% BOB version" and a "sprite + BOB combination" version. This is easy to make, although time consuming...but I have time.

With some luck this should be enough to make most fighter combinations run at 50 FPS even on ECS.

The shadows stay always in the same vertical position. So one could switch to EHB for this 16 or so scanlines.

Unfortunately this is not possible in Blitz Basic. Although display modes can be changed mid-screen, Blitz requires that there are at least 2 "empty" Y lines before a new display mode starts. These 2 lines can't display any graphics and will appear as two lines of Color 0. So display mode changing mid-frame in Blitz can be mainly used only for status panels and such.

And 3D scrolling of the floor would be cool, but I would only consider adding it if I first get two of biggest characters to run firmly at 50 FPS with plenty of steam left.

And the character / background palette set-up may not yet be final, but I'll think about it more if I first get the engine to run at acceptable speed. I already have basic GFX frames ripped for Chun Li and Ken, so I'll try my ideas with them first, and it works well, then I'll try the same with the bigger characters. This should take a few weeks maybe.

[apex]

Fantastic work.

[dlfrsilver]

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.

[chb]

Originally Posted by Master484

But as mentioned before, 16 color sprites may not be possible to do in Blitz, or with the normal Blitz commands at least. So I can only use 4 color sprites.

That's very unfortunate, as in 4-color mode the sprite colors are very limited. Every sprite pair gets its own palette from the upper sixteen colors, sprite 0/1 have color 17,18,19, sprite 2/3 color 21,22,23, 4/5 have 25,26,27, 6/7 have 29,30,31. So you'd have probably quite a bit of redundant colors.

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?

Originally Posted by Master484

So I think I'll use the following system: One of the characters will always be a 100% BOB created with Blits. And the other character will always be a BOB + Sprite combination, and it will get 6 four color sprites which are used to reduce the size of the BOB as much as possible.

By putting 2 four color sprites on top of each other to the same XY, I can use 6 sprites to create three 16*Unlimited Y "sprite zones" into the character, and 6 colors from the BOB palette will be available for these zones (because 4 color sprites are 3 colors + transparent, and even numbered sprites use one set of 3 colors and odd numbered another 3 colors).

So all 4 skin tones + white and black can be used for these sprite zones. I looked through the characters, and these 6 colors work fine for most of them; the entire characters can't be drawn with these colors, but it's enough to make them smaller, and BOB blits handle the rest.

With ECS, you cannot have only two 3-color palettes for odd and even sprites without setting the 16-color mode (and use non-overlapping sprite pairs). I'm also a bit surprised that Blitz does not allow you to have full eight sprites - there's probably no need to make the screen full 320 pix in width?

Originally Posted by Master484

And before each fight, there would be a logic system that chooses which one of the two characters gets to be a sprite + BOB combination, and the best case is always chosen.

This system means that every character needs to have 2 versions: a "100% BOB version" and a "sprite + BOB combination" version. This is easy to make, although time consuming...but I have time.

With some luck this should be enough to make most fighter combinations run at 50 FPS even on ECS.

It's surely a lot of work to get it implemented well, preferably without storing two complete sets on disk but setting up sprites/bobs at level loading time, but could give optimal results indeed.

Originally Posted by Master484

Unfortunately this is not possible in Blitz Basic. Although display modes can be changed mid-screen, Blitz requires that there are at least 2 "empty" Y lines before a new display mode starts. These 2 lines can't display any graphics and will appear as two lines of Color 0. So display mode changing mid-frame in Blitz can be mainly used only for status panels and such.

Ah, ok, that's a pity. You could still try to insert custom copperlist commands with customString, but it's maybe not worth the hassle.

Originally Posted by Master484

And 3D scrolling of the floor would be cool, but I would only consider adding it if I first get two of biggest characters to run firmly at 50 FPS with plenty of steam left.

Yep, sensible approach - it's just icing on the cake.

All the best for your project, I'm curious to see its progress.

[dlfrsilver]

yes getting the 2 big characters working at full speed is the main thing, then the ground scroll a la elfmania

[Tigerskunk]

Great "little side project".

(I am a little bit afraid though, that your Sprite/BOB-Kombination-idea might prove to be a bit too complicated in practical usage. )

[roondar]

Originally Posted by Steril707

Great "little side project".

(I am a little bit afraid though, that your Sprite/BOB-Kombination-idea might prove to be a bit too complicated in practical usage. )

I remember reading somewhere that Mortal Kombat on the Amiga used such a trick and it was abandoned for the sequel - for that exact reason. However, I can't find the interview any more so I could be misremembering.