Arcade / Console --> Amiga conversion discussions

[roondar]

Originally Posted by AnimaInCorpore

Interesting point. Probably the symptomatic problem of the whole matter.

It seems that porting arcade games of the Amiga era cannot hold the quality standard of what one would expect from the system at all. Simply because the whole task cannot be achieved without a tremendous work and still you're afraid of that the result may be unsatisfactory for many.

Yeah, that is what you get when people expect more on the Amiga than perhaps is reasonable (as in, 50Hz updates, 32 colour graphics + sprite layer background + extra copper effects + great sound and running in 512KB please).

Note that this is more about people's expectations than platform capability. The Amiga can do some pretty impressive stuff if you use it in 16 colour mode and add some sprites. The problem is that people tend to want 32 colour (or more) ports and that is where you start to lose quite a bit of performance on OCS due to memory contention and the like.

Originally Posted by mcgeezer

Yes, but would probably need 1mb chip ram.

On the video the boss at the end struggles to keep going at 50 frames, the Amiga would have no such problem because you could put the system into Dual Playfield mode and shift the monster independently without cookie cutting.

I'm not so sure that Dual Playfield would be the best option, it would definitely work but it would lose quite a bit of colour from the scene.

Originally Posted by frank_b

How much memory is required for the graphics? This version needs 4 meg of unified memory on an STe. It may exceed even 2 mb of chip RAM for some levels.

The original required 12 meg of RAM Monster board (12 meg of blittable address space) or Falcon required!

Thats quite a lot of memory and would pose a problem for a port. The question is, of course, how much of this can be alleviated by copying graphics from a fast memory expansion and how much of a performance hit this would create. As long as each single frame doesn't need more than fits in chip memory, it should still be possible (albeit with potential performance issues as I've described).

Originally Posted by frank_b

Masking performance should be similar on both machines. It's single pass on the STE via a clever blitter "trick".

Even so, the Amiga does have sprites to help out.

A simple use of these would be to have the player character and his weapons be sprites which would save a bit of time. Depending, of course, on the amount of 'bullets' the knight gets.

However, if you didn't mind putting in the extra effort, you could also use those sprite channels as a part of the boss. This would, essentially, give you a 64 pixel wide band* of the boss that doesn't need any masking or restoring at all and uses virtually no DMA bandwidth to draw (sprites are insanely fast compared to the Blitter).

Since the game runs in 16 colours, this doesn't pose any problem for sprite colour register usage.

*) I am, of course, assuming that a 16 colour boss is what is desired

[dlfrsilver]

Originally Posted by roondar

Yeah, that is what you get when people expect more on the Amiga than perhaps is reasonable (as in, 50Hz updates, 32 colour graphics + sprite layer background + extra copper effects + great sound and running in 512KB please).

Note that this is more about people's expectations than platform capability. The Amiga can do some pretty impressive stuff if you use it in 16 colour mode and add some sprites. The problem is that people tend to want 32 colour (or more) ports and that is where you start to lose quite a bit of performance on OCS due to memory contention and the like.



I'm not so sure that Dual Playfield would be the best option, it would definitely work but it would lose quite a bit of colour from the scene.



Thats quite a lot of memory and would pose a problem for a port. The question is, of course, how much of this can be alleviated by copying graphics from a fast memory expansion and how much of a performance hit this would create. As long as each single frame doesn't need more than fits in chip memory, it should still be possible (albeit with potential performance issues as I've described).


Even so, the Amiga does have sprites to help out.

A simple use of these would be to have the player character and his weapons be sprites which would save a bit of time. Depending, of course, on the amount of 'bullets' the knight gets.

However, if you didn't mind putting in the extra effort, you could also use those sprite channels as a part of the boss. This would, essentially, give you a 64 pixel wide band* of the boss that doesn't need any masking or restoring at all and uses virtually no DMA bandwidth to draw (sprites are insanely fast compared to the Blitter).

Since the game runs in 16 colours, this doesn't pose any problem for sprite colour register usage.

*) I am, of course, assuming that a 16 colour boss is what is desired

The big problem with capcom CPS1 games is that everything is unified.

such big games need to be splitted per program parts and level parts.

The original need 12 mb of ram because everything is a huge single block.

[frank_b]

Performance gains from using sprites won't help. The issue is the memory usage required and the performance hit from buffering from fast to chip on a 68k machine. I already gave some rough estimates for this on the thread.
What I'd like to know is:

