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

[coder76]

Originally Posted by Master484

But the Neo Geo has 900 sprites, and everything that moves in the screen, including the backgrounds, are sprites. So in all likelyhood it's totally impossible to make an Amiga sprite engine that would be capable of directly replicating all Neo Geo sprites by just multiplexing the 8 Amiga sprites.

Look up Neo Geo specs somewhere:
https://wiki.neogeodev.org/index.php?title=Sprites

Neo Geo has a limit of 381 sprites per frame and 96 per scanline. Neo Geo sprites are all 16 pixels wide and maximally 512 pixels high and have each a 4-bit color palette. In terms of needed graphics bandwidth in visible screen, this is 96*2*4*224*50 = 8,6 MB/sec @50 Hz.

Amiga AGA sprites have a comparable bandwidth of 8*8*2*224*50 = 1,4 MB/sec. In addition to those onecan use blitter (max copy speed 3,3 MB/sec) and CPU (max 7 MB/sec) e.g. on a 68030/50 MHz, dataregister to chip ram. Blitter and CPU copy speeds are of course not comparable to sprite bandwidth, as they need to do more operations to get sprite-like objects (bandwidth is lowered by a factor of 3, for blitter objects, and similar for CPU objects).

[DamienD]

Guys, besides coder76's post above mine, we are getting way off topic discussing CPC / C64 etc...

Move along please.

[Master484]

Look up Neo Geo specs somewhere:
https://wiki.neogeodev.org/index.php?title=Sprites

Neo Geo has a limit of 381 sprites per frame and 96 per scanline. Neo Geo sprites are all 16 pixels wide and maximally 512 pixels high and have each a 4-bit color palette. In terms of needed graphics bandwidth in visible screen, this is 96*2*4*224*50 = 8,6 MB/sec @50 Hz.

Ok thanks for the info, until now I have believed that Neo Geo has 900 sprites...this info I originally read from Wikipedia I think, but now Wikipedia too says it has only 380. Oh well.

[Megol]

Have anyone ever tried to decompress graphics data with the blitter?

Doubt that it would be worth the effort but had to ask.

[Samurai_Crow]

The blitter and copper can render structured graphics as long as it's not realtime.

[saimon69]

Originally Posted by Master484

That's right, on AGA sprites maximum horizontal size was increased to 64 pixels. The older OCS / ECS sprites could only be 16 pixels wide. But both on AGA and OCS we still have only 8 sprite channels.

But the Neo Geo has 900 sprites, and everything that moves in the screen, including the backgrounds, are sprites. So in all likelyhood it's totally impossible to make an Amiga sprite engine that would be capable of directly replicating all Neo Geo sprites by just multiplexing the 8 Amiga sprites.

---

I made an updated memory plan for A500 8 + 8 Dual Playfield:

50 kb = two 288*224 8 color "game area" bitmaps (front playfield)
125 kb = five 288*224 8 color level "background" bitmaps (back playfield)
80 kb = music and sound (although the demo most likely has none)
30 kb = reserve
220 kb = graphics

Game code goes to Slow RAM.

With this plan, in a "real game" there would need a loading break only every 5 screens.

One tank frame is 2,6 kb in 8 colors. So we can have 84 "tank frames"...This is equal to five standard 320*256 Amiga screens full of graphics.

So 220 kb should be able to hold a good amount of frames for the following: Player, enemy soldier, two tank types, helicopter and some bullets and explosions.

So RAM wise a short 5 screen infinitely looping demo level would be 100% possible on the 512K A500, and speed wise I think it would be 17 FPS + player and scroll at 50 FPS.

Some animations can be achieved by splitting elements, like tank and turret and using tweening; you could even make separated wheel animations so to save more space

[idrougge]

Originally Posted by Galahad/FLT

Having seen modern efforts, I think the Amstrad CPC464 got REALLY and properly short changed during its lifetime, more so than the Amiga and its ST ports.

I think one obstacle was the 464, actually. The 6128 has a lot more RAM to dedicate to the quite heavy graphics and all the tricks needed to work around certain hardware limitations.

[LongLifeA1200]

The key to what makes Metal Slug "Metal Slug" is the action. I think that is partly what makes it so memorable.

