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

[Tigerskunk]

I was thinking about some kind of colour multiplexer per scanline for some kind of games before.

Problem is, you would run into problems with ZX Spectrum like colour clashes pretty early if objects started to share scanlines.

If you have drastic palette changes every 8 pixels you'd have to be very clever in which colours you switch to, and you'd still run into colour clash if those BOBs collide somewhere.

[sandruzzo]

Originally Posted by Steril707

I was thinking about some kind of colour multiplexer per scanline for some kind of games before.

Problem is, you would run into problems with ZX Spectrum like colour clashes pretty early if objects started to share scanlines.

If you have drastic palette changes every 8 pixels you'd have to be very clever in which colours you switch to, and you'd still run into colour clash if those BOBs collide somewhere.

Bobs' will use it's own playfield. One for background one for enemies

[mcgeezer]

Originally Posted by sandruzzo

Picture this: Instead try to think how to port GBA or NeoGeo verisons on Amiga with in mind its' limitation, we have to think about how doing MS's Amiga version built around amiga Strenght

Copper will be used only for background. Another layers for enemies

So let me get this right... you want to update the background / tilemap palettes using the copper horizontally every 16 pixels? For what purpose, i’m struggling here with the point in relation to porting the game.

If you want to port it then concentrate on the sprite engine rather than the background colour palettes, which to be fair add little to the game if i am honest.

[Tigerskunk]

I thought a bit about how I would create this in my Inviyya engine, and this is what I came up with:



This uses 16 colours for the foreground (I guess the palette could be optimized a fair bit, though), and retains the parallax background, although with 4 colours compared to the 8 the GBA version uses.

Some further thoughts:
* the amount of BOBs and their size is rather modest in that version most of the times. Most are around 32x40, and usually around 5 to 6 BOBs on screen plus lots of shots (these are more of concern to me)
* I wish I had some colours left for the foliage to look different from the soldiers green. Might further optimize the palette. Let's see where we get there..

I'd say this is a realistic mockup of what the OCS Amiga could be capable of doing here.

[saimon69]

Originally Posted by Steril707

I was thinking about some kind of colour multiplexer per scanline for some kind of games before.

Problem is, you would run into problems with ZX Spectrum like colour clashes pretty early if objects started to share scanlines.

If you have drastic palette changes every 8 pixels you'd have to be very clever in which colours you switch to, and you'd still run into colour clash if those BOBs collide somewhere.

This is not too different from the dynamic color swap 8px horizontal grid i suggested for the Streets of Rage conversion,but there i was thinking to change only one color to differentiate enemies, though; was inspired by how nirvana engine works on ZX spectrum even though is a completely different hardware - and they told me was not feasible, or not?

[Tigerskunk]

Originally Posted by saimon69

This is not too different from the dynamic color swap 8px horizontal grid i suggested for the Streets of Rage conversion,but there i was thinking to change only one color to differentiate enemies, though; was inspired by how nirvana engine works on ZX spectrum even though is a completely different hardware - and they told me was not feasible, or not?

One colour is certainly doable. I tried something like that for Inviyya in the beginning, when I tried out a lot of whacky ideas.
You'd have "colour clash" though, when two of the fighters were standing next to each other in the same "8 pixel field". Imagine 3 fighters sharing this space, and you'd have a very ugly looking game suddenly...

[sandruzzo]

With dual playfield mode you can archive colors changing whiout having bobs' problem. Ok 8 colors' for enemies could be to few, but, but if you interlace two pics, we can "at least" get 16 colors.

Back in the days I tried somethig like that for my own Mortal Kombat2 versions. I've got a lot more colors than Amiga Version, and it flyed very well.

[sandruzzo]

Originally Posted by Steril707

I thought a bit how I would create this in my Inviyya engine, and this is what I came up with:



This uses 16 colours for the foreground (I guess the palette could be optimized a fair bit, though), and retains the parallax background, although with 4 colours compared to the 8 the GBA version uses.

