English Amiga Board

English Amiga Board (https://eab.abime.net/index.php)
-   Coders. Blitz Basic (https://eab.abime.net/forumdisplay.php?f=126)
-   -   SNES SF2 Dual PF Demo (https://eab.abime.net/showthread.php?t=96990)

Master484 08 April 2019 14:59

SNES SF2 Dual PF Demo
 
3 Attachment(s)
Okay, so here is another AGA Street Fighter 2 tech demo. Originally I didn't plan to release this until it was "ready", meaning that there would be some real gameplay. But as usual, I ran out of motivation, and so the project has been sitting on my hard drive since 2017. And because in all likehood I'll never continue it, I thought that I might as well post it here, because people are once again talking about how to properly convert SF2 to Amiga, and at least this demo theoretically demostrates that one could do SF2 in AGA at 50 FPS, with background anims and parallax layers. :great

ADF with Blitz source code is in the attachment of this post.


http://eab.abime.net/attachment.php?...1&d=1554727856


So, system requirement is basic A1200 with 2 MB of Chip RAM. You can scroll the screen with the joystick.

All graphics are from the SNES version of Super SF2, because the size of the SNES characters are perfect for the AGA sprites.

Technical info:

- 64 pixel wide AGA sprites for the characters, so 4 characters can be drawn without any slowdown.

- 3 parallax layers.

- Game runs in 16+16 color dual playfield background, so this way we get two parallax layers.

- Third parallax layer is created using copper effects (sky and sea) and blitted objects to the back playfield (the mountain and the island in the horizon) .

- Characters are 100% sprites, so Blitter is 100% dedicated into drawing background animations only.

All background anims are "Blocks" with no transparency, and they are drawn to pixel positions that are multiples of 16. This makes them super fast to draw. And the lack of transparency doesn't matter, because the Back Playfield always "shines through" the color 0 pixels of the Front PF. So this way we get free transparency.

Also every Block draw automatically "clears" the block that was drawn to that spot previously, so there is no need for "background restore" or anything like that.

And finally some coppers were added to the Front playfield: the light greens of the stone ground are copper generated, and so are some of the palm tree colors on the top.

And all of this still easily runs at 50 FPS on a standard A1200. About half of the frame time still remains.

---

Also here are some character recolors that I did for the SNES Super SF2:

http://eab.abime.net/attachment.php?...1&d=1554727856

In the SNES version every character has an unique 16 color palette, which add up to 212 colors for all characters. But I managed to convert them all to a single 16 color palette, without any noticeable quality loss.

So in theory, a very nice looking AGA conversion could be done, which would be graphically almost identical to the SNES version, if not even better, and it would run at 50 FPS.

And memory wise too this is possible, all frames in both directions for two characters take about 1,2 Megs, so it's just an issue of fitting rest of the stuff into 800 kb, which should be totally possible.

---

However, like I have said before, a project like this is a massive undertaking, and it is unlikely that a full conversion will ever be done.

Only a small one level demo with some of the moves and some kind of simple AI opponent is realistically possible. But even something simple like this will take lots of time to accomplish.

Graphical demos like this are realtively fast and fun to make, but when it comes to actual game coding, things suddenly get slow, hard and boring. :)

This is also why I decided to release this demo; I got bored in programming actual gameplay, and was left with a useless Graphics demo. And back then I thought that later I would continue it, but clearly that isn't going to happen. :D

So here it is, at least the concept is interesting, and hopefully the stuff in the source code is useful for someone. As always, you can freely use the code in your own projects, or even continue this project, if you want.

malko 08 April 2019 15:23

Characters are dancing in the sky here but the visual result is amazing ! Even the movements are smooth. :great :great :great
Nice BB2 tech demo

roondar 08 April 2019 15:33

That's pretty good. Nice to see some AGA DPF love ;)

zero 08 April 2019 18:30

Really nice work!

The only thing about the palette is that you actually need two palettes per character, so you can have two players and distinguish them.

Tigerskunk 08 April 2019 19:17

Quote:

Originally Posted by Master484 (Post 1315253)
Graphical demos like this are realtively fast and fun to make, but when it comes to actual game coding, things suddenly get slow, hard and boring. :)
.

Haha, I know that feeling so well.
I guess that is the reason there are still so many Amiga demo coders around, and not that many game coders...

Master484 09 April 2019 12:05

Quote:

The only thing about the palette is that you actually need two palettes per character, so you can have two players and distinguish them.
Yes, but that would be only needed in 2 Player mode if both players choose the same character.

So an easy way to solve this problem is not to allow the same character for both players.

But also it is possible to switch character colors with a Blitz "Remap" command, and this way there can be two versions of the same character in memory, both having the same palette, but with different color usage. So for example if both players choose Ryu, one can have a blue outfit and the other one can be red.

turrican3 09 April 2019 17:10

you did a really good job with the colours. :great

Puggsy 10 April 2019 17:00

I think is often underestimated how much it takes to actually run a game behind something looking like this, especially Street fighter 2 turbo.
Like those Sonic demos that are not actually a game.

Now turn it into a full game and tell me to shut up and I will be happy ;-)

