Coder shows possible way in which some elements of Street Fighter 2 might be possible

[vulture]

yeah, maybe they're lost in the background with those colours

[DanScott]

So I tried the background conversion on Dhalsim's elephant level, as that's probably one of the more colourful BG's in the game.

This is the result of a straight conversion to 8 colours per line:





There is a lot of horizontal guff in the top half of the image, but the bottom of the Elephants downwards and the floor, look fine...

So I did another conversion with some kind of dither (Stukki or Burkes or something like that), and combined the dithered top 60% with the bottom 40% of the 1st image above (this is still 8 colours per line)




The next step is to look at removing the green figure (and possibly the yellow elephant "jackets") from the background image, and to add that (those) as a sprite overlay, so the yellow and green does not steal valuable colours from the main areas of the background

Also the coder of the image converter is going to add some extra features for me (like ordered dither, which I think looks better in general for games, rather than these random distribution based dithers), as well as being able to "lock" a colour into a particular palette index over a specified range (handy to ensure that maybe a sky colour is always free from any banding, enabling us to also add some gradient too for more colour)

[Havie]

Originally Posted by DanScott

So I tried the background conversion on Dhalsim's elephant level, as that's probably one of the more colourful BG's in the game.

This is the result of a straight conversion to 8 colours per line:





There is a lot of horizontal guff in the top half of the image, but the bottom of the Elephants downwards and the floor, look fine...

So I did another conversion with some kind of dither (Stukki or Burkes or something like that), and combined the dithered top 60% with the bottom 40% of the 1st image above (this is still 8 colours per line)




The next step is to look at removing the green figure (and possibly the yellow elephant "jackets") from the background image, and to add that (those) as a sprite overlay, so the yellow and green does not steal valuable colours from the main areas of the background

Also the coder of the image converter is going to add some extra features for me (like ordered dither, which I think looks better in general for games, rather than these random distribution based dithers), as well as being able to "lock" a colour into a particular palette index over a specified range (handy to ensure that maybe a sky colour is always free from any banding, enabling us to also add some gradient too for more colour)

So this is how you are solving the elephant in the room or do you anticipate adding the other elephants on top?

[DanScott]

Originally Posted by Havie

So this is how you are solving the elephant in the room or do you anticipate adding the other elephants on top?

Quite simply.. nope

or maybe just a trunk and a tusk poking on from the left or right using the hardware sprites

Basically, if you want an OCS version that plays at 50fps, with the parallax floor, and features as much as possible from the original game (or the SNES version), then there are always going to have to be some elements that are omitted..

Sure we could look at the techniques to do a 16 colour version, or a 32 colour version, but you'll NEVER get those at 50fps..... let alone fit all those extra bitplanes of graphic data, without losing a lot of animation frames

[Bruce Abbott]

Originally Posted by DanScott

The next step is to look at removing the green figure (and possibly the yellow elephant "jackets") from the background image, and to add that (those) as a sprite overlay, so the yellow and green does not steal valuable colours from the main areas of the background

I think it looks great already, apart from a green band running behind the figure's head (which should be easy to tweak out). I also like the dithering.

[d4rk3lf]

Originally Posted by DanScott

Sure we could look at the techniques to do a 16 colour version, or a 32 colour version, but you'll NEVER get those at 50fps..... let alone fit all those extra bitplanes of graphic data, without losing a lot of animation frames

Could it be 50 fps if you abandon any parallax effect, make characters 16 color, and bg 8 colors? Just curious.
(I ask, because when I tried with Photoshop, 16 colors characters looked so much closer to the arcade... even maybe 12 colors)

[PortuguesePilot]

Originally Posted by DanScott

Quite simply.. nope

or maybe just a trunk and a tusk poking on from the left or right using the hardware sprites

Basically, if you want an OCS version that plays at 50fps, with the parallax floor, and features as much as possible from the original game (or the SNES version), then there are always going to have to be some elements that are omitted..

Sure we could look at the techniques to do a 16 colour version, or a 32 colour version, but you'll NEVER get those at 50fps..... let alone fit all those extra bitplanes of graphic data, without losing a lot of animation frames

What if we focus on AGA? What can be enhanced/extended in comparison to OCS?

[sokolovic]