Some further thoughts:
* the amount of BOBs and their size is rather modest in that version most of the times. Most are around 32x40, and usually around 5 to 6 BOBs on screen plus lots of shots (these are more of concern to me)
* I wish I had some colours left for the foliage to look different from the soldiers green. Might further optimize the palette. Let's see where we get there..

I'd say this is a realistic mockup of what the OCS Amiga could be capable of doing here.

If we use this, we'll get well and maybe got 50hz!

http://www.powerprograms.nl/amiga/dpl-fastbobs.html

Even bobs' overlap we don't have to restore background, so bobs' operations we'll be allways faster that regular 16-32 colors mode!

[Tigerskunk]

But you would only have 8 colours for BOBs and if interlacing it would look shit because of flickering.

[sandruzzo]

Originally Posted by Steril707

But you would only have 8 colours for BOBs and if interlacing it would look shit because of flickering.

No, if colors' aren't too far, i did it. Like I said, we have to think about Amiga strenght, not fault, and if we do that even with few colors we can have a good palette, and a lot of shit on screen at 50hz!

[roondar]

Originally Posted by mcgeezer

Prove it and i will personally send u a case of peroni.

Test case

Move 10 or so 32*32 16 colour controlable sprites around the screen each with a fully independent palette using the copper.

In my eyes you can only update the palette every 4 pixels per scan line, and thats even if you knew when to change them.

Roondar will probably know better, he has great insights into this kind of stuff.

Geezer

For the visible part of the scanline it goes like this:

Assuming 4 bitplanes or less (OCS) you get one Copper move every 8 pixels. Assuming 6 bitplanes (OCS, doesn't matter whether EHB/DPL or HAM) you get one Copper move every 16 pixels.

For AGA it depends on the fetch mode as well - 1x fetch is just like OCS, 2x or 4x means you get more Copper slots but can still lose a few if you use many bitplanes. And you're still limited to one move per 8 pixels even on AGA.

For the non-visible part it's always one move every 8 pixels (on OCS - I'm not sure how AGA does this part as I seem to recall reading about a 'fast Copper' mode for AGA but never found any documentation showing how that would work). In total, 4 bitplanes of less should give you 57* copper moves per scanline, of which about 15 fall in the horizontal blank.

*) No waits allowed and it depends a bit on how you look at it - the WinUAE debugger seems to show the 57th move halfway on one scanline and halfway on the next, so I guess you could argue for 56 1/2. However 57 moves does seem to work.

---
As for changing many colours horizontally using the Copper, that'd be kind-of possible under AGA (but very finicky) by running less than 8 bitplanes and then using the BPLCON4 XOR palette option**. Doesn't work as desired for HAM8 though and I've not looked at Dual Playfield so it may or may not allow you to switch in all 256 colours in that mode.

However, I'd say that overall horizontal Copper use like this is very complicated - it's technically possible to change colour registers just-in-time (and easier using AGA), but the copper list would quickly become a nightmare for anything with free moving objects like say a game. Let's just say I'd not recommend that route unless you've got total control over what object moves where and don't mind recreating the copper list every frame. Note here that this goes for the idea of independent palettes. Less complicated versions of this idea have more merit, but can still get tricky.

**) note that while this will allow you to 'bank' in other parts of the palette at any location the copper can wait for, it does force a 1/2 lowres pixel delay between the copper move and the updated palette showing.

---
On a side note here: I'd suggest looking at a mostly-fixed colour palette first. A properly optimised 16 colour palette can look pretty good (just look at the Bitmap Brother games) and may save a lot of effort.

[DanScott]

I'm going to chime in here too, and suggest that an Amiga game in the style of (or mimicking, or copying or whatever you want to call it) Metal Slug, would play sufficiently well at 25fps

I would personally go for that, with a 32 colour fixed palette, and a good conversion artist could make it look wonderful