a) how much of the graphics is from tile data. CPU can handle that from fast as there's no need for shifting.

b) How much masked data there is per level which needs to be handled by the blitter

The STe has a *huge* addressing range on its blitter compared to the Amiga. 24 bit with 12 meg of that coming from addressable RAM. If all masked data fits in 2 mb it's doable on ECS with decent performance. If not.....better target the 1200 and accept it isn't feasible on a 500 without crippling the frame rate.

[frank_b]

That said you could probably get away with storing all the sprite data for the player in fast RAM. CPU could just copy into the chip ram buffer and adjust the positing via control words. That would save chip RAM and not be too expensive.

Another question then.
How much memory does the player sprite use up per level?

[mcgeezer]

It's an interesting challenge this one so I've had a quick look at the boss assets and using the dual play field method that I would take to doing it.

There's 976 16x16 tiles that make up the boss sprite which I would squeeze down into using 8 colours (1 transparent).

So 96 bytes per tile using up 93,696 bytes of chip ram, I'd probably double that for masking as many of the tiles overlap so 188Kb.

Then you're looking at the screen buffers and I'd probably triple buffer this one because the boss doesn't move every frame giving you enough time to build up the other buffers ready for display, so around 100K for that too.

The main player sprite is 48x48, so I would be opting for using 6 hardware sprites there, possibly using the remaining two sprites for the fireball the boss breathes out.

Another 60Kb on top for the foreground screen buffers, and maybe 40Kb for the tile data.

Remember , I'm just considering the end of level boss here but you are looking at least 1mb of chip ram... but 50fps?... definitely.

[sandruzzo]

Originally Posted by mcgeezer

It's an interesting challenge this one so I've had a quick look at the boss assets and using the dual play field method that I would take to doing it.

There's 976 16x16 tiles that make up the boss sprite which I would squeeze down into using 8 colours (1 transparent).

So 96 bytes per tile using up 93,696 bytes of chip ram, I'd probably double that for masking as many of the tiles overlap so 188Kb.

Then you're looking at the screen buffers and I'd probably triple buffer this one because the boss doesn't move every frame giving you enough time to build up the other buffers ready for display, so around 100K for that too.

The main player sprite is 48x48, so I would be opting for using 6 hardware sprites there, possibly using the remaining two sprites for the fireball the boss breathes out.

Another 60Kb on top for the foreground screen buffers, and maybe 40Kb for the tile data.

Remember , I'm just considering the end of level boss here but you are looking at least 1mb of chip ram... but 50fps?... definitely.

We can evena have the whole level with 16/32 colors, and switch to dual playfield when boss come

[mcgeezer]

Originally Posted by sandruzzo

We can evena have the whole level with 16/32 colors, and switch to dual playfield when boss come

Yes - that would be the idea.

[sandruzzo]

Originally Posted by mcgeezer

Yes - that would be the idea.

We have only to try!

[mcgeezer]

Originally Posted by sandruzzo

We have only to try!

Was the Amiga Ghouls and Ghosts really that bad it needs a re-write though?
I guess that would be my consideration.

While I like Ghouls and Ghosts, I love Rolling Thunder and I would be more likely to re-port that game instead.

[DamienD]

Originally Posted by mcgeezer

Was the Amiga Ghouls and Ghosts really that bad it needs a re-write though?
I guess that would be my consideration.

Yup horrible, see here: Ghouls 'N' Ghosts...

Ghosts 'N Goblins on the otherhand is beautiful and a very faithful port

[coder76]

If one wants to have something more high-end, then one should use an accelerator board with an A1200, and draw most object graphics with the CPU, because the blitter is way too slow. I did some tests with a 68030/50 MHz on an A1200, and its about 5 times faster at making cookie cut operations and bit shifting than the blitter (for making similar blitter objects), despite you need to copy the graphics into chip ram.

Since one can have up to 128 MB of fast ram on accelerator boards, there will be enough memory for graphics. Then you also have the AGA sprites. With this sort of performance, it starts to be feasible to also use SuperVGA-style graphics, maybe 640x512 and 32 colors, in AGA 4x fetchmode bitplane bandwidth requirements will be about same as in OCS 320x256 and 32 colors, so there's some slowdown for CPU access into chipram. But these VGA/DBLPAL modes also eat up sprites and horizontal scrolling, so a vertical shooter works best with these settings. But on AGA screenmodes are also fully programmable, so you could have some very nonstandard displaymodes and refresh rates to save sprites and scrolling.

