How well can Metal Slug backgrounds be recreated with tiles?

[psycopathicteen]

I do know that Metal Slug and it's sequels DO in fact occasionally recycle BG tiles (yes, I know they're actually sprites ), but not nearly as much as SNES and MD/Genesis games. I want to know how much you can replicate using half or less as many unique tiles.

[Drew Sebastino]

For what reason? Backgrounds from Metal Slug probably reuse more tiles than you would think, as they are often placed far away and/or surrounded by other unique tiles. Less than halving the number of tiles will almost guarantee it to look like shit, imo.

[psycopathicteen]

I was just curious.

Metal Slug looks like it overlaps tiles too. I can't tell if the game actually overlaps tiles, or if the artists did.

[Drew Sebastino]

The backgrounds never overlap, as far as I can tell anyway from looking at the game's tiles in Kawaks. From an artistic standpoint, it seems like it would be much easier, as you could just about forget about palettes and the 16x16 attribute grid. It'd probably be more difficult to implement though as well as eating more graphics bandwidth.

[TOUKO]

I do know that Metal Slug and it's sequels DO in fact occasionally recycle BG tiles (yes, I know they're actually sprites ), but not nearly as much as SNES and MD/Genesis games. I want to know how much you can replicate using half or less as many unique tiles.

I think it's a difficult task without losing many details, unfortunately.

[Stef]

https://www.youtube.com/watch?v=p1HKwHr_zvc

That was made with BEX and i think it's streaming some tiles as the scrolling goes... still that shows that we can somehow replicate it (that would require a huge ROM though)

[psycopathicteen]

https://www.youtube.com/watch?v=p1HKwHr_zvc

That was made with BEX and i think it's streaming some tiles as the scrolling goes... still that shows that we can somehow replicate it (that would require a huge ROM though)

How much ROM does that little demo use up?

[Drew Sebastino]

That was made with BEX and i think it's streaming some tiles as the scrolling goes...

Undoubtedly.

(that would require a huge ROM though)

And that's what the MSU1 is for.

[93143]

It's also what the S-DD1 is for.

The Neo Geo game is 193 Mbits, or a little over 24 MB. Assuming the graphics are uncompressed and constitute the bulk of the data, that already seems like it should fit easily in the S-DD1's 16 MB of addressable ROM when compressed (remember, Star Ocean is literally twice as big without the compression), and there are a few extra MB of spare address space on the A bus that you can fill with ROM in parallel to the chip if you want.

Not to mention that the Neo Geo's screen resolution is higher (leading to SNES graphics being slightly smaller for the same on-screen real estate; the conversion might be time-consuming, but the gameplay would be preserved) and the program was in all likelihood not optimized for size. Also, aren't most of the Neo Geo's PCM channels fixed-rate with no looping? You'd probably save some space on the audio side too, even assuming your audio driver is agile enough to stream everything through ARAM at full quality... With luck and skill, the game might actually fit into 8 MB of physical ROM if you used an S-DD1.

[lidnariq]

The Neo Geo game is 193 Mbits, or a little over 24 MB. Assuming the graphics are uncompressed and constitute the bulk of the data, that already seems like it should fit easily in the S-DD1's 16 MB of addressable ROM when compressed

I picked up the dotEmu port of Metal Slug 3 a while back, and they actually include most of the original data. There's 64 MiB of 4bpp packed-pixels data (decodes nicely at a width of 16px), and 512 KiB of S fix layer data (4bpp, 8px wide, probably bankswitched—part of it repeats every 128KiB)

Also, aren't most of the Neo Geo's PCM channels fixed-rate?

The data files include a raw 16 MiB ADPCM file (seems to decode mostly ok as plain IMA ADPCM); at 18kHz (exactly 1MHz÷54) this will last 30 minutes. The first 135 seconds are literally just every note from a piano; then 15 seconds of a three octaves of a synth lead, then a minute of an octave of a distorted guitar ... yeah. there's not only lots of room for optimizing this, but it'd be necessary to fit in the SPC700's RAM.

[93143]

That game is supposedly 708 Mbit; I'm guessing this means 8 MB was dedicated to code.

I wonder what sort of compression ratio you'd get on that data with an S-DD1? Not that I seriously expect Metal Slug 3 to fit in an S-DD1 cart without altering the pinout of the chip or adding a helper chip. Theoretically I think it can address 256 MB, and I know for a fact that at least one 64 MB homebrew ROM exists, but physically it seems to be limited to 16 MB...

I was referring to the original Metal Slug, which is 193 Mbit. Metal Slug 2 (362 Mbit) might fit as well, but it looks much tighter...

[lidnariq]

That game is supposedly 708 Mbit; I'm guessing this means 8 MB was dedicated to code.

Not clear? In the bundle there's a 9 MiB file full of 68k code (but the last 2 MiB are all 0s) ... looking at the MAME manifest that actually seems to be fair.

Looking at a histogram of the contents, I'd say roughly 2MiB are code, and the other 5 MiB are various tables.

I wonder what sort of compression ratio you'd get on that data with an S-DD1?

I don't suppose anyone's ever written a tool to compress data for the S-DD1 to decompress?

I was referring to the original Metal Slug, which is 193 Mbit. Metal Slug 2 (362 Mbit) might fit as well, but it looks much tighter...

Yeah, sorry, I was just taking some random data I had easily on hand and was vaguely related.

[93143]

That game is supposedly 708 Mbit; I'm guessing this means 8 MB was dedicated to code.

Not clear? In the bundle there's a 9 MiB file full of 68k code (but the last 2 MiB are all 0s) ... looking at the MAME manifest that actually seems to be fair.

I just subtracted all the stuff you mentioned from 88.5 MB, figuring that once graphics and sound were accounted for, the rest had to be program ROM. I guess technically lookup tables are not code...

I don't suppose anyone's ever written a tool to compress data for the S-DD1 to decompress?

Well, there's this: http://www.romhacking.net/documents/257/

I'm not sure how well optimized it is...

Yeah, sorry, I was just taking some random data I had easily on hand and was vaguely related.

Still interesting. That sample pack sounds pretty egregious, more so than I expected... does the game even use all of the samples? Maybe there's some truth to the idea that Neo Geo developers deliberately wasted space so they could advertise bigger MEGA numbers...

[TOUKO]

https://www.youtube.com/watch?v=p1HKwHr_zvc

That was made with BEX and i think it's streaming some tiles as the scrolling goes... still that shows that we can somehow replicate it (that would require a huge ROM though)

this Is not what psychopathic asked .

I want to know how much you can replicate using half or less as many unique tiles.

The conversion you showed don't take care about limiting the amount of tiles.
The metal slug series rely heavily to graphical details and the huge amount of detailed animations.This is why a good conversion on a 16 bit system is not really possible without losing tons of details,and the charm of those games .

[psycopathicteen]

Am I the only one who thinks it's weird that there is no parallax in the first half the level 1, but there is later in the level?