[sandruzzo]

I'll try one more time. Idea is to change palette every x-pixel vertically, to have tons of colors for background, and use the other playfield for enemy. With 256*192 you can even have a lot of unique gfx and build levels around it!

[roondar]

Originally Posted by sandruzzo

I'll try one more time. Idea is to change palette every x-pixel vertically, to have tons of colors for background, and use the other playfield for enemy. With 256*192 you can even have a lot of unique gfx and build levels around it!

Using the copper to create a ton of background colours by reloading colours between scanlines will, obviously, work a treat .

If this is what you meant all along, I think the misunderstanding here started because I (as did others) read your idea as meaning you wanted to change the entire palette every 8 or so horizontal pixels. However, it seems we misunderstood and what you actually meant was changing colours every 8 (or any number really) vertical lines. Which is definitely doable.

That would indeed allow for colourful backgrounds

[Samurai_Crow]

Another advantage of dual playfield mode is that sprites get their own palette entries.

[saimon69]

Originally Posted by roondar

Using the copper to create a ton of background colours by reloading colours between scanlines will, obviously, work a treat .

If this is what you meant all along, I think the misunderstanding here started because I (as did others) read your idea as meaning you wanted to change the entire palette every 8 or so horizontal pixels. However, it seems we misunderstood and what you actually meant was changing colours every 8 (or any number really) vertical lines. Which is definitely doable.

That would indeed allow for colourful backgrounds

Well, the number 8 was kinda my suggestion, since i was told the OCS/ECS copper does horizontal increments by 8 pixels so it might be the fastest way

[sandruzzo]

Originally Posted by roondar

Using the copper to create a ton of background colours by reloading colours between scanlines will, obviously, work a treat .

If this is what you meant all along, I think the misunderstanding here started because I (as did others) read your idea as meaning you wanted to change the entire palette every 8 or so horizontal pixels. However, it seems we misunderstood and what you actually meant was changing colours every 8 (or any number really) vertical lines. Which is definitely doable.

That would indeed allow for colourful backgrounds

Gotcha! Like I said not a difficult task for Amiga having tons of colors on screen

[Tigerskunk]

Originally Posted by sandruzzo

Gotcha! Like I said not a difficult task for Amiga having tons of colors on screen

No one ever doubted that.

Managing those colours for a dynamic game is the problem.
Also, creating assets for something like that.

After some research on the GBA version I think you could recreate the first level of MS rather easy 8even with the parallax, but later on it will get much more difficult.

I did some more palette tweaking, and i think it looks rather good now.



Later on in the game, though, you have a lot more colours on screen, and I think it would be rather difficult to have the Amiga version not looking rather dull in comparison, if you go that way. You need at least 32 colours for this to look any good..

[aros-sg]

Originally Posted by DanScott

I'm going to chime in here too, and suggest that an Amiga game in the style of (or mimicking, or copying or whatever you want to call it) Metal Slug, would play sufficiently well at 25fps

Original Metal Slug on Neo Geo Hardware does not run at full frame (60fps) rate either. It runs at 30fps and sometimes less. You can see how it would look if it ran smooth (which it doesn't) by watching some 60fps video of Metal Slug on Youtube and tell Youtube to play it back at 2x speed. You will see how smooth that is compared to the 1x speed.

[Tigerskunk]

If I were to go for a MS GBA conversion, I'd try with 5 bitplanes and 25 fps, no parallax.

Seems the most doable version...

* assets conversion seems the easiest. With 4BPL/16 colours you'd need to work on the assets a lot to look any good in the later levels.
* Colour scheme would be a lot like the original.
* you'd have enough blit time for the big objects. The original is only 240 pixels wide and 160 high. Gives you also plenty of leftover DMA time as well. Maybe it would even work in 50 fps.
* With no parallax, you could multiplex the sprites and use that for displaying lots of shots as well.