redblade 11 April 2019 06:42

youtube video??

Congratulations. When you do a sprite sheet? Do you do 16x16 all the way down and link the sprites with a table or do you draw the complete sprite. (i.e a kick would be 64 pixels wide??).

If AGA Dualpf is 16 colours on each playfield, what colour pens do the sprite colours use are they COLOUR32->COLOUR48.

Downloading now.

Great work.

Solo Kazuki 11 April 2019 08:19

@Master484

Is not possible to have different colorsets on AGA? It could be in this case individual 16 colour palette for every fighter. It not look bad now, but colors are washed out and inaccurate.

To be exact, there is possibility to have different palette for even and odd sprites. While there are only 2 objects (and only sometimes projectiles), You can have individual 16c palette (or even two as in original game, for mirror matches) for every fighter.

Edit: I'm almost sure that SNES version have similar trick and every fighter have about 16 different colors. In this case AGA version should look almost identical.
I don't understand why you want 16 colours fixed palette for everything like in OCS/ECS...

Daedalus 11 April 2019 09:53

Quote:

Originally Posted by Solo Kazuki (Post 1315820)
@Master484

Is not possible to have different colorsets on AGA? It could be in this case individual 16 colour palette for every fighter. It not look bad now, but colors are washed out and inaccurate.

To be exact, there is possibility to have different palette for even and odd sprites. While there are only 2 objects (and only sometimes projectiles), You can have individual 16c palette (or even two as in original game, for mirror matches) for every fighter.

Unfortunately, that's only for 3-colour sprites. To use 15-colour sprites, two 3-colour sprites have to be coupled together. The resulting joined sprite will then use the palette for odd-numbered sprites, so all 15-colour sprites use the same palette. The difference to ECS is that this palette can be any bank of colours within the 256 registers, and is not restricted to pens 17-31 (and therefore shared with the background) as it would be under ECS.

I do think that the palette could be stretched a little however, if certain pens were allocated on the fly for different characters. for example, have 9 pens common to all fighters, and the remaining 6 pens split as 3 fighter-specific colours each. This would increase the palette across the range of fighters.

Solo Kazuki 11 April 2019 11:04

So how it could be done in Super Street Fighter II Turbo?

http://hol.abime.net/2215/screenshot

https://www.youtube.com/watch?v=mAkVINHrBFc

https://www.youtube.com/watch?v=fbNKim13TeE

https://www.youtube.com/watch?v=mmg3QWm3lys

https://www.youtube.com/watch?v=zkyhhMRBCro

https://www.youtube.com/watch?v=bieK1oXQpsk

I don't know how they do this, but game for sure have different palettes for fighters, at least some colours.

And mind that You have six different colour sets of every fighter!

http://hol.abime.net/pic_full/screen...5_screen10.png

http://hol.abime.net/pic_full/screen...5_screen12.png

http://hol.abime.net/pic_full/screen...5_screen14.png

http://hol.abime.net/pic_full/screen...5_screen16.png

http://hol.abime.net/pic_full/screen...5_screen18.png

Daedalus 11 April 2019 12:19

Is it a case that it's not using sprites at all? Sprites could be used for the GUI elements, leaving the blitter to draw the characters. Perhaps it uses a custom dual playfield split, e.g. 5+3, so the players have 32 pens and the background 8? I'm just speculating...

Different colour sets for the same character are easy enough to do with the method I suggested of having a few pens that are dynamically set for each character. That lets you change the clothing colours very easily for example.

Solo Kazuki 11 April 2019 12:57

It's not that simple. It's rather not 5 + 3 bitplanes, because backgrounds for sure have more than 8 colors. Let's take this screenshot:

http://hol.abime.net/pic_full/screen...5_screen10.png

You have 2x blue (roof and rack) 2x red (sign) 2x grey (buldings, rooster and shirts) 4x brown/orange (many places including pavement) green (sign and below it on right) and white (many places). It's fast calculation without some more colors, e.g sky. So it's probably 4 bitplanes, not 3.

Probably it's 4 bitplanes for background... and some trick because there are different palettes for players, it's rather not shared 4 bitplanes.

Edit: counting colors, maybe each fighter have 8 independent colors, so it's maybe 4 + 2 + 2. Or some 4 bitplane palette based on some universal and some individual colors, similar for this what You propose with sprites.

Master484 11 April 2019 15:14

Quote:

youtube video??
Too lazy to do such a thing. Usually I just wait until somebody makes one. :)

Quote:

When you do a sprite sheet?
I already have complete sprite sheets for Ryu and Zangief. But in this demo I used just a few frames to demonstrate the graphics.

But although the sheets are ready, there are no actual animation routines of any kind for the players. That sort of stuff would be added only if I decided to continue this project.

Quote:

Do you do 16x16 all the way down and link the sprites with a table or do you draw the complete sprite. (i.e a kick would be 64 pixels wide??)
I draw the complete sprites, and sprite size is 64 pixels (which is an AGA only feature, OCS sprites can be only 16 pixels wide). So all sprite frames are 64 pixels wide, or if more width is needed, then two 64 pixel wide sprites would be combined.

Quote:

If AGA Dualpf is 16 colours on each playfield, what colour pens do the sprite colours use are they COLOUR32->COLOUR48.
Yes, in this demo the sprite colors are located at 32-48. AGA sprite colors can be freely located anywhere in the screen palette, which in this case is a 48 color palette, divided into the 2 playfields and the sprites. So the color setup is 16+16+16.

---

Quote:

Is not possible to have different colorsets on AGA?
This is possible, but in this simple tech demo I haven't planned things that far.

The sprite recolors that I posted are the first step into making the SNES graphics work on the Amiga.

And because sprites are used for the characters, we are limited to 16 colors, so both fighters on screen have to use the same palette.

But as Daedalus mentioned, it could be possible to arrange the colors so that there would be some common colors, which would be shared by all fighters, and some unique colors, which would be fighter specific. And the example of 9 common colors + 3 Fighter one colors + 3 Fighter two colors could be one way to make it work.

It would certainly be nice to have some unique colors, and I'm sure that a palette system can be made which makes this possible.

Quote:

So how it could be done in Super Street Fighter II Turbo?
In this game the fighters are most likely blitter objects, not sprites. And it seems to run in 64 color mode; I analysed the screenshots and it seems that 32 colors are reserved for the background only, and both fighters have their own 16 color palettes. So the palette setup is 32+16+16 . And the health bars and other stuff are most likely sprites, which again have their own 16 colors, outside of the 64 color main palette.

In this case it's very easy to have different palettes for both fighters, because both have their own "palette space" of 16 colors.

dlfrsilver 11 April 2019 23:48

Ssf2t on a1200 use 128 colors. 64 for backgrounds and 64 for sprites.
The game opens 8 bpl.

Master484 13 April 2019 13:18

Quote:

Ssf2t on a1200 use 128 colors. 64 for backgrounds and 64 for sprites.
The game opens 8 bpl.
Yes, I analysed the screenshots a little bit more, and it's indeed 128 colors mode.


http://hol.abime.net/pic_full/screen...5_screen10.png


In the above screenshot the colors are used as follows: background has 32 colors, Balrog has 16 colors and Chun Li has 16 colors. And then the fighter portraits have their own 16 color palettes. This adds up to 96 colors. And the remaining 32 colors are used for the energy bars, score numbers, fighter names, and the timer. The letters and the timer numbers look like they could have copper gradients, but in this case I think the gradients are made by just using the remaining colors.

---

This game looks so great in screenshots...in fact it looks almost better than the arcade, because on the smaller Amiga 320*256 screen the sprites appear to be bigger than in the arcade version. :D

And I have been thinking about this...the background is 32 colors...So it could be split into a 16+16 dual PF, and it would still be 32 colors, but now with parallax. And then the AGA 64 pixel wide sprites could be used for the characters...two 16 color sprites could be used for one character, so they could be 128 pixel wide. But the problem is that for the arcade size sprites, 128 pixels is not enough for all frames. So there would be some sprite flicker during certain frames. And the unified 16 color sprite palette would still be a problem too.

But if the AGA sprites can't handle it, then maybe things could be done like they're are in this game: just drop the color mode to 64: using 32 for backgrounds and 16+16 colors for the characters, and draw them with the blitter. And then boost BG colors with the copper, and use sprites to make the background animations or even some parallax. Together the sprites and copper would easily boost the 32 color background to 64 colors, and both players would have their own 16 color palette, meaning arcade perfect colors (they're 16c in the arcade too).

But of course with the arcade GFX Chip RAM usage is the biggest problem. But I'm playing around with the arcade graphics, to see if it's somehow possible that enough frames could be squeezed in to make an acceptable game. Maybe, just maybe the A1200 could handle it...But this is all just speculation. :)

dlfrsilver 13 April 2019 14:47

The huge sprites are build with 16x16 tiles, like on cps2.

drHirudo 14 April 2019 16:54

Quote:

Originally Posted by Master484 (Post 1315903)
Too lazy to do such a thing. Usually I just wait until somebody makes one. :)

Here is one:

https://www.youtube.com/watch?v=Y4khkkLpwI0

Master484 15 April 2019 16:35

Quote:

Here is one:

[ Show youtube player ]
Thanks. :great

Quote:

The huge sprites are build with 16x16 tiles, like on cps2.
Ok, this could be one reason why the game is so slow.

Although dividing the BOBs to smaller pieces is the right way to do it, because it saves Chip RAM. But the number of pieces per animation frame should be as low as possible, so that the amount of Blitter operations needed to draw the characters stays as low as possible.

If everything is in 16*16 pieces, then drawing one character needs something like 30 16*16 objects, which means that the Blitter needs to be started 30 times. Or actually 60 times because there are two players.

Codetapper's site has all GFX from the Us Gold SF2:
http://codetapper.com/amiga/rips/street-fighter-2/

Those graphics sheets are a good example of how to split big objects into smaller pieces in an "Amiga friendly" way. So one frame could be for example one 48*32 block and one 64*48 block. Only two Blitter operations needed. :)


All times are GMT +2. The time now is 23:58.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.

Page generated in 0.04940 seconds with 11 queries