Street Fighter 2 OCS Version Discussions

[redblade]

Originally Posted by 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

What tool did you use for that? It looks good, I'm just wondering why E Honda's skin tone didn't go the same as the other fighters and why the green wasn't incorporated into Guile.

It's quite amazing the results you can get out of with a well chosen 16 colour palette.

[DanScott]

Originally Posted by redblade

@Dan: I'm interested in how you will store your data for the blitter objects for this. Will you store 32x32 first then followed by 16x16 boxes at the end?

Or do you just have a look up table pointing to 16x16 sprites for each frame? Which would take a lot of memory on top of all the gfx data.

I haven't decided yet. It depends what route I want to take.

Maybe to split them into 16x16 tiles (thus removing duplicate tiles from frames that share them)

I have to look into whether I can flip them real time, and whether I can calculate the mask realtime, for the character that needs masking.

[roondar]

Originally Posted by Toni Galvez

The mixer is really good, all the samples are stored in fast ram, to the mixer send the mixed audio frame to chip ram buffer (very small one) and it works great, ask NandiusC, he can tell you how good the mixer work, is amazing.

Originally Posted by DanScott

I'll certainly have a look at it when I come to adding sound. Would be great to have 3 channels of sound effects and 3 channels of music playing if there's enough CPU time left.. perhaps even just mixing 2 channels of SFX into one at a slightly lower bitrate would suffice too ? This would give the advantage of not having to scale down the source data so much to avoid overflow on the addition

Originally Posted by Antiriad_UK

Oh I didn't know that was you, was watching the sprite one just the other day. Nice one

Originally Posted by Akira

Me neither!
My bad about misinterptreting the video roondar. I thought 5% was for the A1200.
This does mean though you need Fast RAM. That's kind of an odd configuration, OCS + Fast RAM. Leaves a lot of OCS systems out.

Originally Posted by Steril707

Damn, that sounds super interesting.
Pun intended..

Will have a look into it..

@Roondar: Why'd you chose the number of the beast for your buffer?
@Roondar 2: Have you or anyone else tried out if this plays along with PTPlayer?

Originally Posted by pink^abyss

I would also go for 2 channels at ~6khz. This would mean 6000/50=120 samples each frame. This means you need to read 2*30 longwords and only add them together each frame. Samples should before dynamics compressed to have good volume at only 7 bit...

Funny you should be talking about my mixer... I've literally just released a new version, which is much faster and has some extra features. To keep this from going off-topic any further: should anyone have any questions, I made a new thread about this http://eab.abime.net/showthread.php?t=105777

@Steril (1): I didn't actually 'choose' the number, it's simply 3 times the number of bytes you need to update per frame to keep up with an 11KHz sample rate
@Steril (2): I implemented this alongside PHX's protracker player. Had to change it ever so slightly to remove any writes/interrupts for AUD3, but that wasn't too much trouble.

[lmimmfn]

Originally Posted by roondar

Funny you should be talking about my mixer... I've literally just released a new version, which is much faster and has some extra features. To keep this from going off-topic any further: should anyone have any questions, I made a new thread about this http://eab.abime.net/showthread.php?t=105777

@Steril (1): I didn't actually 'choose' the number, it's simply 3 times the number of bytes you need to update per frame to keep up with an 11KHz sample rate
@Steril (2): I implemented this alongside PHX's protracker player. Had to change it ever so slightly to remove any writes/interrupts for AUD3, but that wasn't too much trouble.

I really enjoyed your video and the method, it opens doors to some possibilities, e.g. the add algorithm, sounds could be transformed so they are louder etc. its fun, there could be per game/samples better ways to mix the samples.

[roondar]

Thanks! And yes indeed, I do believe quite strongly that on the Amiga especially you need to pick your solutions based on what fits. The architecture is very flexible, but still limited.

[lmimmfn]

Originally Posted by roondar

Thanks! And yes indeed, I do believe quite strongly that on the Amiga especially you need to pick your solutions based on what fits. The architecture is very flexible, but still limited.

Exactly, its all about compromises and tuning those for the best possible outcome, we wouldnt have the awesone soundtrack in Turrican 2 title screen or the fantastic visual effects/colours in Lionheart without compromises.

