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

[roondar]

Originally Posted by Gilbert

Thank you, This is a very great response roondar. 17 or 12 fps is actually faster than I was expecting Can you lose a bitplane to make it 128 colours? That would work on Ghouls N Ghosts I think. The most colours I could get on screen on the first level was 112 for the arcade version.

You can certainly use a bitplane less, but this won't really help that much - this will get you no more than a 12% increase in performance at best. Which likely won't translate to a higher frame rate.

As for 12/17FPS, this is really not enough for good gameplay for games like this. Even 25FPS usually doesn't feel "right" when playing, 17 or 12 FPS starts to feel like moving through muck. These games really do kind of need 50FPS to truly feel right.

"32+8 colours "brute force" dual layer screen IIRC" I don't fully understand this. Does that mean 32 color screen + a sprite layer? or something else?

It means using all 8 bitplanes (normally this gives you a 256 colour screen) and then using the Blitter to update the background 3 bitplanes (which give 8 colours) while having the front 5 bitplanes (which give 32 colours) scroll through the hardware.

Maybe also we could use less colours and then do palette changes with the copper when you reach a scan line? I'm pretty sure you could make it look 98% like the arcade with 60% the number of colours-on screen for example

This is certainly possible, but won't be as flexible as the arcade is. It's quite difficult to make this work with anything other than the static (i.e. background) graphics. Using it to make the enemies change colour is a lot harder unless you restrict them vertically.

[Master484]

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?

The memory use of Amiga graphics can be calculated with this formula: (Width / 8) * Height * Bitplanes

Width is always rounded up to the nearest power of 16. So for example if something is 50 pixels wide, it actually consumes 64 pixels worth of Chip RAM. And if the graphic is a blitter object (bob), then the Bitplanes also need a "mask", which adds one extra bitplane. So 16 color bobs means 4 bitplanes + 1 bitplane for the mask. But Sprites don't have the mask cost.

So for example if we take the normal standing pose of the SNES version of Zangief, that frame is of size 64*93 pixels.

So if it was a bob, it would consume (64 / 8) * 93 * 5 = 3720 bytes = 3,72 kb

Now, let's assume that the character has 200 frames of animation. This would be 3,72 kb * 200 = 744 kb.

But that is only the "facing right" frames. If we want the mirrored frames also in RAM, then it consumes double the 744 kb, which is 1,48 megs.

So right away we can see that the whole game can never fit into memory; only this one character eats 75 % of the 2 Megabytes that we have.

And this is just the SNES version character. In the arcade version, even the smallest fighters have much bigger graphics than anything found in the SNES version.

[DanScott]

The first thing you do is think "how do we flip the frames, so we only have to store half"

You could use the CPU... with a 64k word flip buffer

But how can we optimise the flip?

Well.. the solution is to take each frame, and only flip one half of it. So whichever way the character wants to face, you either flip the top half or the bottom half. This reduces your flip CPU cost to around 50%

Of course, there is also a way to flip image data using the blitter in several passes. Again, we'd only need to flip the half of the sprite that needs flipping.

Now I would also hazard a guess, that many characters do have a lot of blank space in their frames. You'd want to really try to avoid storing some of that blank space.

A simple way would be to slice the frames into 16 pixel wide vertical strips, and remove space from top and bottom. This would surely save some memory on quite a few frames.

There are other ways that you could save memory too, by slicing the frames up slightly differently, but I'll leave that for someone else to figure out


And just to add.. if you used one 16 colour playfield for the background, and one 16 colour playfield for one character, and hardware sprites for another character, you would not need to store any masks for the character frames, and you would use very simple D = A blitter modes to draw them (either to the playfield, or into the sprite data)

[DanScott]

Of all the games we talk about, i think that SF2 could translate really well to A1200 / CD32 and produce a version that is not too far from perfect

[Tigerskunk]

Originally Posted by DanScott

But how can we optimise the flip?

Well.. the solution is to take each frame, and only flip one half of it. So whichever way the character wants to face, you either flip the top half or the bottom half. This reduces your flip CPU cost to around 50%

This is so easy that its genius. Wow.
Thanks for that, will come in handy with my next game.

[DanScott]

Originally Posted by Steril707

This is so easy that its genius. Wow.
Thanks for that, will come in handy with my next game.

I learned that one at Core from Simon Phipps. I think they used this method on the main character in Wolfchild.

[rare_j]

Originally Posted by DanScott

I learned that one at Core from Simon Phipps. I think they used this method on the main character in Wolfchild.

Ha ha, that is sneaky. I like it a lot. Took me a minute to figure it out.

[Old_Bob]

Originally Posted by DanScott

The first thing you do is think "how do we flip the frames, so we only have to store half"

You could use the CPU... with a 64k word flip buffer

But how can we optimise the flip?

Well.. the solution is to take each frame, and only flip one half of it. So whichever way the character wants to face, you either flip the top half or the bottom half. This reduces your flip CPU cost to around 50%

I'd also like to say that this is a beautifully sneaky solution. I simply *have* to have a little fiddle around with this...

Originally Posted by DanScott

Of course, there is also a way to flip image data using the blitter in several passes. Again, we'd only need to flip the half of the sprite that needs flipping.

At a guess, I think using the CPU would be the best option of the two? Given that the blitter could be drawing one fighter while the 020 chews on the flip for the other?

B

