NeoGeo Metal Slug conversion to Amiga 500 - madman task ;-)

[str0m]

Just work on porting Metal Slug 2, that had terrible slowdown/low fps on OG hardware, no idea how it even got released in that state

[DanScott]

Originally Posted by Tigerskunk

That's an interesting one.

On triple buffers, you get a nice performance boost with them. And they are actually not difficult to implement.
The downside is, that you have a mask plane in for every normal plane. Means you actually double your BOB size requirements in RAM instead of adding one additional plane of mask data.

As with all things on the Amiga, it's a give and take.

You could possibly create your 4 plane mask on the fly from a 1 plane version, in 2 seperate D = A blits (EDIT. 3 blits, so a trade off of speed vs. memory)

Interleaved masks are also good for (say your last colour in the palette is white or very bright), you can just OR it to the screen to make a bob "flash" (when taking a hit etc..)

[DanScott]

Blitter Interrupts is certainly much easier and less complicated than Copper Blitting. There's the overhead of the interrupts, but then the blitter is running in parallel with the CPU and you're not wasting any other CPU cycles waiting for the blitter

[sandruzzo]

Originally Posted by jotd

damn I knew most of those tricks, except triple buffer (looks complex).

I also never tried interleaved, because most of the time I'm already cheating with bitplanes (if I know the layer has less than nb_colors/2, I manage to put all colors in low positions so I only have to blit a part of the bitplanes, not all).

But with games like Metal Slug, you can't use this, you have to full blit, so it would apply.

I heard of at least another trick: copper-driven blits, where the blits are controlled by copper (in COPDANG mode). But it means that you have fixed blits, you can't check when blit is over you have to know when it's over!! Never tried it, but doing that avoids to wait for blitter in CPU. Just put the blit values in copper list and enjoy... in theory

Another trick I saw in Shaun Southern code is to pre-compute all blits in a list, then fire a blitter-interrupt chain. Each part of the chain sets the new blit. Also pretty constraining, but less constraining. Same benefit: CPU never waits for blitter except after the final blit. Given the speed of the games the guy can code, I'd say it's good. But not very flexible.

blitter by copper is useful if you have interleaved, otherwise you'' have a lot of overhead. On a regular OCS/ECS, I won't use blitter interrupts because it is very slow to get into and out of it!

Since this game is also very taxking on CPU I would spent a lot of time to use as less instruction as possible since you have to access to a very busy Chip Mem

[sandruzzo]

@DanScott

Very well programmed BLITTER via Copper, is the way to go. With some precalculated Copperlist, you can speed up things a lot- What you need to do it is only changing copperjump address!

[sandruzzo]

We can also use less wider actual screen are like 288x240 or 256x240 or like that. You will gain a lot of DMA cicles...

[sandruzzo]

Triple buffer requires 1MB of Chipmem...

[x-vision]

I can't believe there is already a great for port of Metal Slug for a simple Atari STE, and people here saying it needs AGA and 030

[ Show youtube player ]

[sandruzzo]

Originally Posted by x-vision

I can't believe there is already a great for port of Metal Slug for a simple Atari STE, and people here saying it needs AGA and 030

[ Show youtube player ]

Wonderfull. Maybe a little bit of Fast will help a lot!

[Old_Bob]

Originally Posted by jotd

I heard of at least another trick: copper-driven blits, where the blits are controlled by copper (in COPDANG mode). But it means that you have fixed blits, you can't check when blit is over you have to know when it's over!! Never tried it, but doing that avoids to wait for blitter in CPU. Just put the blit values in copper list and enjoy... in theory.

This can work pretty well. I've used this technique in a couple of test programs and the overhead for writing the copper list is tiny. If i was to write Tapper all over again, I'd probably do that way

If I was doing the engine for AGA Metal Slug, i think I'd do (almost) everything in a chunky pixel buffer in Fast RAM. It would also be possible to execute a copper list with further blitting in to the frame buffer bitplanes once the C2P step was complete for another useful contribution while the CPU is working in Fast RAM on the next frame.

A fast CPU would be needed, of course. The faster the better, I guess. Possibly a 50mhz 68030 might just be able to hack it?

Maybe another little test program is needed...

B

[dreadnought]

Originally Posted by x-vision

I can't believe there is already a great for port of Metal Slug for a simple Atari STE, and people here saying it needs AGA and 030

[ Show youtube player ]

It's a great achievement by @masteries, but it's not really a port...kinda remix more like.

[jotd]

Originally Posted by x-vision

I can't believe there is already a great for port of Metal Slug for a simple Atari STE, and people here saying it needs AGA and 030

[ Show youtube player ]

It's so easy that at least 5 people already ported that version to amiga.

[sandruzzo]

Do we need Metal slug on Amiga?

[jotd]

Do we need Amiga?

[TCD]

Originally Posted by jotd

It's so easy that at least 5 people already ported that version to amiga.

I think your dry humor is a bit lost here, but I surely appreciate it

[sandruzzo]

Originally Posted by jotd

Do we need Amiga?

Good Point! Mind you...

[Samurai_Crow]

Originally Posted by jotd

Do we need Amiga?

If I hadn't held my tongue I'd have beaten you to it.

:-D

[roondar]

Originally Posted by dreadnought

It's a great achievement by @masteries, but it's not really a port...kinda remix more like.

Not to mention it actually uses an actual advantage the ST(e) has over the Amiga (yeah, I know - the shock for some people, right ): the ability to access much more GFX RAM with the ST Blitter.

The requirements have gone down somewhat, but I believe you still need 4MB of ST-RAM for the latest version of this port, which would translate into needing 4MB of Chip RAM.

It's a great example of using a system well for sure. The 'interlacing' the whole game to get more colours trick is done very well too.

[sandruzzo]

With 1mb of chipmem and some fastram, maybe we can help the blitter with cpu aid! I think with Amiga it is possible to move a lots of bobs efficently and fast. There is no reason why it can't be done, expect the code itself that require a lot of time and more than one coder

[saimon69]

Originally Posted by sandruzzo

With 5 planes you can use some "special" interleaved bitmap:

- one of 3 planes
- one of 2 planes

So you can speed up blitting for little bobs: explosions, regular enemies, bullets, and so forth. So you can still have regulat 32 colors on screen.

Thats' 4

More or less that is what was happening in Powder