[Tigerskunk]

@Roondar: Would love to have a go at your new improved mixer. Could you send me this as a zip? LHA is a pain in the ass for me since I do cross dev.
Wish I had known about this earlier, but will surely use this in my next game.

[saimon69]

Originally Posted by Steril707

@Roondar: Would love to have a go at your new improved mixer. Could you send me this as a zip? LHA is a pain in the ass for me since I do cross dev.
Wish I had known about this earlier, but will surely use this in my next game.

IzArc on windows seems to handle lha and lzh properly [whoops forgot you are on Mac]

[malko]

Originally Posted by saimon69

IzArc on windows seems to handle lha and lzh properly [whoops forgot you are on Mac]

There is "7zX" for MAC.

[JoeJoe]

Or simply unlha the file in the emu.Mostly the HD or directory is mounted as drive hd0

[roondar]

Originally Posted by Steril707

@Roondar: Would love to have a go at your new improved mixer. Could you send me this as a zip? LHA is a pain in the ass for me since I do cross dev.
Wish I had known about this earlier, but will surely use this in my next game.

Sure thing, I put a zipped version in the Zone for you: http://eab.abime.net/zone/Audio_Mixing_V2.zip

I'll be putting it on my website as well, as you made me realize that a zip file version is quite useful regardless of platform for those of us who primarily use cross-development

[Tigerskunk]

Originally Posted by roondar

Sure thing, I put a zipped version in the Zone for you: http://eab.abime.net/zone/Audio_Mixing_V2.zip

I'll be putting it on my website as well, as you made me realize that a zip file version is quite useful regardless of platform for those of us who primarily use cross-development

Thanks, mate!

I would need to transfer it to my real 1200, un-lha it there and transfer it back to my mac otherwise.. LOL.

I use my emu just for testing out asm code.

[roondar]

Originally Posted by Steril707

Thanks, mate!

I would need to transfer it to my real 1200, un-lha it there and transfer it back to my mac otherwise.. LOL.

I use my emu just for testing out asm code.

No problem, I aim to please

[pink^abyss]

Originally Posted by DanScott

I haven't decided yet. It depends what route I want to take.

Maybe to split them into 16x16 tiles (thus removing duplicate tiles from frames that share them)

I have to look into whether I can flip them real time, and whether I can calculate the mask realtime, for the character that needs masking.

I'm sure you already thought of these savings but anyway:
-Use non interleaved gfx for one the characters to need only a single mask
-Use adjustable Y height when splitting. There will be a sweet spot between minimum height and blitter setup time (i would assume >=6 pixel height is a win).
-For optimum width one can search for min/max within height spans and divide by 16 for simplicity

Choosing the optimum height and width is not as simple as it sounds. A dumb but near perfect alogrithm could do 'random' splits. After a 100k iterations you should have pretty good result.
I think one can reduce the save gfx amount by a further 50% compared to regular 16:16 grid cutting.

[pink^abyss]

I think my last ideas can be simplified:
It should be already sufficent to split the gfx into horizontal stripes with a multiple width of 16 and a fixed height of 16 pixel (for simplicity). This should already save 50% of the original frame size.

To get this down to 25% of the original size one could pack these stripes with LZ4 and unpack them on the fly (this will be around 1kb - 2kb for each character image). As you have 5-6 stripes for each character you can balance how many stripes you are able to unpack each frame. This may introduce 1-2 frames latency tho i don't think anyone will notice if you don't tell

[dodke]

If you pack the frames with LZ4 and the animations only play at max half the screen update frame rate you could only unpack one at a time, alternating between the characters.

[Retro1234]

this will save room on disk but will still have to be unpacked into memory, if you start putting several 16x16 bobs on screen this is going to be alot slower than one large bob.

[chb]

Originally Posted by pink^abyss

This may introduce 1-2 frames latency tho i don't think anyone will notice if you don't tell

One could store the first frame of every move uncompressed to hide that latency (the animation speed is probably way less than 50 fps, more like every 3rd frame or so).

[saimon69]

Will surely complicate rendering, but what about keeping limbs divided? Could help with storage?

[Tigerskunk]

I thought with 3BPL we can get a whole sheet into RAM?