Can The Amiga CD32 Run Perfect Versions of Capcom CPS1 Games?

[Gilbert]

Originally Posted by Old_Bob

2mb actually isn't much, dude. At least, not if you're expecting 256 or even 128 colour games. A game like SF2 would devour that fairly quickly. The only real option that leaves is realtime decompression of assets as they're needed. Definitely not great for framerate. Especially if you're doing it all in Chip RAM.

B

That's a fair point. Can the extra power of the 32 bit 14Mhz CPU be leveraged? SF2 probably only needs 6Mhz - 8Mhz of that to run the basic game code when optimized for the Amiga. Maybe the chip ram barrier is too much - but you could store the first 3 frames of animation of every non standard move in memory, and then start to decompress the rest of the frames after the player initiates that move. It could probably be done because you'd have a fair number of frames delay to decompress the data before it was needed. Is this possible?

Also there is the vanilla option of using a different 16 colours for each fighter - one can use sprites and the other the blitter. If you were being super adventurous - you could effectively blit over sprites or put some sprites over a blitter object to get the same 32 colours for each character. Would still look a lot better than standard Amiga version and you could probably get all the frames in memory. The arcade would use 4 bitplanes I imagine but be tile based. I still would guess not a huge number of different colours used per fighter in the arcade. I would actually guess at 32 max but I have been wrong before here

EDIT : Have just done a test on the arcade (SF2) sprites and they use 16 colours per fighter The SNES also has 16 colours per fighter but the sprites are slightly weedier (not as beefy) and it misses a few animation frames out.

Arcade sprite for Guile (looks wider here because CPS1 has narrow width pixels)


Arcade Sprites here:
https://www.spriters-resource.com/ar...treetfighter2/

Problem is number of sprites. Guile has 237 animation frames (facing one way) +24 for win poses (can be halved by only loading one win pose per round) + 7 for projectile animation (sonic boom). Wonder how much memory this would take up?

Originally Posted by mcgeezer

£30,000 is cheap, you should see how much they pumped into that new fangled Cyber Punk game ... BIIIIIIILLLIONS.

If you took the Arcade version of Ghouls and Ghosts and ported it to the CD32, not worrying about Resolution you could achieve 50frames per second.

But the resolution would be something like 128px X 128px.

I'm definitely up to contribute £50. The rest of the CD32 userbase - it's up to you!

[Old_Bob]

Originally Posted by Gilbert

That's a fair point. Can the extra power of the 32 bit 14Mhz CPU be leveraged?

It certainly doesn't hurt. As you correctly point out, the overhead for the logic code driving everything would be fairly minimal in comparison to everything else and a 68020 would rip through that part fairly quickly. But you're always going to bump up against the limits of CD32's ball achingly slow Chip RAM. And, if your decompression routine is running while the blitter's going it'll be slowed down even more.

Originally Posted by Gilbert

Also there is the vanilla option of using a different 16 colours for each fighter

Even if you're only using 16 palette entries for each fighter, you'd still need to blit in to all the active bitplanes, which means you're hitting the next limiting factor which is the slow blitter.



The two timing bars here illustrate just how much of a problem this is. It's taking almost a complete frame to merely blit two fighters. Adding an erase step pushes this deep in to 25fps territory and a decompression step would add yet more pain. The test program this is taken from uses a 128 colour background with 64 separate colours for each fighter.

I think the best approach for a game like SF2 on CD32 would be using large AGA hardware sprites. There is a post somewhere on the board with a Blitz Basic (I think) demo doing just that. Add two scrolling 16 colour background layers in dual playfield mode, or ditch the parallax and have a single, but much nicer, 128 colour background.

Originally Posted by Gilbert

Problem is number of sprites. Guile has 237 animation frames (facing one way) +24 for win poses (can be halved by only loading one win pose per round) + 7 for projectile animation (sonic boom). Wonder how much memory this would take up?

A lot. Even using hardware sprites, which would be the most memory efficient option. And, remembering that we can't trivially flip them in hardware so we require left and right copies for each frame means that, even with compression, a fair amount of frames would likely have to be ditched. And there's also the audio samples on top of that which also must fit in Chip RAM somewhere. These take up a surprising amount of memory. Even at a reduced quality 11khz sample rate. Realistically, the only thing the CD32 has to its advantage in this scenario is CD music.

B