Pretty much everything ? I guess it could double the colors for each playfield, the bobs and for the sprites, more chip ram, bigger sprites, much faster CPU quarter pixel scrolling (don't if this one could be possible or relevant thought).

But there is already someone working on an AGA version, at least an engine to facilitate this kind of game.

[Tigerskunk]

Originally Posted by PortuguesePilot

What if we focus on AGA? What can be enhanced/extended in comparison to OCS?

I think Pixelshape and Neoman have already impressively shown what the AGA version would look like, and explained it very well from a technical perspective in their video.

It's not really interesting to talk about something that quite clear how to do, is it?

[d4rk3lf]

Originally Posted by Steril707

I think Pixelshape and Neoman have already impressively shown what the AGA version would look like, and explained it very well from a technical perspective in their video.

Exactly.

For me too, an OCS version is far more interesting to see.
What sort of limitation we need to accept, and what would be some approximate maximum.

And after we finish it, we will start thinking how to do an C64 version.

[sokolovic]

Last news, PixelShade was saying they gonna try to ask permission from Capcom since they don't seem to be that reluctant with fan games (they even gave support to Megaman X Street Fighter). Wait and see.

[Master484]

What happens when you use 15 but have some common colours set in registers 6,7,8 & 9?

Using 16 color BOBs, that would give 4 common colors + 5 unique colors for each fighter. Or actually 6 unique colors for each, but the transparent color 0 eats one of the fighter 1 colors, so I would make it a 4+5+5 system, and the last color in register 15 is left free to be used for something else.

The 4 common colors I would probably make black + white + one blue + one red, to make them equally useful for as many different characters as possible. So 9 colors in total for each fighter, with 5 of them freely selectable for both. And the end result should look pretty good.

---

Another option would be to use 8 color bobs in either 16 or 32 color mode, with the first bob drawn using color registers 0-7 and the second using registers in 8-15. There is a Blitz Basic command that can do this. This would give only 7 colors per fighter, but all are freely selectable, which should still boost the quality considerably in comparison to an unified 7 color palette. And we get the big RAM save for using 8 color bobs.

[DanScott]

Forget about Blitz or AMOS, it doesn't have the horse power to do all this

[mcgeezer]

Originally Posted by Master484

Using 16 color BOBs, that would give 4 common colors + 5 unique colors for each fighter. Or actually 6 unique colors for each, but the transparent color 0 eats one of the fighter 1 colors, so I would make it a 4+5+5 system, and the last color in register 15 is left free to be used for something else.

The 4 common colors I would probably make black + white + one blue + one red, to make them equally useful for as many different characters as possible. So 9 colors in total for each fighter, with 5 of them freely selectable for both. And the end result should look pretty good.

I have some time this afternoon and so I'm going to implement this.

If I can reconstruct both hardware sprites (16 colours) in a decent amount of frame time then I suspect the game is possible (near SNES perfect).

I would need the sprite sheets in 128x128 pixel frames, the upper half facing one way (left) and the lower half facing the other (right).

It is best to use big, large sprites for a test so ideally the largest volume pixels used in that 128x128 matrix.

Geezer

[redblade]

Silly question.

Is it possible to do 16 colours + sprites? 9 common colours + 1 transparency and 5 independent colours for each back drop and not do dual playfield + sprites?

or maybe 10 common colours and 5 independent for the back ground adjustable by vertical scan line?

[Tigerskunk]

Originally Posted by d4rk3lf

Exactly.

For me too, an OCS version is far more interesting to see.
What sort of limitation we need to accept, and what would be some approximate maximum.

And after we finish it, we will start thinking how to do an C64 version.

I'd go for the ZX81 one...

BTW, I thought your palette looked better than Maste484's in itself, but it just didn't work well with the colourful background. Would need a much less saturated background, then it would work quite well though.. Maybe cool for another game.

[DanScott]

Originally Posted by mcgeezer

I have some time this afternoon and so I'm going to implement this.

If I can reconstruct both hardware sprites (16 colours) in a decent amount of frame time then I suspect the game is possible (near SNES perfect).

I would need the sprite sheets in 128x128 pixel frames, the upper half facing one way (left) and the lower half facing the other (right).

It is best to use big, large sprites for a test so ideally the largest volume pixels used in that 128x128 matrix.

Geezer

You'd be best writing a converter.. that grabs the data, flips the correct half automatically, and spits out .dat files with all the info etc...

[mcgeezer]

Originally Posted by DanScott

You'd be best writing a converter.. that grabs the data, flips the correct half automatically, and spits out .dat files with all the info etc...

Yeah, do it manually first. (First few frames i mean)

No fuckin way though am i converting all them frames though.

I’ll write some python but someone will need to put the sprite sheets together - no idea how they are packed in the snes cart.

[d4rk3lf]

Originally Posted by Steril707

BTW, I thought your palette looked better than Maste484's in itself, but it just didn't work well with the colourful background....

Thanks, but...
I'd hesitate to call it "my palette", because it's basically Photoshop automated palette (with a little bit of tweaking options).
Actually, making it more contrasted and saturated should be fairly easy... I might try later...
One great thing about PS is that you can do a palette on one picture (like I did), and then just make automated action to convert all other images to same colors...

And yeah, I totally agree that Master484 characters looked great on that bg.

[DanScott]

I'm just gonna carry on playing around with 7 colour assets for OCS

Actually, it's quite fun trying out different ideas, and finding ways of doing cool(ish) stuff