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

[Tsak]

Originally Posted by Retro1234

if Tsak is on board then I guess it's probably a sound project

I should clarify here I'm not on board with this project. But Pixel Shade is helping with KK's Dread projet (which I am part of) so we have discussed about this a bit

[Tigerskunk]

None of the stuff we see in that video is "magic" or hasn't been done or thought of before, which you would know if you'd follow any of the threads here on eab where people talk 100s of pages about how some game could be done technically (see the "Metal Slug - Madman Task" or Codetapper's old Rygar thread.

The thing is ALWAYS, is somebody willing to put YEARS of work into a project to finish it through or not (I had a scrolling parallaxing stage of my SHMUP with BOBs flying around running in around 3 weeks. The rest of the game took me 4 years to code. Shit like Hiscore lists, dynamic level switching, tools for level creation and assets conversion, integration of music players, data compression unto disk, and and and...)

Until then, this is a nice demo, but Master484's demo looked great as well.
The only difference I see here is a massively better presentation in that Youtube video.

I see exactly the same discussions we have seen in a few other threads we had on the probability of a SF2 conversion starting to happen here.

Until someone solves all these points that I am too tired right now to list here and presents me a fully fledged SF2 that I can play that doesn't suck donkey balls, I don't take this anymore seriously like any other little demo I have seen countless times on different platforms over the years.

[Tsak]

You have to admit though that at least from an artwork perspective (but also the way that this implementation is done) it's not your typical 'here, see a couple bobs moving and call it a demo'. It's clear that there's some serious thought and effort put into this to maximise the visual result. I don't remember seeing any version or demo of this game (including all AGA tries) looking this good and utilising that many tricks to get it done.

[roondar]

Originally Posted by Steril707

You though anyone here who knows two shits about Amiga coding thought that this demo is not possible on the Amiga1200?

Honestly, the only thing in the video I find to be perhaps a bit optimistic is the repeated BPLCON4 palette swaps planned in combination with horizontal scrolling. Might need a bit more space between the crowd elements on the boat to do that without issues.

Well, that and perhaps the memory issue (the relevant part of that Blanka sheet came out to be huge). But I'm also pretty convinced that a much better way of storing all the GFX than just dumping it raw into memory can be found.

Agreed. I am convinced your conversion will be amazing.

Absolutely, it has all the hallmarks of the right approach already

[mcgeezer]

Originally Posted by roondar

Well, that and perhaps the memory issue (the relevant part of that Blanka sheet came out to be huge). But I'm also pretty convinced that a much better way of storing all the GFX than just dumping it raw into memory can be found.
Absolutely, it has all the hallmarks of the right approach already

It’s a big big big problem to overcome though and people seem to be brushing over this issue.

When i make a game, before any code is written i spend a fair bit of time working out the memory requirements.

For me, the answer is still “no”. The stock A1200 or CD32 can’t run Street Fighter 2 close to the arcade. The only way i’ll be convinced is if someone calculates a couple of the characters and fits them into memory with reasonable assumptions - in this entire thread or the video, none of that was mentioned or is rather glossed over.

@Gilbert - your guarantees are worthless.

[roondar]

Originally Posted by mcgeezer

It’s a big big big problem to overcome though and people seem to be brushing over this issue.

Well yes, I absolutely didn't intend to make it into a non-issue with my comment. If you just dump the GFX into 4BPL and resize down to 75% as suggested by the video, one character will take over 1MB just for the frames facing one way.

That said, it'd be interesting to see how much ROM space is actually used for these characters in the game. If that number is way, way lower than what I calculated, then using the same storage method might work. Though obviously blitting to the screen/real time flipping probably becomes a nightmare if you use a cartridge-style format.

When i make a game, before any code is written i spend a fair bit of time working out the memory requirements.

Wise, I had that bite me in the behind for my last big project. Ended up having to effectively cancel it and start from scratch. This time I do have a memory map ready

For me, the answer is still “no”. The stock A1200 or CD32 can’t run Street Fighter 2 close to the arcade. The only way i’ll be convinced is if someone calculates a couple of the characters and fits them into memory with reasonable assumptions - in this entire thread or the video, none of that was mentioned or is rather glossed over.

Memory wise, I'm leaning to a maybe - depending on how close it needs to get for it to "count". GFX wise (i.e. can we display a screen such as shown in last parts of the video), I'm leaning towards probably, yes. Though perhaps with a few minor compromises.

[mcgeezer]

Originally Posted by roondar

Well yes, I absolutely didn't intend to make it into a non-issue with my comment. If you just dump the GFX into 4BPL and resize down to 75% as suggested by the video, one character will take over 1MB just for the frames facing one way.

That said, it'd be interesting to see how much ROM space is actually used for these characters in the game. If that number is way, way lower than what I calculated, then using the same storage method might work. Though obviously blitting to the screen/real time flipping probably becomes a nightmare if you use a cartridge-style format.
Wise, I had that bite me in the behind for my last big project. Ended up having to effectively cancel it and start from scratch. This time I do have a memory map ready
Memory wise, I'm leaning to a maybe - depending on how close it needs to get for it to "count". GFX wise (i.e. can we display a screen such as shown in last parts of the video), I'm leaning towards probably, yes. Though perhaps with a few minor compromises.

Yep, I'm totally fine with compromises, all the consoles had to make them. I just had a look and the SNES seems to have a 4Mbit rom which is likely compressed. The SNES can flip sprites so I think I wise thing to do would be to try and take the SNES assets and implement "on the fly" tile flipping when building those bitmaps that go into the hardware sprites.

I''l go and take a look in the SNES assets now and see how big they are.

Cleaned the post - BippyM

[Retro1234]

I'd be interested in thoughts on SNES sprite sheets reduced to 16colour or MegaDrive.

[mcgeezer]

So I had a quick look at the main character in the SNES game..

Here's the Sprite Sheet I used...

https://www.spriters-resource.com/sn...f2/sheet/5557/

I cut it down to 1280 x 840 and to 16 colours, ran it through promotion into 16x16 tile maps.... this gave out an image of 320x2192.

So memory wise this would chew up 350Kb of Chip ram.

Now that tileset has alot of crap in it so maybe reduce it by 100kb to 250kb.

So memory use wise.

500Kb for Sprite data
65kb for background screen buffer (512x256 x 16 colours)
130kb for foreground screen buffer (1024x256 x 16 colours)
250kb for music and Sound FX
200Kb program code

400kb for shit I forgot.

-------
1545kb

hmmmmmm...... maybe... more analysis needed but I'm warming to the idea.

[Retro1234]

what is rough size for the sprite sheet whole not in tiles.

[Muzza]

Originally Posted by mcgeezer

Dedicate all blitter and cpu time to reconstructing the player sprites from 16x16 tiles, 4 even sprites for the 1st player, 4 odd sprites for the 2nd player, this then allows for 16 colours dedicated per player (64 colours in total without copper effects), each player then has maxium 128x224 size.

Is this right? You’d need attached sprites for 16 colours and then they would all share the same odd sprites palette. So you’d have 16 colours for both characters rather than per character...?

[d4rk3lf]

As a hardware (and software) Amiga noob, I have a question for you guys:

If Street Fighter 2 is very hard to do (even with compromises) on plain A1200, how come we have that amazing port of Mortal Kombat 2 that runs very nicely on Amiga 500 - 1MB?
Is Mortal Kombat 2 technically much simpler to make, or something else is case?
And MOrtal Kombat 2 have digitized characters, not drawn, that I assume is harder to show in limited palette of Amiga 500.
Yet, the game runs with no slow downs, with amazing gameplay feel, and amazing graphics and sound.
It has magic, fatalities, everything...

If SF2 would be made in similar engine (same sprites size... etc), do you think we could have much better port even on plain A500, or I am missing something obvious here?

[DanScott]

I don't think those sprite sheets on Spriters Resource are even laid out in a good way.. All those bounding lines, text, and the frames probably not even aligned correctly to 16 pixel boundaries (I've noticed this before when grabbing test sprite data from there)

