Street Fighter 2 OCS Version Discussions

[touko]

Yeah you're right,but the snes has another advantage for SF2, it has a third background layer .

[DanScott]

Originally Posted by touko

Yeah you're right,but the snes has another advantage for SF2, it have a third background layer .

The SNES's use of background layers is quite bizzare in SF2.

But we're not talking about the advantage of the SNES here... we're talking about how we get as close to it as visually possible on a 1985 computer This does mean there have to be compromises in certain areas.

[touko]

Yes, and can't wait to see what you can do with the old OCS amiga,for now i'am impressed by what you have shown, even if it's a mockup based on the amiga features .
I'am impatient to see if this can be done on the real thing .

[Galahad/FLT]

Originally Posted by Adrian Browne

Fascinating. I honestly thought the a500 was incapable of producing a snes like conversion in the play-ability department. Good idea to make an original game as its probably more interesting to you as a project and for us too of course. Elfmania is the only beat em up game that springs to mind as being a somewhat otherworldly accomplishment from a technical point of view. God knows how they did what they did.

Well, its always easier if you don't have to follow what someone else has written.

Elfmania, they could do whatever they wanted, exploit advantages and limitations of the OCS hardware.

With SF2, it has to have a certain look, it has to use certain colours, it has to sound a certain way...... none of those contraints on an original product for Amiga, hence why so many original games on Amiga look so good.

[Tsak]

Originally Posted by DanScott

a) yes, you could... as long as there was some space either side, you could quite easily shift it left and right, however it would then also be needing colours from the back playfield.

Indeed, so it really mostly depends on the copperising you do with those to be able and correctly color this.
However you could (perhaps) get better detail this way than just using 3 colors (as you do with sprites), even if the sprites palette can use different hues. In the arcade version f.e. the back building does seem to share similar hues with the foreground, unlike the SNES version.

Originally Posted by DanScott

I think that clouds could still also be added above the building, and be static / very slow moving

Right, that can be done regardless. I wanted to ask though, in case of sprite clouds, could you also do a per line shift? So the result would look more like a mist instead of having bigger cloud chunks.

Originally Posted by DanScott

b) yes to this too, i did think about this, but the the SNES doesn't seem to do any vertical parallax, and not sure the coin op does either.. but for a different game that is "inspired" by SF2 (that's the overall plan) it could be done for sure with careful planning and consideration for an already complicated copperlist

Sure, the arcade does it btw.

[DanScott]

Originally Posted by Tsak

Sure, the arcade does it btw.

Maybe it does on that level, seems there's different things going on on different levels?

On Ken's level, the boat moves up and down, but the other backgrond elements seem totally fixed (background boat, horizon, clouds etc...)

Anyway, I am basing my stuff on the SNES... anything extra I can find time to do will be a bonus

[DanScott]

Originally Posted by Tsak

I wanted to ask though, in case of sprite clouds, could you also do a per line shift? So the result would look more like a mist instead of having bigger cloud chunks.

If anything I'd like to get as close to the SNES as possible in that respect.

Not sure we will have the copper capacity to do a per line shift. In dual playfield we don't have the luxury of 8 pixel copper instructions, so options are more limited there

[roondar]

Originally Posted by DanScott

There *might* be a way to use some hardware sprites up there for the scoreboard, but not sure yet, need to think about that.. might be possible though

Now I did that fully-covered-background with non-repeating sprite's tech demo a while back so I figure I might at least do a back of the envelope style calculation for this

Rough calculation: it's running 6BPL Dual Playfield, so one Copper move every 16 pixels during display. Assuming 128 pixels of sprite data/4 colours for the bars you can load 16 registers in that time. This would be equivalent to 5 sprites reloaded (1x position, 2x data) or a total of 208 pixels of sprite imagery that can be displayed there. But we can do even better: during the 5 new sprites being displayed (80 pixels), 5 more Copper moves can be done.

As we still had one left from the previous run (16>5*3 ) we can add one more reloaded sprite into the mix for a total status bar width of 224 pixels. Requires repositioning of all 8 sprite channels at the end of the scanline though.

And this effect will most definitely work as I've already done something almost exactly like this.

Question is if we have enough Copper moves. You need 8 for the Copper colour reloading, 8 for the sprite reset and 21 for the Sprite drawing. For 6BPL@304px wide, you normally would have space for 37 Copper moves so it should just fit. Except you probably need to use a Wait instruction to time the sprite drawing so you'll probably end at a maximum of 208 pixels of sprite data (and room for a spare Copper move for ehh, something).

Limitations: uses all sprite channels during that area and costs a bit of DMA. Plus, all the reloaded sprite data needs to be changed in the Copper list rather than using just DMA for sprites.

[DanScott]

Originally Posted by roondar

Now I did that fully-covered-background with non-repeating sprite's tech demo a while back so I figure I might at least do a back of the envelope style calculation for this

Rough calculation: it's running 6BPL Dual Playfield, so one Copper move every 16 pixels during display. Assuming 128 pixels of sprite data/4 colours for the bars you can load 16 registers in that time. This would be equivalent to 5 sprites reloaded (1x position, 2x data) or a total of 208 pixels of sprite imagery that can be displayed there. But we can do even better: during the 5 new sprites being displayed (80 pixels), 5 more Copper moves can be done.