While I can't think of any AGA game that ever matched Metal Slug's level of intensity (That's not to say there isn't one, I don't know every game.) at least a project like this generates interest from programmers to try.

If you design the levels so that the player is constantly engaged, and provide the illusion that multiple things are happening at once, it will feel like you are playing a Metal Slug game, in my opinion.

Though, I can't shake the feeling that since it's mainly programmers who are interested in this project as opposed to artists, there may be a few missed opportunities here.

[rare_j]

Thanks to this thread I went back and played Metal Slug properly. Not like last time, when I yawned my way through it spamming the insert credit button and dying every 2 seconds.
Playing it properly is hard at first but mind bendingly awesome. I got to the bit where you roll over a line of fiat 500s in the tank and was grinning like an idiot.
This just can't happen on ocs. You might as well say you're going to port it to the zx spectrum.

[Shatterhand]

Metal Slug is awesome, but from 3 upwards IMO the games got too hard in a stupid way, while the level design never matched the previous games. The best games on series are the first 3 imo (1, 2 and X).

I like 6 because they finally tried to do something different with it, with new characters and a few minor new stuffs, but it's nowhere as good as X

[Master484]

Here is a quick A500 Metal Slug graphics stress test demo that I put together by copy pasting code from my earlier demos.

ADF download is in the attachment of this post. Just boot the disk and it'll autoload. Disk also includes Blitz source code.

Instructions: press numbers 1-9 to make stuff appear, move the robot with joystick, and press space to delete objects.

---

This demo is for the 512K A500, and it's optimized for low RAM usage.

Because RAM in the "real game" would be so tight, I made the front playfield bitmap 288*224, without any "bob zones" around it. The "bob zones" are usually needed so that we can draw objects whose images are partially outside of the visible screen. But the BOB zones increase the size of the bitmap, and therefore I left them out.

Also, there are no "Queues" or bitmap repair buffers.

Instead, this system is used: Every frame I use a CLS to clean to whole front PF bitmap. This is relatively fast thanks to the small 8 color bitmap. And after this objects are drawn either with "Blit" or "ClipBlit" command, depending on their position on screen; usually Blit is used, but when object goes to the border zone, it switches to the somewhat slower ClipBlit.

But despite the full screen CLS and ClipBlits, speed is comparable to "QBlits" when we draw lots of GFX. Only at low object amounts QBlit is faster (the 50 FPS zone), but at medium object amounts (25 FPS zone) this method is equally fast, and at extreme object amounts I think this method is actually faster.

---

The demo also has an auto-scrolling level loop, some copper effects, and uses all 8 sprite channels to make that 16 color Turrican robot sprite.

I put the sprite in to demonstrate how sprites can always move at 50 FPS, no matter how much slowdown. Also the sprite shows how large objects can be made "for free" with sprites. It uses all 8 channels to make this one 64pix wide sprite. But on AGA this same sprite would cost only 2 channels. So on AGA we could have four 64pix wide sprites like this. ( Just imagine an AGA Street Fighter 2 conversion using big sprites like this )

But so, how does it run?

Well, the FPS for the bobs is locked to 25, and this is what it can draw without slowdown:

15 soldiers
8 normal tanks
1 super tank
7 explosions
25 shots
22 rockets

That means one of those things, not all at once, hehe.

But it's not totally hopeless, and maybe the real game could indeed run at 25 FPS "with slowdowns".

I watched a Neo Geo longplay that used "real hardware", and there were frequent slowdowns in it, triggered by common events like big explosions, lots of bullets, etc. So frequent slowdowns on A500 too would be acceptable.

---

You can run this demo on A1200 too, but the difference won't be that big: basic A1200 can draw some 21 soldiers, 10 tanks, and so on, so the speed increase is some 20 %.

And if we used the AGA 16+16 dual playfield, then I estimate speed to be about the same as 8+8 on OCS.

But on AGA, there are two things that can be done to boost speed, but it's a choice between two things: Firstly, we can use the four 64pix sprites to put some big stuff to screen at almost no cost. Or secondly, we can use the bigger AGA display fetch modes. The fastest fmode boosts drawing speed by some 30 %, but doing this reduces the available sprite channels to just 1. So it's a hard choice, but in most 2D games I would probably go for the sprites. The fmodes are probably most useful in 3D and in isometric games like Syndicate, Populous and stuff like that.

And of course both on A500 and A1200 we can add fast RAM, and this too gives some 30% boost. But if we are trying to prove that Metal Slug "could have been done", then Fast RAM is a no-no, because only a few A500/A1200 owners back then had Fast RAM. And the same goes for adding faster processors and GFX cards.

[ross]

Originally Posted by Master484

The fastest fmode boosts drawing speed by some 30 %, but doing this reduces the available sprite channels to just 1. So it's a hard choice, but in most 2D games I would probably go for the sprites.

Compromises are possible.
Your screen is 288 so 32*9 single CAS DMA. For scroll you need 2 further, so a slice of 352.
Setup FMODE=$D, DDFSTRT=$38 to DDFSTOP=$D0 (11 single CAS DMA fetch), a view from DIWSTRT=$xxA1 to DIWSTOP=$xxC1.
Drawback? Screen shifted 16 pixel to the right, we can live with it.
Profit? We have all 8 sprite available and plenty of more blitter DMA slots available

Another 2 cents.

[zero]

How are you going to scroll a 352 pixel wide bitmap? You need one that is at least twice as wide as the display area to low overhead scrolling.

[Samurai_Crow]

Originally Posted by zero

How are you going to scroll a 352 pixel wide bitmap? You need one that is at least twice as wide as the display area to low overhead scrolling.

...or use a tube scroller. That only needs a few tile widths extra on all but one row of pixels.

[Master484]

Compromises are possible.
Your screen is 288 so 32*9 single CAS DMA. For scroll you need 2 further, so a slice of 352.
Setup FMODE=$D, DDFSTRT=$38 to DDFSTOP=$D0 (11 single CAS DMA fetch), a view from DIWSTRT=$xxA1 to DIWSTOP=$xxC1.
Drawback? Screen shifted 16 pixel to the right, we can live with it.
Profit? We have all 8 sprite available and plenty of more blitter DMA slots available

Thanks, I'll try to test those values with the Blitz "DisplayAdjust" command, and see if I can get both the AGA fmodes and 8 sprites working at the same time.

How are you going to scroll a 352 pixel wide bitmap? You need one that is at least twice as wide as the display area to low overhead scrolling.

About the scrolling method, in the actual "real game" I would scroll a 5 screen long 8 color bitmap. This demo uses the same method, but the bitmap is only 2 screens long. And this is a 8+8 dual playfield, and only the back playfield bitmap is used for scrolling. The front playfield is a 288*224 single screen bitmap that never scrolls, and is only used to draw the objects.

And a 5 screen wide scrolling bitmap means loading brakes every five screens, on the 512K A500.

[Amiga1992]

The demo is great for static objects, but there needs to be animation in there.
The toll to RAM when you introduce more frames per object will quickly get impossible to maintain on an Amiga.

Also these graphics are thrown in as-is, perhaps reducing their size would improve performance. Yes, a daunting task, but no one said this should be easy.

Originally Posted by LongLifeA1200

The key to what makes Metal Slug "Metal Slug" is the action.
[...]
If you design the levels so that the player is constantly engaged, and provide the illusion that multiple things are happening at once, it will feel like you are playing a Metal Slug game, in my opinion.

This, 100%. This is one of the key elements one could extract from the game design of Metal Slug that would make a "clone" feel like Metal Slug.
This ultimately allows you to take a lot of compromises on graphics size, amount, animation frames, objects at once on screen, colors and more.

[LongLifeA1200]

Good show, Master484. Just seeing Metal Slug sprites move about on a stock A500 makes a person think "it could happen" .

Trachu, did you get the sound files, too?
And do you still have the sprite sheets in their original colours?

[turrican3]

just to say it , if i was a coder i would choose good games to convert but more realistic to port... I have 2 in mind :

1) penguin adventure from msx :
[ Show youtube player ]
that amiga 500 should easily handle it and even improve it.Everybody loves this little game, it's a gem.

2) vigilante arcade or pcengine :
[ Show youtube player ]
the amiga should be able to handle it. and the stages are just 5, shouldn't be so long for a good coder.
the amiga 500 version was a real crap, i should say a shame :
[ Show youtube player ]
by the way could it avoid the copyright problem if the new version ask you to insert the original amiga disk of vigilante to work ??

[OmegaMax]

Speaking of games like Vigilante,I started these for pc engine(Kung Fu Master)their 32x64 pixels each.It also has five stages,not many colors onscreen.

[dlfrsilver]

Originally Posted by turrican3

just to say it , if i was a coder i would choose good games to convert but more realistic to port... I have 2 in mind :

1) penguin adventure from msx :
[ Show youtube player ]
that amiga 500 should easily handle it and even improve it.Everybody loves this little game, it's a gem.

2) vigilante arcade or pcengine :
[ Show youtube player ]
the amiga should be able to handle it. and the stages are just 5, shouldn't be so long for a good coder.
the amiga 500 version was a real crap, i should say a shame :
[ Show youtube player ]
by the way could it avoid the copyright problem if the new version ask you to insert the original amiga disk of vigilante to work ??

Vigilante Arcade use a double 256 colors palette. This explains how poor in colors the graphics are.