[mcgeezer]

Originally Posted by Muzza

Is this right? You’d need attached sprites for 16 colours and then they would all share the same odd sprites palette. So you’d have 16 colours for both characters rather than per character...?

No, on AGA the Even Sprites can have a 16 colour palette separate to the Odd ones.

Edit 1: Mind you i'm setting here pissed so I might be wrong.

Edit 2: I'm right by the looks of it... $dff10c (BPLCON4) controls bits for the palette of odd and even sprite allocations.

Bits 0-3 select the odd palette (0-7)
Bits 4-7 select the even palette (0-7)

[Tsak]

Originally Posted by mcgeezer

So I had a quick look at the main character in the SNES game..

Here's the Sprite Sheet I used...

https://www.spriters-resource.com/sn...f2/sheet/5557/

I cut it down to 1280 x 840 and to 16 colours, ran it through promotion into 16x16 tile maps.... this gave out an image of 320x2192.

So memory wise this would chew up 350Kb of Chip ram.

Now that tileset has alot of crap in it so maybe reduce it by 100kb to 250kb.

So memory use wise.

500Kb for Sprite data
65kb for background screen buffer (512x256 x 16 colours)
130kb for foreground screen buffer (1024x256 x 16 colours)
250kb for music and Sound FX
200Kb program code