As we still had one left from the previous run (16>5*3 ) we can add one more reloaded sprite into the mix for a total status bar width of 224 pixels. Requires repositioning of all 8 sprite channels at the end of the scanline though.

And this effect will most definitely work as I've already done something almost exactly like this.

Question is if we have enough Copper moves. You need 8 for the Copper colour reloading, 8 for the sprite reset and 21 for the Sprite drawing. For 6BPL@304px wide, you normally would have space for 37 Copper moves so it should just fit. Except you probably need to use a Wait instruction to time the sprite drawing so you'll probably end at a maximum of 208 pixels of sprite data (and room for a spare Copper move for ehh, something).

Limitations: uses all sprite channels during that area and costs a bit of DMA. Plus, all the reloaded sprite data needs to be changed in the Copper list rather than using just DMA for sprites.

If it helps, the screen will be 256 pixels wide (272 actual fetch width for scrolling), so we get a few more copper instructions per line

The advantages of sprites, is that it doesn't need to be updated completely each frame... only need to update what changes, and even then can do it on a cycle (one "element" each frame)

Defnitely worth a try though.. as having this info displayed on the playfield is going to require a complete redraw each frame!

I did dynamic sprite reloading in De Profundis, in the intro, there are 4 bitplanes (with the newspaper), and the text is done with HW sprites (16 per line)

[roondar]

I think that Parasol Stars uses a similar idea, but just for one BPL of one sprite (move one sprite, reload one BPL of data). Works in 4BPL, but not 6BPL. This idea (i.e. the one I posted/you used in the intro of De Profundis) will work, as long as you let the sprite DMA do the fetching for the first 128 pixels.

Anyway, it will help get to 224 pixels, but not more. The issue is reloading the sprites as they are being displayed. The extra Copper time means we won't have to bother chopping off the last possible sprite to make the wait fit and can do whatever other effects we need easier but it won't increase the reload speed. Only dropping to 5 or 4 BPL would do that and we can't do that

[pink^abyss]

Originally Posted by DanScott

If we set aside a generous 100k for music and sound effects (this is one project where PreTracker might come in handy)

PreTracker is very bad at emulating crash cymbals.. a an important instrument in the SF2 OST

[DanScott]

Originally Posted by pink^abyss

PreTracker is very bad at emulating crash cymbals.. a an important instrument in the SF2 OST

We can spare a few kb for a crash

[DanScott]

Originally Posted by Tsak

b) Would you consider to vertically parallax the building as well, i.e. when the characters jump?

Looking at the SNES version again, there is some vertical movement of the back building, but it's very subtle.

The snes seems to have a 200 pixel high playfield displayed in a 192 high window, so only seems so scroll 8 pixels vertically... the building appears to shift by just 3 or 4.. it's very subtle, but IS there.. and is something we can do

[no9]

Originally Posted by pink^abyss

PreTracker is very bad at emulating crash cymbals.. a an important instrument in the SF2 OST

But you know what is good at this... [ Show youtube player ]

[DanScott]

Yeah, I'd imagine a cymbal sample pack might have some cymbal samples in it...

Can we keep on topic please !

[Master484]

The screenshots look really good, very close to SNES quality.

Will the demo have moving characters? If you need some more animation frames mapped to this 8 color palette, then just tell which characters and what animations you want, and I can convert them.

[Toni Galvez]

About the sprite size, I recomend to use the SNES graphics size. Arcade graphics are too big.

With 16 colours I did this conversion, you can see all the characters look very well with the same palette(and the backgrounds have the same palette as well. It is a gif image, if someone want it, ask me.

https://ibb.co/nsL1jgy

About the music, DJ Metune got the SF2 Ryu stage music with the exact arcade instruments translate to a 60k module (I can say, it sound incredibly amazing, much better than any other SF2 song you heard on Amiga), it uses mostly 3 channels. Ask him.

[saimon69]

Toni, i know you don;t like my methods
(that rely a lot on the brain filling up missing parts and sound effects keeping the focus of attention) but once i get rid of some real life annoyance want to test some two channel tunes!

[Toni Galvez]

Originally Posted by saimon69

Toni, i know you don;t like my methods
(that rely a lot on the brain filling up missing parts and sound effects keeping the focus of attention) but once i get rid of some real life annoyance want to test some two channel tunes!

You can keep improving yourself, it is what we all do, improving our methods to make the music sound better and take less space.

I think, make the RYU song better than DJ Metune in 60k, sounding like the arcade, using mostly 3 channels, is almost impossible to make it better.

[Toni Galvez]

Please guys, about the sound effects, there is a nice sound mixing routine that mix fixed frequency samples with very low CPU usage (like 5%) where you can get up to 3 samples mixed at once in one Amiga channel.

Check here [ Show youtube player ]

The best is, you can use all the samples from Fast memory, so, it won't take the chip memory at all.

We are using this routine on our new Amiga OCS game and it works amazingly well.