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

[str0m]

Originally Posted by sokolovic

The NGPC version could be a good start.

Great game, sequel even better due to the button remap.

[d4rk3lf]

Originally Posted by sandruzzo

We should forget the "perfect port" at all, and point to some sort of "Amigas' Metal slug"

Yes.. but this is what I was saying.
Everybody have a different idea on how much compromise you could make.
Someone would look at it and not be happy until the port is 95% like original, and someone could be happy with 2 pixels running around.

[Cris1997XX]

Originally Posted by d4rk3lf

Yes.. but this is what I was saying.
Everybody have a different idea on how much compromise you could make.
Someone would look at it and not be happy until the port is 95% like original, and someone could be happy with 2 pixels running around.

Two literal pixels wouldn't be enough at all...let's make it four

[d4rk3lf]

Originally Posted by Cris1997XX

Two literal pixels wouldn't be enough at all...let's make it four

3 pixels (one player, second enemy, and third boss), and this is the farthest I will go.
Otherwise, there will be massive slowdowns on the Amiga.

[sandruzzo]

@d4rk3lf

Ok. I didn't understand you! I think Amiga can move much more than we think with a very good playable gameplay..

[saimon69]

Originally Posted by sandruzzo

@d4rk3lf

Ok. I didn't understand you! I think Amiga can move much more than we think with a very good playable gameplay..

As long as you can handle the idea of have 25/30FPS it can move TONS of stuff*

[ Show youtube player ]
(if does not work go at 24:55)

[ Show youtube player ]
(if does not work go at 9:00)

*some restrictions apply

[Retro-Nerd]

Metal Slug was never full 60fps anyway, but that's another story. Port the GBA Version to AGA, that should be possible.

[Dunny]

Originally Posted by sandruzzo

We should forget the "perfect port" at all, and point to some sort of "Amigas' Metal slug"

So all we need now is for someone to actually write it?

[Rob68K]

Originally Posted by Retro-Nerd

Metal Slug was never full 60pfs anyway, but that's another story. Port the GBA Version to AGA, that should be possible.

There's nothing quite like a compromise before you even start to install a demon that will during development, constantly whisper in your ear "You weren't good enough to do the real thing, were you, you massive lamer"

Originally Posted by Dunny

So all we need now is for someone to actually write it?

It's a hiding to nothing.
Probably far better to attempt something that most would consider a slight stretch and then completely kill it.

[paraj]

Has anybody looked at some hard numbers yet? Even just basics like how many different "characters"/sprites are used in a level? How many animation frames for each of those? What are the sizes of the background layers etc. Just say for level 1.

[Old_Bob]

Originally Posted by paraj

Has anybody looked at some hard numbers yet? Even just basics like how many different "characters"/sprites are used in a level? How many animation frames for each of those? What are the sizes of the background layers etc. Just say for level 1.

Absolutely hundreds!! Have a look at the sprite sheet for the player sprite alone...

https://www.spriters-resource.com/fullview/11225/

Looking at the file in my MAME ROMs folder, it has an unpacked size of 44,302,336 bytes. I reckon you'd be pretty comfy with 16mb Fast RAM. 8mb, possibly, with a bit of trimming for an AGA port. Which, IIRC, is the amount of RAM the Neo Geo CD has (?) which, I think, is also the version the sprite sheet above was grabbed from. So, the cart version possibly has even more frames!?

The background images are pretty huge, as well.

B

[sandruzzo]

Originally Posted by Dunny

So all we need now is for someone to actually write it?

Doing a perfect playable level isn't a big problem. The real nightmare is to do the full game!

[sandruzzo]

Originally Posted by saimon69

As long as you can handle the idea of have 25/30FPS it can move TONS of stuff*

[ Show youtube player ]
(if does not work go at 24:55)

[ Show youtube player ]
(if does not work go at 9:00)

*some restrictions apply

There are a lot of tricks that you can do with blitter to push a lot of objects on screen even at decente frame rates

[jotd]

I'd love to learn about those tricks

[sandruzzo]

Originally Posted by jotd

I'd love to learn about those tricks

Some of them depends on screens' layout. With dual Playfield, if you use one of them for actual bobs' you can avoid screens' restore at all, and just clear it!

This is one.

[sandruzzo]

If you're using regualr 4-5 planes. With bob that don't overlaps, you can skip restoring at all! But You need triple buffer! This trick can be used for Metal slugs' big bosses and so forth

this two

[sandruzzo]

For non moving bobs, you can place them on aligned position so you don't have to blit that damn more word...

this three

[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

[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.

[Tigerskunk]

Originally Posted by jotd

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.

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.