400kb for shit I forgot.

-------
1545kb

hmmmmmm...... maybe... more analysis needed but I'm warming to the idea.

Nice, granted you have a ton of dublicate data in there, which just happened to be at different positions (when making a grid out of this sheet) so the are just cropped as different tiles. Also supposed the shadow will be an additional object you can get the number of actual needed tiles down even more.

[Retro1234]

yeah I think if you aligned the characters you might get a much smaller tile set, I not sure it's any smaller is it?

but it might be better to have a custom tile maker so even if there not aligned it can spot a reused section.

[kamelito]

This guy did reversed the all game and rewrote it entirely in C, I guess he could help you.
There's also a lot of technical info about the game in his blog.
https://sf2platinum.wordpress.com/

[mcgeezer]

Originally Posted by Tsak

Nice, granted you have a ton of dublicate data in there, which just happened to be at different positions (when making a grid out of this sheet) so the are just cropped as different tiles. Also supposed the shadow will be an additional object you can get the number of actual needed tiles down even more.

There is plenty of optimisation that could be done but it is best to stick to a fixed amount of ram... 500kb for both players looks about enough.

[roondar]

Originally Posted by d4rk3lf

As a hardware (and software) Amiga noob, I have a question for you guys:

If Street Fighter 2 is very hard to do (even with compromises) on plain A1200, how come we have that amazing port of Mortal Kombat 2 that runs very nicely on Amiga 500 - 1MB?
Is Mortal Kombat 2 technically much simpler to make, or something else is case?

The thing with Mortal Kombat 2 on the A500 is that the correct compromises were made. The people behind that port just did a very good job on not trying to exceed the systems limits and focussed heavily on getting the game to play well instead. So, they made the characters much smaller and less colourful than the Arcade ones, removed the parallax/background animation, removed many animation frames, removed most of the music, etc, etc.

If you can live with similar compromises, you should be able to make a version of SF-II on the A500 that plays similarly well as MK-II does. However, what we're talking about with the A1200 port is about something that is much closer to the arcade. Still downgraded, but overall with most features in tact. And that is much harder. Basically the closer you get, the harder it becomes.

[Muzza]

Originally Posted by mcgeezer

No, on AGA the Even Sprites can have a 16 colour palette separate to the Odd ones.

Edit 1: Mind you i'm setting here pissed so I might be wrong.

Edit 2: I'm right by the looks of it... $dff10c (BPLCON4) controls bits for the palette of odd and even sprite allocations.

Bits 0-3 select the odd palette (0-7)
Bits 4-7 select the even palette (0-7)

All true but when you attach them they have to be adjacent sprites (even must attach to odd) and they all use the odd palette. So you have four attached sprites up to 64 pixels wide but sadly all sharing the same 16 colours.
If this isn’t true I want to know how as it recently frustrated me!