[frank_b]

Originally Posted by coder76

If one wants to have something more high-end, then one should use an accelerator board with an A1200, and draw most object graphics with the CPU, because the blitter is way too slow.

Chuck hardware at it? Why not? There will be a Falcon version too. A500 owners will be out of luck though. It's possible on a stock 8 mhz STe however. It would be good to see a version on the Amiga 500/600/500+ too.

BTW the really exciting thing about this project is it isn't limited to one game.
Street Fighter II anyone?

[sandruzzo]

Originally Posted by frank_b

Chuck hardware at it? Why not? There will be a Falcon version too. A500 owners will be out of luck though. It's possible on a stock 8 mhz STe however. It would be good to see a version on the Amiga 500/600/500+ too.

BTW the really exciting thing about this project is it isn't limited to one game.
Street Fighter II anyone?

Street Fighter II with less big sprites, why not?

[idrougge]

I think that given the current mood in the Amiga community, a GnG port requiring 4 MB of RAM would not be well-received. There is a certain quality in a port running on vanilla hardware, even if it inferior.

For the STE, it's different because every machine can be expanded to 4 MB of RAM — but on the Amiga 500, requiring 4 MB is tantamount to requiring 12 MB on the ST, and you still don't get the advantages you have on the STE since chip RAM is still limited.

[frank_b]

A full 68k bus master blitter, with the same register interface as the Amiga would be a hell of a nice USP for new ACA 500 cards.
Would do wonders for fblit too.

[coder76]

Originally Posted by frank_b

Chuck hardware at it? Why not? There will be a Falcon version too. A500 owners will be out of luck though. It's possible on a stock 8 mhz STe however. It would be good to see a version on the Amiga 500/600/500+ too.

BTW the really exciting thing about this project is it isn't limited to one game.
Street Fighter II anyone?

Well it seemed to me that AnimaInCorpore doubted that it would be possible to make some more high-end bullet hell shooter on an A1200 like Cho Ren Sha. Yes, not possible on an unexpanded A1200, one needs to throw more hardware in, and learn how to use it. The A1200 does not have a DSP like Atari Falcon, and also not a chunky 16 bit screenmode, so you need throw in more CPU power, the planar modes are slower to handle than some 8/16 bit chunky pixels, although you can optimize performance by using less colors in planar modes.

[frank_b]

Cho ren sha has up to 4000 sprites on screen or something equally crazy. Forget about that on a non 060 1200. I'm talking about the arcade ports here. That's more feasible.

[LeCaravage]

Originally Posted by mcgeezer

It's an interesting challenge this one

I'd love to see a game demo from you

[coder76]

Originally Posted by frank_b

Cho ren sha has up to 4000 sprites on screen or something equally crazy. Forget about that on a non 060 1200. I'm talking about the arcade ports here. That's more feasible.

This can't be true, initially I would have estimated max number of sprites to be around 500. Then I found this documentation, which says that X68000 has 128 sprites, but the author found a way to multiplex them into 512. I'm not too familiar with the X68000 system, but seems still like its doable on an A1200, maybe you get less colors. But the game looks pretty boring to me.

http://shmuplations.com/chorensha68k/

[frank_b]

Ok I will do the math for 500 16*16 sprites at say 16 colours with the CPU.

You're reading 2 bytes per line per plane * 16 for the sprite: 2*4*16 = 128 bytes.
The mask takes 2 bytes per line * 16 = 32 bytes

You're reading an extra column on the destination to take account for shifting the source.
The destination being the screen. So that's 4*4*16 = 256 bytes

You also have to read and restore the screen buffer. Let's say you have a third buffer containing a copy of the
screen as a source.

So that's another 256*2 bytes (read and write).

A single 16*16 sprite costs the CPU 128 + 32 + 256 + 512 bytes.. that's 928 bytes worth of bandwidth.

Now lets multiply that by 500. That's 928 * 500 = 464,000 bytes per frame worth of reads/writes!!!!

This is excluding overhead and actual game logic. How on earth is that going to run acceptably on a 1200? Even with fast RAM and an accelerator!
I'd go down the chunky pixel route, use compiled sprites if I was doing it. I'd not be targeting a stock 1200!