I can say for sure there's probably not many of you that haven't heard of 'Metal Slug', a game in a series of games that are well known in the community, going back to the days of the Neo Geo system. This game has plenty of humor, while remaining action packed throughout. In fact it was so much fun and still is, that a fan by the name of masteries had developed a Metal Slug port for the Atari STE and a new port for the Sega Mega Drive; an in development action blaster that runs at a rather smooth 50 frames per second with very few slowdowns!
This is what the website says about both versions available below. The Atari STE version makes usage of custom sprite routines, extremely efficient but memory hungry ones, and a 3 voices digital audio mixer. The Megadrive/Genesis version however which is new, is a completely different nightmare. While the STE computer has 4 MB of RAM, the 16 bits console only has 64 KB of video RAM (around 52 KB available for scenario and sprites) that needs to allocate a 320x208 framebuffer.
In order to display almost the same high detailed scenarios as the NeoGeo version, and the incredible huge amount of sprites at same time... without collapse... This console version is one of the most challenging things I ever performed. The 16 bits console audio driver was written by SplinterGU, that provides 3 compressed digital audio voices and the digital audio needs to be compressed in order to maintain a ROM size less than 8 MB. While these are still in a beta state, a new Metal Slug adventure is planned with 6 levels that could be completed thanks to donations.
Note: original graphics and sounds are property of their respective owners.
Links :1) Website
This is absolutely amazing work !
ReplyDeleteWonderful work ! Both on Atari and Megadrive. I wonder what it would look like on Amiga with the Scorpion Engine.
ReplyDeleteVery cool, though this is a huge stretch for the word 'beta', which has traditionally meant 'feature complete but lacking testing/polishing'. And just for the record, the mega-drive doesn't allocate a framebuffer (at least, not in the traditional sense), it has character maps and sprites - even a 4-bit framebuffer at that stated resolution would be over 32K. I'm sure the author knows this though, having written this demo :) Perhaps something lost in translation/simplification?
ReplyDelete