[DanScott]

oops.. my bad.. it would be a 128k word flip table, and that would require shifting the original word up to get a long word offset into the table... might be better working with bytes in that case (a 256 byte table)

[DanScott]

Let's compare byte vs. word (just the main flipping of 16 bytes of data in a simple way), assuming a0 points to our source, a1 points to our destination, and a2 points to our flip table:

using a byte flip table (256 bytes):

move.b (a0)+,d0 ;8 cycles
move.b (a2,d0.b),-(a1) ;18 cycles
move.b (a0)+,d0 ;8 cycles
move.b (a2,d0.b),-(a1) ;18 cycles
; total 52 cycles per word


using a word flip table (128kb):

moveq #0,d0 ;4 cycles
move.w (a0)+,d0 ;8 cycles
add.l d0,d0 ;8 cycles
move.w (a2,d0.l),-(a1) ;18 cycles
; total 38 cycles per word

[DanScott]

I wonder if this would work for a 64k table:

move.w (a0)+,d0  ; 8
add.w d0,d0          ; 4
move.w (a2,d0.w),d0 ;14
addx.w d0,d0       ;4
move.w d0,-(a1)  ;8

38 cycles again.. but table can be 64k... essentialy you are flipping the low 15 bits, and the addx moves the leftmost bit to the right

[roondar]

On A1200/CD32 it may actually be more effective to run the flipping on the CPU with a small routine that fits in the cache. You could run (part of) the flip while you blit the non-flipped part. Key would be to do the flipping into registers as much as possible and only read/write in 32 bit chunks to keep memory accesses low.

Not tested this, but it does intuitively feel like a reasonable approach.

[DanScott]

Originally Posted by roondar

On A1200/CD32 it may actually be more effective to run the flipping on the CPU with a small routine that fits in the cache. You could run (part of) the flip while you blit the non-flipped part. Key would be to do the flipping into registers as much as possible and only read/write in 32 bit chunks to keep memory accesses low.

Not tested this, but it does intuitively feel like a reasonable approach.

Definitely!

[Gilbert]

You guys know your stuff! I'm not a proper coder but I thought flipping sprites was fairly common on the Amiga? - even AMOS on A500 had flipping for both sprites and Bobs and it didn't seem to slow it down if at all.

I agree it seems hard to fit all the graphics into memory but we can use the decompression method. I read what Bob wrote about it being hard but I still think the extra power of the CD32's CPU could do it - esp with sprites and dual playfield mode being used to get a close - but not arcade perfect version. The SNES version missed out some animation frames from the arcade and no one really noticed.

I would also say the original Arcade version of Streetfighter is just over 7Mb (it's 58 Megabit) and that has 12 fighters in there. So I think the sprites could take up less space than you think? Maybe we are overestimating? Unless 58 Megabit is wrong - but it is way larger than both the SNES and Megadrive carts.

Originally Posted by DanScott

Of all the games we talk about, i think that SF2 could translate really well to A1200 / CD32 and produce a version that is not too far from perfect

I agree but I also think a close version of Ghouls N Ghosts, Strider, Area 88 (UN Squadron) etc are very possible - as shown by the 16 bit consoles.

Originally Posted by roondar

You can certainly use a bitplane less, but this won't really help that much - this will get you no more than a 12% increase in performance at best. Which likely won't translate to a higher frame rate.

As for 12/17FPS, this is really not enough for good gameplay for games like this. Even 25FPS usually doesn't feel "right" when playing, 17 or 12 FPS starts to feel like moving through muck. These games really do kind of need 50FPS to truly feel right.
It means using all 8 bitplanes (normally this gives you a 256 colour screen) and then using the Blitter to update the background 3 bitplanes (which give 8 colours) while having the front 5 bitplanes (which give 32 colours) scroll through the hardware.
This is certainly possible, but won't be as flexible as the arcade is. It's quite difficult to make this work with anything other than the static (i.e. background) graphics. Using it to make the enemies change colour is a lot harder unless you restrict them vertically.

Thanks for this roondar. I do think 25fps games feel pretty good if you run the control and logic code at 50fps but then draw everything only every 25fps. I'm sure Rainbow Islands and R-Type on Amiga are both 25fps for example. These would have probably been bad conversions if they ran them at 50fps - less things on screen, maybe smaller screen etc

[Thorham]

Originally Posted by DanScott

using a word flip table (128kb):

moveq #0,d0 ;4 cycles
move.w (a0)+,d0 ;8 cycles
add.l d0,d0 ;8 cycles
move.w (a2,d0.l),-(a1) ;18 cycles
; total 38 cycles per word

On a 68020 you can just do this:

    move.w  (a0)+,d0
    move.w  (a2,d0.w*2),-(a1)

That *2 is free.

[sokolovic]

Well surprinsgly this dead end thread is becoming very interesting with all the technicall comments of many.

[DanScott]

Originally Posted by Thorham

On a 68020 you can just do this:

    move.w  (a0)+,d0
    move.w  (a2,d0.w*2),-(a1)

That *2 is free.

yes of course, I forgot totally about that My vanilla 68k/OCS head seems to be permanently switched on

[S0ulA55a551n]

Sorry for the slight O/T but people have mentioned just playing on mame. This might interest some

https://www.nintendo.com/games/detai...tadium-switch/

and this

https://www.eurogamer.net/articles/2...intendo-switch