How well can Metal Slug backgrounds be recreated with tiles?

How well can Metal Slug backgrounds be recreated with tiles?
by psycopathicteen on 2018-05-19 (#218756)

I do know that Metal Slug and it's sequels DO in fact occasionally recycle BG tiles (yes, I know they're actually sprites :roll:

), 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.

Re: How well can Metal Slug backgrounds be recreated with ti
by Drew Sebastino on 2018-05-19 (#218764)

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.

Re: How well can Metal Slug backgrounds be recreated with ti
by psycopathicteen on 2018-05-19 (#218766)

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.

Re: How well can Metal Slug backgrounds be recreated with ti
by Drew Sebastino on 2018-05-19 (#218767)

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.

Re: How well can Metal Slug backgrounds be recreated with ti
by TOUKO on 2018-05-21 (#218823)

psycopathicteen wrote:

I do know that Metal Slug and it's sequels DO in fact occasionally recycle BG tiles (yes, I know they're actually sprites :roll:

), 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.

Re: How well can Metal Slug backgrounds be recreated with ti
by Stef on 2018-05-22 (#218881)

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)

Re: How well can Metal Slug backgrounds be recreated with ti
by psycopathicteen on 2018-05-23 (#218910)

Stef wrote:

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?

Re: How well can Metal Slug backgrounds be recreated with ti
by Drew Sebastino on 2018-05-23 (#218917)

Stef wrote:

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

Undoubtedly.

Stef wrote:

(that would require a huge ROM though)

And that's what the MSU1 is for. :wink:

Re: How well can Metal Slug backgrounds be recreated with ti
by 93143 on 2018-05-23 (#218918)

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.

Re: How well can Metal Slug backgrounds be recreated with ti
by lidnariq on 2018-05-23 (#218920)

93143 wrote:

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)

Quote:

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.

Re: How well can Metal Slug backgrounds be recreated with ti
by 93143 on 2018-05-23 (#218921)

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

Re: How well can Metal Slug backgrounds be recreated with ti
by lidnariq on 2018-05-24 (#218923)

93143 wrote:

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.

Quote:

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?

Quote:

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.

Re: How well can Metal Slug backgrounds be recreated with ti
by 93143 on 2018-05-24 (#218935)

lidnariq wrote:

93143 wrote:

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

Quote:

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

Quote:

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

Re: How well can Metal Slug backgrounds be recreated with ti
by TOUKO on 2018-05-24 (#218944)

Stef wrote:

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 .

Quote:

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 .

Re: How well can Metal Slug backgrounds be recreated with ti
by psycopathicteen on 2018-05-24 (#218947)

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?

Re: How well can Metal Slug backgrounds be recreated with ti
by TOUKO on 2018-05-24 (#218949)

i agree it's really strange .

Re: How well can Metal Slug backgrounds be recreated with ti
by psycopathicteen on 2018-05-24 (#218955)

93143 wrote:

Quote:

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

The Neo Geo's YM2610 sound chip was designed to waste space.

Re: How well can Metal Slug backgrounds be recreated with ti
by TmEE on 2018-05-24 (#218959)

You could maybe say that only if it used uncompressed samples. You could also say similar stuff about how NES uses graphics ROMs disallowing compression with most mappers (and on NG there's no mapper with graphics RAM that I know of, only ROMs).

Re: How well can Metal Slug backgrounds be recreated with ti
by 93143 on 2018-05-24 (#218962)

TOUKO wrote:

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 .

I'm not convinced of this. Particularly since most of the game runs at 30 fps, with (IIRC) only a few BG tile animations running at 60... The obvious factor preventing a faithful Metal Slug port on 16-bit systems was ROM size - even with an S-DD1 you'd be hard-pressed to jam even the first game into a Super Mario 64-sized cart, and I can certainly imagine a would-be porting studio taking one look at the number on the original game's cartridge sleeve and noping out - but that's not a fundamental issue with either the SNES or the Mega Drive.

(I can't help but think about the N64, and how it got essentially no 2D pixel art games despite being capable of blitting opaque unscaled sprites at 250 megapixels per second...)

...

@psycopathicteen: What was the reason for your question? Have you analyzed the game for VRAM and/or DMA usage and determined that it won't fit? Or is it a ROM space issue?

Re: How well can Metal Slug backgrounds be recreated with ti
by psycopathicteen on 2018-05-24 (#218967)

I'm curious how Metal Slug would look like squeezed down to 32 or 48 megabits.

TmEE wrote:

You could maybe say that only if it used uncompressed samples. You could also say similar stuff about how NES uses graphics ROMs disallowing compression with most mappers (and on NG there's no mapper with graphics RAM that I know of, only ROMs).

Most sample based sound chips are capable of pitch scaling, without recording every single note.

Re: How well can Metal Slug backgrounds be recreated with ti
by tepples on 2018-05-24 (#218969)

I've tended to refer to one sample per pitch as the "Mellotron" pattern. There are valid reasons to use it even without hardware limits like that of the NES or Neo Geo sample unit. One is that an instrument may have greatly differing tonalities in the high or low pitches.

Re: How well can Metal Slug backgrounds be recreated with ti
by TmEE on 2018-05-24 (#218970)

YM2610 is a version of YM2608 with the internal sample ROM replaced with external one. Internal sounds of 2608 do not have any freq scaling capability. You're supposed to play SFX and whatnot on those channels and that's what most games do. There aren't a whole lot of games that use all the channels for music.

Stuff like piano scales really badly, you need at least one sample for every octave to get any decent results and most pro gear actually does use one sample every few notes or even for every note as fas as pianos go.

Re: How well can Metal Slug backgrounds be recreated with ti
by 93143 on 2018-05-24 (#218976)

tepples wrote:

I've tended to refer to one sample per pitch as the "Mellotron" pattern. There are valid reasons to use it even without hardware limits like that of the NES or Neo Geo sample unit. One is that an instrument may have greatly differing tonalities in the high or low pitches.

As long as you've got as much memory as you want, yes. Multisampling is an extremely common technique, but even fairly modern sound sets don't always sample every single note.

You can absolutely go nuts with multisampling if you want realism at any cost. Modern grand piano sample sets can be several gigabytes, for instance, because they have samples for every note at multiple key velocities, sometimes both with and without the sustain pedal, as well as stuff like release samples. Maybe even multiple samples per note per velocity, so as to randomize or round-robin the samples and avoid the dreaded "machine-gun effect" of absolutely identical samples playing in tight sequence. I casually searched just now and found a 67 GB grand piano set with 66,000 samples.

But if you care about storage requirements at all, the Mellotron pattern is the first thing to go - stretching a piano sample across five octaves sounds terrible, but stretching it a few semitones can be undetectable in a mix. And I suspect that a fair number of the instruments in Metal Slug were sampled from a synth module that used moderate stretching (and looping); it's very likely that the game uses a good bit more memory than the original synth did for these instruments.

The only thing I can think of at the moment for which I'd insist on the Mellotron pattern if possible is distorted rhythm guitar - there are types of lead guitar that can survive extensive repitching, but for your typical low/mid-range powerchords the fixed frequency profile is as important to the sound as the pitch-dependent component, so a stretch of even one semitone sounds clearly fake. On the other hand, repitched rhythm guitar samples are almost a separate instrument at this point, considering how common they were in '90s videogame soundtracks...

Re: How well can Metal Slug backgrounds be recreated with ti
by psycopathicteen on 2018-05-24 (#218980)

Oh yeah, I find the machine gun effect annoying with guitar samples. How do some SNES games avoid that?

Re: How well can Metal Slug backgrounds be recreated with ti
by Drew Sebastino on 2018-05-25 (#218989)

I had never heard of multiple sound samples being used for different notes of one instrument. You said that the grand piano was most affected; do you have a good comparison between a synth that is using one sample and changing the pitch vs one that isn't?

Re: How well can Metal Slug backgrounds be recreated with ti
by rainwarrior on 2018-05-25 (#218996)

Espozo wrote:

I had never heard of multiple sound samples being used for different notes of one instrument.

It's usually called "multisample", but it might have other names. It's actually the reason why XM and IT formats have a separate collection of "samples" and "instruments", i.e. the instruments reference many samples. Interestingly, even Famitracker has this feature, where the instrument maps DPCM samples to keys.

There's another dimension of this called "multitimbral" where you play multiple samples per note, e.g. you could blend between a "soft" and "hard" version of an instrument depending on how fast you press the key, which could have more expressive variation of the sound than just changing the volume, like you would without this feature.

Espozo wrote:

do you have a good comparison between a synth that is using one sample and changing the pitch vs one that isn't?

Piano samples are mentioned often because the disparity between a real piano and a sample pitch up or down gets very strong rather quickly, and pianos have a very large range for an instrument so there is something real to compare against, too. Pianos also have a separate set of strings and hammer for each note, designed and adjusted to give a good tone across the whole range (e.g. thicker/fewer strings on the bass, softer hammers on the treble), so it's a bit removed from the ideal thing that a samplerate change could replicate where each successive pitch should be identical components just scaled smaller.

All samples when pitched lower than their recorded frequency will start to have audibly missing high frequency components (i.e. sound too "dull") and at the same time have their envelopes lengthened (sound too "long" or "slow"). Conversely, when pitched higher, there is proportionately too strong a high frequency component compared to a natural instrument's pitch change, aliasing problems tend to build up in the high frequencies, and the envelopes become shortened too.

For a piano sample taken too far you get a very tinny short tink for high notes, and a very dull booooong for low notes. Everything is out of proportion. In reality the low pitches on a piano do have a longer envelope, but not THAT long, and high pitches do have a shorter one (but not THAT short), so you'll actually see this accounted for in synthesized approaches. Yamaha's FM synthesizers have "keyboard rate scaling" to adjust the speed of envelopes across the range of the keyboard, and "keyboard level scaling" to similarly adjust the timbral effect across the range (dampening high frequencies for high notes to keep them from sounding unnaturally harsh).

I can't point to a good example of how it sounds bad, because usually composers just avoid playing that piano outside its range, because it tends to sound bad. Maybe just find a random MOD with piano samples, open it up in OpenMPT or some other tracker and try for yourself how the individual samples sound when play them in different ranges. (This particular MOD has one "bass" piano sample, and one mid-range sample, and avoids going very high. You can easily hear the harsh tone of its higher notes though, and in general how various notes sound too bright or too dull.)

I always thought the game over screen from Super R-Type had a really fun use of a piano sample. It is used over a wide range, but outside a small range it sounds very unlike a piano. At some point it does interesting pitch sweeps in the low range that might as well be a sine wave. It also seems to avoid going very high in pitch, maybe to avoid it standing out too harshly compared to its fairly dull sound in the range it's mostly used.

psycopathicteen wrote:

The Neo Geo's YM2610 sound chip was designed to waste space.

It's designed to play sound effects and drums. Wasting space to use those sound effects for music was someone else's goal. ;P They might have considered it putting that space to good use rather than wastage. The only wasted space is empty.

Re: How well can Metal Slug backgrounds be recreated with ti
by lidnariq on 2018-05-25 (#219003)

rainwarrior wrote:

The only wasted space is empty.

Right. Cart costs for the Neo Geo were almost a non-issue. A game had every reason to use all 32 MiB addressable by the YM2610, and basically no reason to not.

... ok, that's not quite true, because SNK did actually make a special mapper IC that allowed all 7 voices to address the same ROM instead of having two disjoint memories. I'm having difficulty finding historical prices to support my argument, though.

Re: How well can Metal Slug backgrounds be recreated with ti
by 93143 on 2018-05-25 (#219004)

psycopathicteen wrote:

Oh yeah, I find the machine gun effect annoying with guitar samples. How do some SNES games avoid that?

Hard to say without examples.

It's possible to modify the volume and/or note length per-note to produce a musical pattern and break up the sameness. Adding a bit of looseness to the timing can help too, but it can easily backfire if you're not careful/musical about it. If you've got a separate attack sample (like the lead guitars in Rock 'n' Roll Racing seem to), or even a sufficiently long and distinct attack section of the main sample, you can do quite a bit to introduce variation (pitch, volume, volume profile, length) because the attack is a large part of the perceived timbre. Proper phrasing - following a volume profile over multiple notes - can help with some instruments.

Also, in my experience, some samples just don't sound as bad as others when repeated. For example, samples with long, pronounced attacks can sound really bad when repeated, because the attack is a significant portion - sometimes all - of the note.

Speed matters. Timpani rolls in real life are nowhere near as fast as some people seem to think they are...

Which reminds me - the machine-gun effect with percussive samples can be much worse when you use only a single channel, because the sample has to be abruptly cut off right before retriggering. Some SNES music devotes multiple channels to one percussive instrument, so the decay tail can continue into the next note, which tends to sound far more natural.

With something like a wind instrument, that can only produce one sound at a time, you can emulate legato playing by just changing the pitch with the sample running, rather than having to restart and getting a gap and another attack. Guitar hammer-ons can be dealt with this way too. Unfortunately, some instruments like violins that would otherwise be ideal candidates for this technique sound fake if you use the same sample over a significant pitch range - but then, violins tend to sound fake regardless unless you use large samples or sophisticated synthesis techniques...

Re: How well can Metal Slug backgrounds be recreated with ti
by TOUKO on 2018-05-26 (#219015)

Look at the PSX version :
https://www.youtube.com/watch?v=qHl5JkMDWv8

And the NG version:
https://www.youtube.com/watch?v=Yp8IK-uKNxs

And make your hown conclusions .

Re: How well can Metal Slug backgrounds be recreated with ti
by 93143 on 2018-05-26 (#219032)

The main difference I see (other than the loading pauses) is in the smoothness of the animation. I'm not sure what's driving it, but remember that the PSX didn't have full access to much more than a couple megabytes of data at a time without going through the painfully slow CD-ROM interface. My understanding is that the Saturn version was much better, partly because it employed a RAM expansion.

By contrast, a SNES with an S-DD1 can access anything in the cartridge at the speed of DMA with basically no latency, so the only limits would be DMA bandwidth and VRAM space (assuming sufficient CPU power). The SNES has enough VRAM to cover the whole screen in unique 4bpp tiles twice, with enough space left over for two double-wide tilemaps, and enough DMA bandwidth to replace all of VRAM in six frames at 30 fps. This may not be enough (I haven't tried), but the PSX version is limited by different factors and therefore doesn't really prove much.

It may be necessary to do tricks with the sprite palettes, but again, that's not something you could infer from the PlayStation version.

Re: How well can Metal Slug backgrounds be recreated with ti
by TOUKO on 2018-05-27 (#219050)

Quote:

By contrast, a SNES with an S-DD1

Yes with this configuration you can have a very large cartridge ,with a strong hardware decompression,but there is another problem, it's the DMA budget as you noticed ,the psx is way more powerful than any 16 bit home systems,and lack many animations and other stuffs which make the MS series so good,even if the gameplay is intact .

Re: How well can Metal Slug backgrounds be recreated with ti
by 93143 on 2018-05-27 (#219056)

TOUKO wrote:

the psx is way more powerful than any 16 bit home systems,and lack many animations and other stuffs which make the MS series so good,even if the gameplay is intact .

Yes, but why? It's not immediately obvious, and the fact that there are loading pauses suggests that it's RAM-bound, not DMA-bound. Besides, the Saturn version (which used a RAM expansion, on top of the console having more VRAM to start with) doesn't have this problem.

The PlayStation was not a uniform upgrade from the SNES. Most things were better, but at least one thing - storage access speed - was inarguably far worse. Therefore it is impossible to conclude just from that simple example that a SNES version would necessarily have the same problem.

Re: How well can Metal Slug backgrounds be recreated with ti
by TOUKO on 2018-05-28 (#219067)

Quote:

It's not immediately obvious

Yeah, i really saw the big difference when i launched the NG version directly after .

Quote:

and the fact that there are loading pauses suggests that it's RAM-bound,

Yes, but with main RAM and video RAM the PSX has 24 Mb of RAM (i do not count audio RAM), and even with his powerful chipset and CPU it's far from the orginal version .
Really i don't see how a snes or MD can even do a MS close to the PSX version .

Re: How well can Metal Slug backgrounds be recreated with ti
by 93143 on 2018-05-28 (#219072)

TOUKO wrote:

Quote:

It's not immediately obvious

Yeah, i really saw the big difference when i launched the NG version directly after .

That statement refers to the previous sentence, regarding the reason the PSX version has choppy animation. I can see it has choppy animation; what I can't see is a detailed system resource utilization profile.

However, it is possible to infer what might be going on based on knowledge of game design and of the PSX hardware.

Quote:

and the fact that there are loading pauses suggests that it's RAM-bound,

Yes, but with main RAM and video RAM the PSX has 24 Mb of RAM (i do not count audio RAM), and even with his powerful chipset and CPU it's far from the orginal version .

My point stands. There are mid-level loading pauses; therefore the game is RAM-bound (or else horribly programmed).

Forget the chipset. Choppy animation (as distinct from slowdown) in 2D games is almost never caused by insufficient computational power. It's caused by memory issues, generally storage limitations (which can translate into computational issues if compression is used, but I doubt that's the problem here), or else a limited budget to pay the sprite artists (inapplicable in this case). In the context of a CD-based console, "storage limitations" translates to RAM limitations, because the CD is huge but slow, and for sprite animation purposes you need to be able to grab a more or less random chunk of data very quickly. The only other reasonable possibility is DMA, and the PSX should be able to replace all of the graphics that actually appear on screen in less than 5% of a frame.

The memory buses are too fast for DMA to be the problem, and the frame rate is too solid for it to be a GPU issue. It can't be the CPU because a 33 MHz R3000 stomps a 12 MHz 68000 completely flat. It's sure as hell not a storage issue, not on a CD-based console. It seems that the only possible bottleneck is system RAM.

This inference is supported by the fact that the Saturn version uses a RAM expansion and animates just fine.

Quote:

Really i don't see how a snes or MD can even do a MS close to the PSX version .

Simple - they don't have the problem that's bottlenecking the PSX version, namely slow, high-latency storage access. A SNES with S-DD1 has effectively immediate high-speed access to all of the game data, and the same would be true of the Mega Drive with an appropriate mapper.

The 16-bit consoles could still end up bottlenecked by DMA or VRAM, but the PSX version isn't, so it doesn't tell us anything.

Re: How well can Metal Slug backgrounds be recreated with ti
by tepples on 2018-05-28 (#219075)

Yes, one big advantage of S-DD1 is random access to tile data.

But if backward scrolling is not needed, and if the drive's control unit supports asynchronous loading, random access might not be needed to load new areas without a pause. Format each level on disc to sort its individual 16x16-pixel tiles left to right by the position of their first use. Then as each tile falls off the left side of the screen, it becomes unused. The level file then includes instructions to replace each unused tile in memory, at the moment it becomes unused, with a tile used on the next screen. If this technique works for Haunted: Halloween '85, which devotes only 4 KiB to up to 256 distinct tiles in the visible portion of a level's background, it can probably be made to work for a system with much more memory than that.

At 4 bits per pixel, a 16x16 pixel tile is 128 bytes without compression. At 300 KiB/s, up to 2400 tiles can be theoretically streamed from disc into RAM every second. Even if every tile streamed in has 4 frames of animation, that's still 600 tiles in a second. A 320x224 pixel screen can only have (320/16+1)*(224/16+1) = 21*15 = 315 tiles per layer, and that's counting tiles that are half-visible at both the vertical seam and the horizontal seam, but not counting the tiles above and below the visible area of the primarily horizontally scrolling map.

Re: How well can Metal Slug backgrounds be recreated with ti
by TOUKO on 2018-05-28 (#219081)

Quote:

It seems that the only possible bottleneck is system RAM

Of course it is,and as you can see, even with 24Mb of RAM(main+VRAM) the loadings are frequent(we can conclude there is a lot of VRAM transferts),so if you can have the benefit of a cartridge speed, you are inevitably limited by the amount of VRAM and the DMA bandwidth,add to this the 16KB limit for sprites and you can see how that's hard to do it on snes ,and frankly MD too .

We have the GBA version as an example, it has been completely redone to have a chance to preserve the gameplay as much as possible ..
https://www.youtube.com/watch?v=ZVxr47jkufM

And i only consider data transfers, i do not count the number of sprites on screen,with all that implies in term of CPU usage.

Re: How well can Metal Slug backgrounds be recreated with ti
by psycopathicteen on 2018-05-28 (#219097)

Does the SDD-1 chip decompress stuff while DMA is happening? How does it do that?

Re: How well can Metal Slug backgrounds be recreated with ti
by tepples on 2018-05-28 (#219100)

S-DD1 reads compressed bits from ROM, decompresses them, stores the decompressed bits in some sort of queue, and makes them available when the CPU reads from an address on the cart that represents the output from the decompression circuit. Because it can produce 1 bit per master clock cycle, this is fast enough to keep the DMA unit fed.

Re: How well can Metal Slug backgrounds be recreated with ti
by 93143 on 2018-05-28 (#219102)

TOUKO wrote:

Quote:

It seems that the only possible bottleneck is system RAM

Of course it is,and as you can see, even with 24Mb of RAM(main+VRAM) the loadings are frequent(we can conclude there is a lot of VRAM transferts),so if you can have the benefit of a cartridge speed, you are inevitably limited by the amount of VRAM and the DMA bandwidth

No, that doesn't follow. Consider logically:

The problem isn't DMA. A Metal Slug screen uses memory roughly on the order of the amount of VRAM the SNES has, generally less. The main RAM bus on the PlayStation is 133 MB/s, and VRAM is twice that. So it doesn't matter if you can't fit all the animations in VRAM because you can easily swap them out from main RAM in virtually no time at all. Completely replacing all the graphics necessary to draw a frame 60 times a second would barely make a dent in your overall compute time, and the actual DMA load would be even less because you don't need to do that.

The problem isn't VRAM. Triple-buffering the framebuffer in 32-bit colour would still leave way more than enough space for the data necessary to display a Metal Slug screen, and there's no reason to go to either of those extremes; I'd guess almost 3/4 of VRAM is probably available for data. And from the previous paragraph we see that loading lots of data into VRAM is not necessary for animation purposes because DMA is so fast - all you actually need is the data for one frame.

The problem is, quite simply, the CD interface, with its anemic data rate and monstrous seek time. That's why loading is slow. And the reason why this matters is that if you want fast random access, you have to load the relevant data into RAM, and there isn't enough total RAM to hold all the stuff that needs fast random loading during a level. This is why the Saturn version works fine - even though its CD interface is also slow, it has an extra half megabyte of VRAM and an extra megabyte of work RAM (due to the use of an expansion cartridge) to load the animations into before the level starts, so it can access them quickly.

If the SNES had to use a CD interface to load its 128 KB of work RAM with animations and background tiles to transfer to VRAM, Metal Slug would be hilariously out of reach. But it doesn't. The entire contents of the cartridge are effectively already in RAM, which means the potential bottlenecks for a SNES port are factors that have nothing to do with why the PSX version is bad.

Quote:

add to this the 16KB limit for sprites and you can see how that's hard to do it on snes ,and frankly MD too .

You can actually work around the 16 KB sprite limit under certain circumstances if you're (very) careful, but honestly 16 KB is already more than half a screen worth of unique sprites. It's not obvious to me that level 1, at least, would run into this limit, particularly for objects that can show up anywhere on screen at any time (the Achilles' heel of the OBSEL trick). And in any case it's got nothing to do with animation smoothness, which is limited by DMA bandwidth on SNES and MD if you have adequate storage.

At 30 fps, an NTSC SNES could replace 16 KB of sprite data in two frames while leaving plenty of bandwidth for scrolling BG tile replacement. The animations in the Neo Geo version are fluid, but they're not 30 fps. The problem is non-scrolling BG tile replacement - lots of water in level 1, and at least some of it is 60 fps. Maybe it's possible to use tilemap animation, if there's enough spare VRAM... I don't think it's something that can be definitively answered without at least trying to make it work. (Besides, the water looks weird at 60 fps; it might almost be better if it had to be slowed down a bit.)

The Mega Drive doesn't have any of the weird sprite system limits the SNES has, so that's just a pure VRAM/DMA question. The MD's main problem is colour fidelity - even the SNES can't handle all the unique palettes without tricks, although it's probably possible to merge some palettes without being too obvious about it. But on MD they've had to suck it up and make obvious cuts even on a single BG layer with no action.

Quote:

We have the GBA version as an example

64 Mbit cartridge, no hardware decompression. Probably storage-limited.

Quote:

And i only consider data transfers, i do not count the number of sprites on screen,with all that implies in term of CPU usage.

Two things: First, a few well-programmed games and even some homebrew projects demonstrate that the SNES can actually handle quite a bit of action if programmed properly. (Note that Rendering Ranger is a SlowROM game - compare the shmup segments to Gradius III and realize that the CPU resources available to the devs were identical.)

Second, Metal Slug is 30 fps, so it's reasonable to expect twice as much onscreen action as the system could handle at 60 fps. And Metal Slug seems to slow down a fair bit even on the Neo Geo, possibly due to suboptimal programming practices. I don't think it's at all obvious that the SNES couldn't do an acceptable job, and if the SNES can handle it the MD probably can too.

...

None of this handwaving has anything to do with the PSX version having choppy animation. I think it's reasonably evident that the bottleneck in that case doesn't apply to the SNES or MD. And since the anticipated bottlenecks on 16-bit consoles aren't even close to being a problem on the PSX, the PSX version tells us nothing about the feasibility of a 16-bit port.

Re: How well can Metal Slug backgrounds be recreated with ti
by psycopathicteen on 2018-05-28 (#219103)

Alisha's Adventure already has a pretty advance dynamic animation engine, so I can probably reuse that for Metal Slug, if I'm making a port.

Re: How well can Metal Slug backgrounds be recreated with ti
by TOUKO on 2018-05-29 (#219109)

Quote:

the PSX version tells us nothing about the feasibility of a 16-bit port.

I am not saying it's not feasible, but you have to do an heavy butchering .
The real question is, at what level of fidelity is this possible ?
Look further in the first level for example, you 'll see the amount of animations and sprites, even the NG have slowdowns, and i don't see how the snes or md can doing it fluid even at 30fps ,and the other levels seems to be crazy at animations .

Quote:

so I can probably reuse that for Metal Slug, if I'm making a port.

We'll be happy if you can do some tests, of course i know it's time consuming, but starting a port like this it's not fingers in the nose and you'll spend a big amount of time .
The big advantage is that you'll don't have to care about all the game(gameplay,assets,sound, level design) but only code .

Re: How well can Metal Slug backgrounds be recreated with ti
by 93143 on 2018-05-29 (#219115)

TOUKO wrote:

Quote:

the PSX version tells us nothing about the feasibility of a 16-bit port.

I am not saying it's not feasible, but you have to do an heavy butchering .

Maybe. But you haven't demonstrated that, and the PlayStation version being cut down is no argument, as I believe I've shown.

Quote:

The real question is, at what level of fidelity is this possible ?

That's always the question. It can't be 100%, because the SNES can't output 320x224, and the Mega Drive can't handle enough colours (even the SNES may not be able to, depending on whether the palettes line up well for HDMA changeouts). So how close can you get? I think you could get reasonably close. I see no obvious reason why the character/object animations would have to be cut at all, never mind as much as in the PSX port.

Quote:

Look further in the first level for example, you 'll see the amount of animations and sprites, even the NG have slowdowns, and i don't see how the snes or md can doing it fluid even at 30fps ,and the other levels seems to be crazy at animations .

I've already looked further into the game, and so far I haven't seen anything that makes me as nervous as the water in Stage 1. (Actually, on that subject, back when Espozo was talking about trying to port Metal Slug, we looked at the waterfall BG near the ship hulk, and it turned out that several sections of each frame were identical to one another. I think there may be significant tile reuse going on in this game.)

Lots of arcade games are programmed like Gradius III, with no regard for efficiency. I doubt Metal Slug was optimized anywhere near as well as it could have been.

I think the detailed animation may be misleading. Given an arbitrary amount of ROM (the main selling point of the Neo Geo), adding extra frames to a given sprite animation should be fairly cheap in terms of peak computational load (though I could be wrong as I've never written an animation engine). It's not like it's full-screen FMV, either; it's not obvious to me that the DMA requirements of the sprites would be too high for the SNES.

Remember, lots of games use compressed graphics, which is a major hit to CPU time if you want to update a bunch of stuff all at once, but with the S-DD1 you don't have to care about that. I was thinking that if you ran into CPU troubles you could go with an SA-1, but then you're limited to 8 MB and software decompression so it's not necessarily a clear win...

Quote:

The big advantage is that you'll don't have to care about all the game(gameplay,assets,sound, level design) but only code .

Unfortunately that's not quite true. Just like with Gunstar Heroes, it's time-consuming to rejigger the game around the slightly lower horizontal resolution. At least this game seems to more or less ignore the tile grid gameplay-wise, but some BG graphics (thinking of that waterfall here) may still have to be reworked to retain the existing tile savings, or even increase them. Espozo was actually considering just leaving the graphics as-is and putting up with the distorted aspect ratio and reduced visibility.

It's possible to automate the graphics conversion to a degree, if you don't care about tile reuse (and for sprites you generally don't). I've found that when scaling only in one axis, using a high-fidelity antialiasing method in RGB space followed by a re-palettization to the original colours produces a reasonably good result requiring only minor tweaking. A more sophisticated method, such as the one used by RotSprite, could be even better.

And of course the audio might need some intelligent rework. Just having the ability to pitch-shift samples would probably save an enormous amount of space, but perhaps not enough by itself to make everything work with 64 KB of ARAM even with streaming.

Porting assets is still much easier than making them from scratch...

Re: How well can Metal Slug backgrounds be recreated with ti
by psycopathicteen on 2018-05-29 (#219119)

I think if you're doing Metal Slug on 16-bit systems, you would probably want to let the animations run slightly out of sync when the animation is intense. If there are large bosses, you might want to split it into 2 or more metasprites that animate out of sync, to avoid wasting VRAM on double bufferring.

Re: How well can Metal Slug backgrounds be recreated with ti
by TOUKO on 2018-05-29 (#219125)

Quote:

But you haven't demonstrated that

You're right, but i have a little bit of experience and i continue to think it's not so trivial and the guy who is going to do a MS conversion is going to shit pounded glass because of transferts,but like you, maybe i'am wrong :wink:

Quote:

It can't be 100%, because the SNES can't output 320x224, and the Mega Drive can't handle enough colours

Really, this is minor if you can do the rest with accuracy :wink:

If psycopathicteen is doing some tests we'll can see what is possible or not .

Re: How well can Metal Slug backgrounds be recreated with ti
by 93143 on 2018-05-29 (#219143)

TOUKO wrote:

You're right, but i have a little bit of experience and i continue to think it's not so trivial and the guy who is going to do a MS conversion is going to shit pounded glass because of transferts,but like you, maybe i'am wrong :wink:

That's fair.

I have some experience with SNES programming, though I'm not what I'd call an expert, and my current project (the danmaku port which will remain nameless) involves multiple scenarios where I have to jam large quantities of DMA into VBlank, so I'd like to think I have some idea of what you can do with a SNES. But I do tend to be a bit optimistic at times... Also, I have no experience with action platforming engines, so psycopathicteen or maybe HihiDanni or Espozo is probably better equipped to judge... Ultimately the only way to know for sure is to do it.

I just watched a playthrough of the entire game. I see nothing that's obviously impossible, given the 30 fps game speed and the abundant slowdown (a blessing in disguise when you're DMA-bound; drop one frame and you can basically replace all of OBJ RAM between engine updates), but there's a lot that's questionable.

A good bit of it, though, is amenable to workarounds with BG layers and such (especially some of the bosses), and there's at least one spot where the OBSEL trick could come in handy because a lot of the action is vertically segregated and the BGs look reasonably spare. I think the collapsing building is doable with a combination of sprites and Mode 2, and there may be other ways. Other than the water in Mission 1, I suspect the most dubious bit may be the explosions; they're big and plentiful and they animate fast. There are a couple of potential shortcuts that were discussed back when Espozo was attempting this... and maybe the big circular flashes could be done with windowing, but that only helps so much, and you'd run out of windows pretty quickly... Fortunately the debris from large explosions tends to be less detailed than one might have feared...

Obviously you'd be looking at extensive flicker/cheesegrater effect due to tile-per-line limits...

psycopathicteen wrote:

I think if you're doing Metal Slug on 16-bit systems, you would probably want to let the animations run slightly out of sync when the animation is intense. If there are large bosses, you might want to split it into 2 or more metasprites that animate out of sync, to avoid wasting VRAM on double bufferring.

I was thinking the same thing. Particularly if you wanted to try to bust the 16 KB limit with the OBSEL trick at some point; it can have dire implications for both DMA and VRAM usage if the situation isn't quite right for it...

Re: How well can Metal Slug backgrounds be recreated with ti
by Drew Sebastino on 2018-05-31 (#219197)

Oh yeah, Metal Slug is programmed like shit. I haven't done anything sort of disassembly, because it's obvious. The people at Irem that went to form Nazca must have favored x86 because both the M72 and M92 used x86 processors when no other arcade machine did, (unless they signed some sort of contract with NEC) and their games were still pretty badly programmed then.

psycopathicteen wrote:

Alisha's Adventure already has a pretty advance dynamic animation engine, so I can probably reuse that for Metal Slug, if I'm making a port.

How complex is it? You won't be able to afford any unused space or redundant tiles.

93143 wrote:

I see nothing that's obviously impossible, given the 30 fps game speed and the abundant slowdown (a blessing in disguise when you're DMA-bound; drop one frame and you can basically replace all of OBJ RAM between engine updates),

I'd first just try and shoot for 60fps for the hell of it. :lol:

I'd be funny to give people a reason to legitimately play this over the Neo Geo original. The 30fps honestly hampers my enjoyment of the game a bit (especially with the slowdown where it starts to look terrible)...

93143 wrote:

A good bit of it, though, is amenable to workarounds with BG layers and such (especially some of the bosses)

You could easily make all but the last boss a BG layer; the first boss is obviously just going to be the foreground layer, the second boss flies fully above the train and would use an IRQ or HDMA, the third boss only has the foreground, the fourth boss has a background, but it's fully above both tanks, and each tank is fully above the other, and the fifth boss also only has the foreground. The last boss is small enough though that I think I remember taking it apart and it fitting in about 3 64x64 sized sprites.

93143 wrote:

That's always the question. It can't be 100%, because the SNES can't output 320x224, and the Mega Drive can't handle enough colours

8 pixels on either side are blacked out, so you're only dealing with 48 less pixels in width; whatever you're missing on the sides of the screen should be negligible. The aspect ratio is going to off, but not enough to care. A Mega Drive port probably would not look good at all; 9 bit color won't look good for this game, and four palettes for the BG layers and 4 palettes for the sprites would be difficult enough, but I don't think you'd be able to share them with sprites and would have to somehow condense all the BG and sprite graphics down to two unique palettes... Not to mention you don't get an extra layer for the scoreboard so you'd probably have to black out behind that, and things like the background in front of the waterfall would pretty much be impossible.

93143 wrote:

I suspect the most dubious bit may be the explosions; they're big and plentiful and they animate fast. There are a couple of potential shortcuts that were discussed back when Espozo was attempting this... and maybe the big circular flashes could be done with windowing, but that only helps so much, and you'd run out of windows pretty quickly...

The explosions are 80x80 at their largest; I don't remember how fast they animate though. Luckily, explosions are pretty coordinated with each other, so you can use the same graphics. It'd be pointless to use windowing for the flashes when there's going to be a large sprite the same size later anyway; all this would be is a waste of HDMA channels. Windows would be more useful for other things, like the background over the waterfall.

You're going to have to use HDMA like crazy; you have the background palettes that need to be swapped out, you have the 2bpp scoreboard that you'd change a few colors to recreate the gradients, and if you want as many unique sprite palettes as the original, you're going to have to dynamically change the palettes down the screen, especially for 2 player. Can you use an IRQ to change the HDMA registers? That's the only way you're doing all this.

93143 wrote:

Obviously you'd be looking at extensive flicker/cheesegrater effect due to tile-per-line limits...

Yeah, that's innevitable. You can even make the original game drop sprite pixels if you keep spamming grenades and/or rockets; you'd want to drop old player created explosions if too many appear for this reason and that it'll shit all over your VRAM space and DMA bandwidth.

Re: How well can Metal Slug backgrounds be recreated with ti
by 93143 on 2018-05-31 (#219221)

Espozo wrote:

I'd first just try and shoot for 60fps for the hell of it. :lol:

If it came to a choice between 30 fps with an S-DD1 and 60 fps with an SA-1 and an MSU1, I'd probably choose the former just for the authenticity factor, never mind that it's a stronger proof of claim.

Also, I can't see one frame being enough for animation updates in all cases, so those would probably lag. Though without double buffering (which you'd probably want to avoid as much as possible to save VRAM, as psycopathicteen points out), there'd be a similar visual effect even with the engine at 30 fps...

I agree it would be great if you could hit 60 fps just with the S-CPU, but I'm not sure it's possible outside the lightest action segments (the beginning of Mission 1, some of Mission 3, the final boss, stuff like that). Also, slowdown is more pronounced at 60 because going from 60 to 30 is a bigger drop than going from 30 to 20, leaving aside the fact that it will happen more.

Quote:

8 pixels on either side are blacked out, so you're only dealing with 48 less pixels in width; whatever you're missing on the sides of the screen should be negligible. The aspect ratio is going to off, but not enough to care.

I don't know about that. It seems like narrowing the effective visible area that much (~16%) would negatively affect the gameplay, and it would certainly look wrong. There are a lot of graphics to convert, but if you were really going to the trouble of producing a faithful port of Metal Slug I would imagine you wouldn't want to cut corners where it's not necessary.

Besides, you can save PPU sprite bandwidth and DMA bandwidth (and ROM) by rescaling the graphics, at least on large or partly blank sprites. The Mega Drive gets ~25% more DMA speed and 25% more sprite overdraw in H40 mode as compared with H32 mode, and all of it is eaten up by the extra resolution.

If you wanted to be a cheeseball and cut six or seven pixels from each side of the screen (or, honestly, even if you didn't), you could scale the graphics from 320 to 256, and that 80x80 explosion would be 64x80.

Quote:

Can you use an IRQ to change the HDMA registers? That's the only way you're doing all this.

Yes, you can (though it's kinda tricky to repurpose an HDMA channel mid-frame)...

...but you're just describing palette work. One HDMA channel can address one CGRAM entry per line regardless of where it is or why you're changing it. If all you're doing is changing colours, you can combine a bunch of unrelated palette changes into one HDMA channel; if they overlap, just spill to the next channel until you run out, and then spill to the next line. Or something like that.

You might be able to save compute time by using indirect tables, since you could then simply stick a pointer to the desired data in the HDMA table and use repeat mode, instead of having to copy the whole thing (you'd have to store interleaved index/index/colour data in ROM for every combination of subpalette index and sprite colour list, but they're just 60 bytes each, and how many could there possibly be?).

Re: How well can Metal Slug backgrounds be recreated with ti
by Drew Sebastino on 2018-05-31 (#219229)

Quote:

If it came to a choice between 30 fps with an S-DD1 and 60 fps with an SA-1 and an MSU1, I'd probably choose the former just for the authenticity factor.

I'm not entirely convinced it couldn't run at 60fps just on the 5A22 though; you can always point to Rendering Ranger R2 and how it runs on a SlowROM cart. I don't know how well the extra speed of a FastROM cart is going to cover the dynamic vram engine, palette sorting, but I figure it wouldn't have more slowdown at 60fps than the original at 30fps...

Quote:

Also, I can't see one frame being enough for animation updates in all cases, so those would probably lag. Though without double buffering (which you'd probably want to avoid as much as possible to save VRAM, as psycopathicteen points out), there'd be a similar visual effect even with the engine at 30 fps...

Yeah, 30fps really isn't going to give you an advantage for this reason. The largest, most animated common things are the 80x80 explosions, and they're like 3KB at largest; you basically have to double buffer these. Luckily though, they pretty much always go off at the same time, so you only need to store and update graphics for one. Smaller explosions often don't go off at the same time, but slightly after one another, so you couls still only need to animate the first one.

Quote:

but if you were really going to the trouble of producing a faithful port of Metal Slug I would imagine you wouldn't want to cut corners where it's not necessary.

But palettes are not going to align perfectly like they did, so you won't be able to just automate converting the graphics, which means it's going to take forever and a half. This is my opinion, but unless the person converting the graphics has a lot of experience (and even more time), it's probably going to look worse than the stretched original anyway. Most games that I've seen that were on the Genesis and the SNES ran at 320 pixels wide on the Genesis and used the exact same artwork (minus the difference in color) for both versions. You can tell that even SNES exclusive games often have artwork that assumes square pixels.

Re: How well can Metal Slug backgrounds be recreated with ti
by psycopathicteen on 2018-05-31 (#219235)

Espozo wrote:

Oh yeah, Metal Slug is programmed like shit. I haven't done anything sort of disassembly, because it's obvious. The people at Irem that went to form Nazca must have favored x86 because both the M72 and M92 used x86 processors when no other arcade machine did, (unless they signed some sort of contract with NEC) and their games were still pretty badly programmed then.

psycopathicteen wrote:

Alisha's Adventure already has a pretty advance dynamic animation engine, so I can probably reuse that for Metal Slug, if I'm making a port.

How complex is it? You won't be able to afford any unused space or redundant tiles.

What my animation engine can do:
- Display up to 24 unique 32x32 sprite patterns and 32 unique 16x16 sprites patterns at once
- Update 4kB of sprite patterns in one frame
- Automatic animation delay to prevent DMA overflow
- Automatic duplicate frame checking
- Metasprites are allowed to have several copies of the same sprite pattern within itself

Shortcomings:
- Doesn't do any predictive double buffering
- Can't reactivate left over dead sprite patterns
- Activates newest vacant sprite slot, instead of oldest vacant sprite slot
- Can't animate metasprites larger than 4kB without breaking it into smaller parts
- Non-identical metasprites can't share a duplicate sprite pattern in VRAM
- Can't split a 32x32 sprite slot into 4 16x16 sprite slots, and vise versa
- Doesn't have any split screen page-switching (this would be rocket science)

Re: How well can Metal Slug backgrounds be recreated with ti
by tepples on 2018-05-31 (#219237)

Pinocchio and Pac-Attack run at 256 on both platforms.

Re: How well can Metal Slug backgrounds be recreated with ti
by 93143 on 2018-05-31 (#219239)

Espozo wrote:

Quote:

If it came to a choice between 30 fps with an S-DD1 and 60 fps with an SA-1 and an MSU1, I'd probably choose the former just for the authenticity factor.

I'm not entirely convinced it couldn't run at 60fps just on the 5A22 though; you can always point to Rendering Ranger R2 and how it runs on a SlowROM cart. I don't know how well the extra speed of a FastROM cart is going to cover the dynamic vram engine, palette sorting, but I figure it wouldn't have more slowdown at 60fps than the original at 30fps...

I dunno. Rendering Ranger has a lot less going on in the run&gun segments, and feels more scripted. People have done neat stuff on the SNES, but there's really an awful lot going on in Metal Slug at times.

Quote:

Also, I can't see one frame being enough for animation updates in all cases, so those would probably lag. Though without double buffering (which you'd probably want to avoid as much as possible to save VRAM, as psycopathicteen points out), there'd be a similar visual effect even with the engine at 30 fps...

Yeah, 30fps really isn't going to give you an advantage for this reason.

No, I'm pretty sure it'd still be a big advantage. You'd only need to run the game logic half as fast, including everything from physics and collisions to HDMA palette swap scheduling. About the only thing that wouldn't have its compute time requirements cut in half would be the animation engine. A good load-leveling DMA engine might give you broadly similar performance between 30 and 60 fps, but everything else would be immensely eased and you'd spend a lot less time with the gameplay speed cut to half or one-third.

Actually, it occurs to me that even DMA might be easier at 30 fps, because you only have to update OAM and CGRAM once every engine cycle.

Quote:

The largest, most animated common things are the 80x80 explosions, and they're like 3KB at largest; you basically have to double buffer these.

Do you? Even 3 KB fits into VBlank quite nicely, and if you have to delay updating something anyway, you might as well delay something else. And if you scaled it from a 320-wide starting point, it would only be 2.5 KB (though it could be more fiddly to transfer).

Quote:

But palettes are not going to align perfectly like they did, so you won't be able to just automate converting the graphics, which means it's going to take forever and a half. This is my opinion, but unless the person converting the graphics has a lot of experience (and even more time), it's probably going to look worse than the stretched original anyway.

That's true, but you don't have to redraw it completely. With an appropriate tool (and what are you doing converting Metal Slug backgrounds if you haven't set yourself up with appropriate tools), you could automate the initial conversion and then manually re-palettize any collisions, and if necessary rejigger the palettes to ensure there are only 8. If you got desperate you could even patch it up with sprites, though I doubt you'd want to...

Sprites typically only use one palette anyway, so converting them is easy.

I really think you're underestimating the gameplay impact of changing the aspect ratio that much. And I still think the size reduction could be important.

I've attached the large explosion, converted from 320-wide to 256-wide (so, 64x80) by sinc rescaling in GIMP and repasting over a 16-colour indexed version of the original. No touch-ups have been made. And this is a very simple method; unfortunately RotSprite doesn't support anisotropic scaling like this, but their method pretty clearly generalizes to it...

Attachment:

ms_explarge_rescale0.png [ 54.91 KiB | Viewed 2861 times ]

psycopathicteen wrote:

- Update 4kB of sprite patterns in one frame

Was this just intended to leave space for OAM, CGRAM and BG map and tile updates, or is a significant chunk of it CPU time for dispatching the transfers?

Quote:

- Doesn't have any split screen page-switching (this would be rocket science)

Yeah, in the general case it seems like it'd be extraordinarily difficult. Maybe impossible.

In a specific case where a lot of things are happening on two separate levels without crossing between them, while some other things can cross over, it might be possible to reserve 8 KB for full-screen action and 8 KB each for the upper and lower levels, switch at a fixed V-position, and just special-case the engine to deal with it.

No?

Re: How well can Metal Slug backgrounds be recreated with ti
by tepples on 2018-05-31 (#219241)

I cloned RotSprite in Python as Rotpixels. If I remember correctly, it supports this sort of aniso scaling. (It probably needs to be updated for Pillow 4's changes to nearest neighbor resampling offset.)

Re: How well can Metal Slug backgrounds be recreated with ti
by psycopathicteen on 2018-05-31 (#219242)

93143 wrote:

psycopathicteen wrote:

- Update 4kB of sprite patterns in one frame

Was this just intended to leave space for OAM, CGRAM and BG map and tile updates, or is a significant chunk of it CPU time for dispatching the transfers?

OAM, yes.
CGRAM, no.
BG map updates, yes.

Re: How well can Metal Slug backgrounds be recreated with ti
by Drew Sebastino on 2018-05-31 (#219253)

Quote:

I dunno. Rendering Ranger has a lot less going on in the run&gun segments, and feels more scripted. People have done neat stuff on the SNES, but there's really an awful lot going on in Metal Slug at times.

And there's an awful lot of slowdown when there is. :lol:

Other than the final stage (which pushes 12 enemies at once in the begining) I don't think the load is too much different; Rendering Ranger R2 actually pushes more player bullets (even when taking into account two players) for one thing.

Quote:

No, I'm pretty sure it'd still be a big advantage.

I meant in the context of animation.

Quote:

Actually, it occurs to me that even DMA might be easier at 30 fps, because you only have to update [...] CGRAM once every engine cycle.

Not necessarily; if you're using HDMA to change colors down the screen, you're going to have to reset them every frame.

Quote:

I really think you're underestimating the gameplay impact of changing the aspect ratio that much.

Well, as a rudimentary test, view the game, but cover everything to the left of the second pow icon and everything to the right of the the number of credits at the bottom of the screen. As is, I didn't find it that jarring, but you'd probably still want to move the camera around a bit to better capture everything.

Quote:

Was this just intended to leave space for OAM, CGRAM and BG map and tile updates, or is a significant chunk of it CPU time for dispatching the transfers?

I've got to ask, why designate different amounts of time for everything?

Quote:

Yeah, in the general case it seems like it'd be extraordinarily difficult. Maybe impossible.

Not to mention all the BG graphics probably won't allow sprites to use more than 16KB anyway. With the space efficient method psychopathicteen is using, I don't think it is as much of a problem as the VBLANK DMA limit.

Quote:

What my animation engine can do:

The one thing I'd try and push for for space concern is removing the distinction between 16x16 and 32x32 sprites and just let them fight for the same space. I have no idea what sort of repercussions there would be though. Still the most advance VRAM engine for the SNES by a wide margin.

Re: How well can Metal Slug backgrounds be recreated with ti
by 93143 on 2018-06-01 (#219261)

Espozo wrote:

I've got to ask, why designate different amounts of time for everything?

Huh? Am I understanding your question correctly?

It's just a matter of budgeting your VBlank time. Make sure you've accounted for everything that MUST get done to avoid glitching, such as updating OAM and refreshing the tilemap, and then see how much time you've got left for tasks that can be delayed a bit, like sprite animation. Remembering of course that you can't just DMA chunks all over VRAM back to back; you need to stop and change the destination address, which starts eating into your bandwidth if you have to do it too often.

This calculation could perhaps be automated in a truly general method. My shmup port doesn't really need a general method, so I've done a fair bit of cycle-counting to make sure everything fits in the worst-case scenario. 9 KB sounds like a lot, but when the Super FX is feeding you nearly 7 KB per frame you've got to be thrifty with the remaining bandwidth...

I did manage to rig my CGRAM HDMA so it restores the colours to their top-of-frame values before the end of the frame. Very useful; saved at least one DMA transfer. This may not be possible with Metal Slug - with five HDMA channels (setting aside one for audio streaming and two for other stuff), it would take 24 lines just to reset the sprite palettes, assuming you'd changed all of them - though perhaps there's a smart way to handle this that happens to not break in the actual game... The HUD would be pretty easy to reset in the top few lines. Other BG layers probably don't need HDMA in the first place...?

Oh hey - I just realized that setting a palette with all N HDMA channels (N being however many you end up reserving for CGRAM) gets done a lot faster than just piling all 15 colours into one channel. (Yes, I'm stupid today. We discussed this years ago.) And you can still get N palettes changed in 15 lines. The drawback is of course more CPU time; at minimum you now have to write N pointers per palette change rather than one... on the other hand, collision avoidance when scheduling could be simpler... on the other other hand, this method wouldn't work at all at the altitude of the HUD, but then perhaps it wouldn't need to all that often...

Re: How well can Metal Slug backgrounds be recreated with ti
by Drew Sebastino on 2018-06-01 (#219266)

Yeah, I think the general thing with this project is that you can make the port as detailed and close to the original as possible, but it's a hell of a lot of trickery/work. With all the cartspace in the world, even an official port would have turned out to be shit. I don't think any developer would have made a dynamic, sprite palette changing engine just to avoid having to condense the bullet and explosion palettes together. :lol:

Re: How well can Metal Slug backgrounds be recreated with ti
by psycopathicteen on 2018-06-01 (#219267)

I don't think Metal Slug would need a lot of palette switching.

Re: How well can Metal Slug backgrounds be recreated with ti
by Drew Sebastino on 2018-06-01 (#219275)

It would; the backgrounds usually fit into 8 palettes, but not always, and then you've got the scoreboard that wants 2 additional palettes. Sprites really want more palettes; just about every object uses a unique palette. For example, there's player 1, player 2, the weapon pickup icon, the ammo crate, POWs, soldiers, the soldier shot shot/grenade, the sherman tank wannabe, the shotgun blast, the machine gun fire, shrapnel... I mean, even the grenade explosion and the standard explosion have different palettes... Most screens won't use more than 8 palettes, but you really can't count on it, especially with 2 players. I think I've counted 12 palettes on-screen with 2 players before, but they were stacked vertically enough to where it would work.

Re: How well can Metal Slug backgrounds be recreated with ti
by 93143 on 2018-06-01 (#219277)

The thing is, these palette changes aren't free. (Well, the HUD is - you just need to keep the HDMA in place, and it's such a tiny fraction of CPU time that you'll never miss it.) You'd have to spend a lot of time checking for palette usage and scheduling the changes. You could very well end up with significantly more slowdown simply because you refused to harmonize █████ with █████. And it's not like the rest of the game is going to be 100%; there's going to be either a lower resolution or a narrower screen, a lot more sprite dropout, sprites animating out of sync with the frame rate - and it's probably not going to sound the same either. Merging a few palettes wouldn't be the end of the world.

...if it could be pulled off without exceeding the amount of slowdown in the original (and without single-handedly sinking the project into development hell), I think I might go for it. Might at least be worth a try...

Re: How well can Metal Slug backgrounds be recreated with ti
by Drew Sebastino on 2018-06-01 (#219279)

93143 wrote:

...if it could be pulled off without exceeding the amount of slowdown in the original (and without single-handedly sinking the project into development hell), I think I might go for it. Might at least be worth a try...

It's more for authenticity / bragging rights / whatever than actual visuals; the majority of people probably wouldn't even notice the palettes were condensed. :lol:

Background updates should still mostly be free though, correct? The difficulty would be working the sprite palette updates around these, unless you're fine with potentially halving the color changing bandwidth by reserving some HDMA channels for background color updates and some HDMA channels for sprite color updates.

I really kind of wonder how you'd arrange this...I think I suggested that you'd start with something like virtual palettes that you'd have to find where their top and where there bottom is on the screen, and then sort them. The problem is, the only way it seems to find the area for each palette would be to compare the visual area of each object with the visual area of the palette it's requesting, so basically one dimensional collision. The palette area will grow if an objective using that palette is above or below it.

Re: How well can Metal Slug backgrounds be recreated with ti
by 93143 on 2018-06-08 (#219527)

Espozo wrote:

Background updates should still mostly be free though, correct?

Yeah, BG changes should be fairly cheap because you can just schedule them like tile updates. As long as the sprite repalettizer knows about them and can work around them.

I'm just wondering if these extra palettes really are always vertically segregated, or if there are enough situations where they'd inevitably collide that it'd look better to just harmonize them. Palette streaking would probably be more noticeable than slightly inauthentic colours...

Those cars in the example you used last time might be doable with a BG layer.

psycopathicteen wrote:

- Update 4kB of sprite patterns in one frame

I'm wondering if it's feasible to get this up to 5 KB, at least conditionally. With a standard 38-line VBlank, you've got a little over 6 KB of time. Subtracting OAM and 5 KB of sprite data still leaves well over half a KB. Updating one row or column of two BG maps, along with the requisite tile data (assuming 100% new) can be done in four frames at 544 bytes per frame, leaving about half a scanline for overhead.

Probably too tight for the general case (especially if Metal Slug ever scrolls faster than four layer-pixels per frame). But it might be helpful to be able to detect situations where extra sprite data (or BG data, for BG-based pseudosprites) will fit into VBlank.

On the other hand, if large areas of CGRAM need updating too, that might get in the way too much... I don't like the idea of having to trim the screen vertically, though perhaps a couple of lines could go mostly unnoticed... Or maybe BG update stuffing could leave some frames clear for extra OBJ data. Metal Slug isn't the sort of game where leaving DMA bandwidth on the table is a good idea if you can avoid it.

Re: How well can Metal Slug backgrounds be recreated with ti
by psycopathicteen on 2018-06-08 (#219529)

I have thought about putting SRAM in the Fast ROM region so you can have a fast self modifying code for vblank. If I do 2 16x16 at a time so that every DMA transfer is $80 bytes long, I can write the same value to both $420b and $4375.

Re: How well can Metal Slug backgrounds be recreated with ti
by MottZilla on 2018-06-09 (#219610)

93143 wrote:

TOUKO wrote:

Quote:

It seems that the only possible bottleneck is system RAM

Of course it is,and as you can see, even with 24Mb of RAM(main+VRAM) the loadings are frequent(we can conclude there is a lot of VRAM transferts),so if you can have the benefit of a cartridge speed, you are inevitably limited by the amount of VRAM and the DMA bandwidth

No, that doesn't follow. Consider logically:

The problem isn't DMA. A Metal Slug screen uses memory roughly on the order of the amount of VRAM the SNES has, generally less. The main RAM bus on the PlayStation is 133 MB/s, and VRAM is twice that. So it doesn't matter if you can't fit all the animations in VRAM because you can easily swap them out from main RAM in virtually no time at all. Completely replacing all the graphics necessary to draw a frame 60 times a second would barely make a dent in your overall compute time, and the actual DMA load would be even less because you don't need to do that.

The problem isn't VRAM. Triple-buffering the framebuffer in 32-bit colour would still leave way more than enough space for the data necessary to display a Metal Slug screen, and there's no reason to go to either of those extremes; I'd guess almost 3/4 of VRAM is probably available for data. And from the previous paragraph we see that loading lots of data into VRAM is not necessary for animation purposes because DMA is so fast - all you actually need is the data for one frame.

...

None of this handwaving has anything to do with the PSX version having choppy animation. I think it's reasonably evident that the bottleneck in that case doesn't apply to the SNES or MD. And since the anticipated bottlenecks on 16-bit consoles aren't even close to being a problem on the PSX, the PSX version tells us nothing about the feasibility of a 16-bit port.

With PS1 you start out with 1 Megabyte of VRAM and then subtract your frame buffers from that. For a 320x240 game you lose around 307,200 bytes. So you'd lose more than a quarter of the available VRAM. I'm not sure what you are talking about with triple buffering or 32-bit color. If that was in relation to PS1, I'm fairly sure there is no 32bit color and not aware of any game that would use 3 frame buffers. What games typically do is load background tiles in VRAM and maybe some objects/enemies that don't take a ton of frames. The player (or players) which usually have lots of animation typically have their graphics loaded into the main work RAM and are DMAed to VRAM as needed. This sort of setup can be seen in SNES games too.

The problem with Metal Slug (and Metal Slug X) on PS1 is obviously a lack of RAM. You cited the Sega Saturn which benefits from a RAM expansion cartridge and has a very solid port of Metal Slug. If the PS1 had an additional 1 megabyte or more of RAM it could have had a similarly good port. But Sony never created one. Maybe the Parallel I/O slot on the back wasn't capable of adding additional memory. Or maybe it was and they didn't feel it was worth it to create one. Plenty of other 2D games from this era demonstrate the PS1's lack of RAM.

And none of this is relevant to the SNES. But a more important question is are you thinking you'll just make your own clone of the game with modified assets? Or are you actually looking to reverse engineer the game?

On the subject of optimization, check out Metal Slug 2. It's way worse with slowdowns. Metal Slug X and Metal Slug 3 improve on performance over the first two games. The bottom line though is Metal Slug was given NeoGeo Pocket versions. So anything is possible if you cut it down enough. And no matter what any SNES version of Metal Slug would pale in comparison to the original.

Re: How well can Metal Slug backgrounds be recreated with ti
by 93143 on 2018-06-10 (#219617)

MottZilla wrote:

With PS1 you start out with 1 Megabyte of VRAM and then subtract your frame buffers from that. For a 320x240 game you lose around 307,200 bytes. So you'd lose more than a quarter of the available VRAM.

I was not trying to suggest that there was enough VRAM for all the animations. My point was that regardless of any framebuffer considerations, there was certainly enough VRAM for one frame, and that since DMA was fast enough to replace all the graphics data needed to draw one frame in much less than a frame, VRAM as such was therefore not a bottleneck.

I was attempting to demonstrate by process of elimination that the bottleneck had to be the CD interface, which then caused the game to be RAM-limited. And the PSX has nowhere near as much RAM as a SNES+S-DD1 has ROM, meaning the reason the PSX port came out choppy doesn't apply to the SNES, meaning you'd have to actually examine the problem to conclude anything about a hypothetical SNES port rather than just assuming the PSX version to be indicative.

Also, it seems my estimate of the actual likely framebuffer size ("almost 3/4 of VRAM is probably available for data") matches yours pretty closely. In fact most of your post sounds like you're agreeing with me. Was that your intention?

Quote:

I'm not sure what you are talking about with triple buffering or 32-bit color. If that was in relation to PS1, I'm fairly sure there is no 32bit color and not aware of any game that would use 3 frame buffers.

What I was getting at is that even if you were to max out the amount of VRAM used by the framebuffering (triple-buffering is a thing, though I'm not sure how helpful it'd be here), there'd still be plenty left for the graphics data used to draw the frame. I was not suggesting that this was a likely approach (particularly since the Neo Geo uses 15-bit colour).

As for 32-bit, I've been reading up on the N64 lately, and I guess I just assumed that the PlayStation's true-colour mode was 32-bit. The N64 stores alpha in the framebuffer for a couple of reasons, but I guess the PSX just uses 24-bit...

Quote:

The player (or players) which usually have lots of animation typically have their graphics loaded into the main work RAM and are DMAed to VRAM as needed. This sort of setup can be seen in SNES games too.

Generally that's done when software decompression is used. With uncompressed graphics, or a decompression chip like the S-DD1 that's capable of feeding DMA, there'd be no need to use WRAM for graphics.

Quote:

The problem with Metal Slug (and Metal Slug X) on PS1 is obviously a lack of RAM.

Exactly. And the only reason that matters is that the CD drive is too slow and high-latency to act as proper ROM. Therefore

Quote:

none of this is relevant to the SNES.

Which was my point, in opposition to TOUKO who seemed to be maintaining that the choppy animation in the PSX version somehow indicated that the game would be even worse on SNES. It very well might be, of course, but if so it would be for unrelated reasons.

Quote:

But a more important question is are you thinking you'll just make your own clone of the game with modified assets? Or are you actually looking to reverse engineer the game?

The idea here would be to port the actual game as faithfully as possible; hence the talk of switching out sprite palettes with HDMA so as to be able to use more than 8.

I'm pretty sure it's a hypothetical at this point - maybe a team will come together around it someday, but I at least am certainly too busy right now. In any case I imagine Espozo would want to be involved; he started learning SNES dev with the idea of making this port himself.

There are a number of ports that could be interesting to try. This is one of them. The danmaku game I'm porting (which I won't name at this stage) is another. TIE Fighter, Thunder Force IV... psycopathicteen was poking at Gunstar Heroes at one point, but seems to be working on an original IP now... Games like Street Fighter Alpha 2 and Doom that appear to have been ported suboptimally could be interesting targets too. But these are all fairly big projects, and together with copyright issues this suggests that few would be willing to bother.

Super Road Blaster exists. It's possible it was simpler to port due to its nature as a laserdisc game with minimal interactivity, but it's at least a completed example, pulled off by one person no less...

A clone of Metal Slug with modified assets (as in real new art, not just rescaled Metal Slug art) would be massively more time-consuming than a straight port even if the art was bad.

Quote:

And no matter what any SNES version of Metal Slug would pale in comparison to the original.

I'm not sure I can agree with this given the current state of the question, though I suppose it depends what you mean by "pale". Certainly it wouldn't be a perfect port. There would be far more sprite dropout as well as a lower horizontal resolution. But it's not clear to me how much worse it would need to get beyond that, because no one's tried it. With an S-DD1 there'd certainly be enough ROM...

Re: How well can Metal Slug backgrounds be recreated with ti
by TOUKO on 2018-06-10 (#219620)

Quote:

Which was my point, in opposition to TOUKO who seemed to be maintaining that the choppy animation in the PSX version somehow indicated that the game would be even worse on SNES.

Yes because when i read all the comments here, you all seem to think that DMA bandwidth is the only problem to solve to do a good MS port .
DMA bandwidth is only one of the problems,you have to deal with the tons of BGs animations, collisions, the huge and many sprites .
The NG's CPU is only taxed by the game logic and collisions detection,he don't care of VRAM transferts and is not impacted by them and it slow down,really i don't see how the snes's CPU (or MD one) can do better, even if you can juge the NG version as a lazy programming, it still a 10Mhz CPU .

Quote:

The idea here would be to port the actual game as faithfully as possible

i agree else this topic is a nonsense,the goal is to do a conversion as close as possible.

Re: How well can Metal Slug backgrounds be recreated with ti
by 93143 on 2018-06-10 (#219657)

TOUKO wrote:

you all seem to think that DMA bandwidth is the only problem to solve to do a good MS port .

I don't think I've ever implied this. It's certainly one possible source of trouble, and it's much easier to quantify and have discussions about than CPU load, for instance.

What I've been arguing is specifically that the PlayStation version having choppy animation is not evidence of what you are contending. It's purely a memory issue, which doesn't exist on SNES. And none of the possible problems with a SNES version (CPU, DMA, VRAM, OAM) are even close to being problems on PSX. So the comparison is pointless. It doesn't imply anything.

Re: How well can Metal Slug backgrounds be recreated with ti
by TOUKO on 2018-06-11 (#219682)

Quote:

It's purely a memory issue,

Not only, there is less sprites on screen and it slow down a lot too and seems less fluid overall.
You can have all the ROM space you want, if you are not able to transfer all the datas and manage all the sprites/collisions needed, it's a pure waste,that's my point :wink:

And even with a SDD-1, i'am really curious if somebody can do something better or impressive only with the stock CPU, because for me there is really too much on screen .

Re: How well can Metal Slug backgrounds be recreated with ti
by lidnariq on 2018-06-11 (#219705)

... They literally said:

93143 wrote:

the PlayStation version having choppy animation

Quote:

purely a memory issue, which doesn't exist on SNES

That's it. Nothing more.

Their entire point is:

PSX version has problems
Those problems imply NOTHING about the feasibility of a good SNES port.

Re: How well can Metal Slug backgrounds be recreated with ti
by 93143 on 2018-06-11 (#219706)

TOUKO wrote:

there is less sprites on screen

Isn't that mostly just debris and stuff? That could pretty easily be explained by the memory issue - maybe they didn't want to waste space on details irrelevant to gameplay.

Quote:

and it slow down a lot too

I'm not seeing it.

In any case, if it did have slowdown, it would have to be either deliberate or incredibly lazy, because a 33 MHz R3000 destroys a 12 MHz 68000, and even 33 Mpix/s is enough to draw over the whole screen roughly 15 times in 1/30 of a second. There's no way this game is legitimately overtaxing either the CPU or the GPU.

It's hard to figure this stuff out with quick web searches, but Metal Slug X at least is said to have no slowdown on PlayStation.

Quote:

and seems less fluid overall.

Yeah, choppy sprite animation (and loading pauses) will do that. Maybe this is why it looks like slowdown? Possibly combined with YouTube conversion issues making the whole thing even choppier?

...

There should have been a Nintendo 64 version. Even the slowest cartridge speed of about 5 MB/s would have been more than enough, and with the monster CPU for decompression, the whole game probably could have fit in a 12 MB cartridge. The N64 isn't known for 2D games, but it has a surprising amount of support for various types of limited drawing that never really got used, and its theoretical performance when drawing untransformed alpha-keyed graphics is 250 Mpix/s. Taking TMEM loading into account and assuming no tile reuse, that drops to a bit under 200 Mpix/s, or eight Neo Geos... you'd have to use big enough chunks to get a substantial fraction of that, of course, but it'd be simple to rearrange the backgrounds and large bosses in horizontal strips, and most other objects, even the 80x80 explosion, would fit in TMEM with room to spare...

...

Also, I was reading sega-16 and found this comment:

TheSonicRetard wrote:

Joe Redifer wrote:

I often wonder if the Neo Geo could even do a game like Space Harrier with it's constantly changing floor.

If nothing else, the Neo Geo could brute force the floor from space harrier through FMV.

It's funny because it's true...

Re: How well can Metal Slug backgrounds be recreated with ti
by psycopathicteen on 2018-06-11 (#219723)

Quote:

Subtracting OAM and 5 KB of sprite data still leaves well over half a KB. Updating one row or column of two BG maps, along with the requisite tile data (assuming 100% new) can be done in four frames at 544 bytes per frame, leaving about half a scanline for overhead.

If you figure out how many palettes or tiles you need before you do the dynamic animation routine, the dynamic animation routine can work around whatever DMA time is left.

Re: How well can Metal Slug backgrounds be recreated with ti
by TOUKO on 2018-06-11 (#219728)

Quote:

I'm not seeing it.

A quick example .
https://www.youtube.com/watch?v=34sU5DVIGMM&t=137s

Quote:

Yeah, choppy sprite animation

No it's not really a question of choppy animations, all seem slower, maybe it's the video,or it's because the psx is emulated here i don't know .
But i agree MSx seems a way better game technicaly,it has way less flaws .

TheSonicRetard wrote:

Joe Redifer wrote:

I often wonder if the Neo Geo could even do a game like Space Harrier with it's constantly changing floor.

If nothing else, the Neo Geo could brute force the floor from space harrier through FMV.

The space harrier floor effect is nothing else than a raster effect which can be donne even with sprites,sega did it like that for the Md version (the raster effect ,but with BG not sprites) .

Re: How well can Metal Slug backgrounds be recreated with ti
by 93143 on 2018-06-12 (#219729)

TOUKO wrote:

Quote:

I'm not seeing it.

A quick example .
https://www.youtube.com/watch?v=34sU5DVIGMM&t=137s

Nope, still not seeing it. I really think it's a combination of choppy sprite animation and poor video sync. Look at the Slug's machine gun; it doesn't change its fire rate at all.

Quote:

The space harrier floor effect is nothing else than a raster effect

I know; I posted that because I thought it was humorous. I almost wouldn't put it past a Neo Geo developer to do that...

Re: How well can Metal Slug backgrounds be recreated with ti
by TOUKO on 2018-06-12 (#219730)

Quote:

Nope, still not seeing it. I really think it's a combination of choppy sprite animation and poor video sync. Look at the Slug's machine gun; it doesn't change its fire rate at all.

The example was for the boss part, few seconds later !!

The saturn version seems to slow down even more, but i don't know if it's related to emulation, or it's the same on real thing .
https://youtu.be/waIxNfAMUBY?t=58s

EDIT: i think this is because emulation .

Re: How well can Metal Slug backgrounds be recreated with ti
by 93143 on 2018-06-12 (#219731)

I still don't see any unambiguous slowdown. If it's there, it's minor, and could be due to a number of factors other than system overload. Emulation is one possibility. Also, the frame rate of the video is low and doesn't seem to be well synchronized with the game's frame rate, which results in strange effects, most obviously with the water. If the game is emulated, frame rate inconsistencies could stack and result in funky timing in the final video. Again, the machine gun's rate of fire seems to be pretty consistent.

As for the Saturn version, a) the Saturn was far harder to program, and b) they may simply have been attempting to emulate the slowdown in the arcade - apparently it's very similar if you use the right RAM cartridge (reportedly, using anything other than the original 1 MB cart slows it down more, which also suggests something weird in the programming).

Re: How well can Metal Slug backgrounds be recreated with ti
by psycopathicteen on 2018-06-12 (#219743)

I almost forgot, you can block move 5kB of data together to speed up DMA. Although block moving could be kind've slow, unless you time DMA around HDMA.

Re: How well can Metal Slug backgrounds be recreated with ti
by 93143 on 2018-06-12 (#219757)

psycopathicteen wrote:

If you figure out how many palettes or tiles you need before you do the dynamic animation routine, the dynamic animation routine can work around whatever DMA time is left.

Sounds good.

I just remembered that Metal Slug, if it remains at 30 fps, only requires OAM to be updated every other frame. That might leave some extra room even if CGRAM has to be updated every frame (which may not be necessary; it may be possible to reset any changed BG palettes with HDMA before the end of the frame, which would make CGRAM updates fairly rare if sprite palettes were harmonized rather than rewritten with HDMA).

psycopathicteen wrote:

I almost forgot, you can block move 5kB of data together to speed up DMA. Although block moving could be kind've slow, unless you time DMA around HDMA.

Yeah, I'm not sure I like the idea of trying to manually work around the DMA crash bug. And while I can't seem to track down any information on how the S-DD1 is addressed by the SNES, I imagine it uses a fixed source address for decompressed data, in which case you wouldn't be able to use block move anyway. An unrolled loop would work, but if the data source is one byte wide, you can't do an unrolled loop faster than block move unless your target is in the same page as the source, and isn't 5 KB of block move 3/4 of your active CPU time? Slow indeed.

Considering how scripted the game is, I'm wondering if a partly scheduled OBJ VRAM partitioning might make some sense. It sounds like you're dealing with very small chunks, which means a lot of overhead. But if you could use somewhat constant-size slots for certain objects, you could optionally use just a few transfers, or even just one, to load such an object. Any extra data required for an unusually large animation frame could be spilled to the general-purpose dynamic sprite area. This might be useful for maximizing bandwidth, particularly if the S-DD1 requires a bit more setup than plain ROM. Transferring a 70x80 explosion in 128-byte chunks seems unnecessarily fiddly...

Maybe it could be possible to have a simple defragmentation algorithm that would rearrange VRAM to carve object slots out of dynamic sprite areas as desired during lulls in the action, by moving miscellaneous active sprites elsewhere to clear the slot. This could allow object slots to be reversibly split into general-purpose sprite slots if necessary. Any object corresponding to a slot type with no free instances could simply go in as individual sprites, so if you fail to clear a slot in time you just burn a bit more VBlank on the object rather than glitching out or missing important object appearances or state change cues.

Am I making any sense? I kinda wasn't paying much attention during the dynamic animation engine discussions, because I don't think I need one for the game I'm working on...

...It's too bad the SNES can only display black during forced blank. Big explosions like shotgun blasts or the Slug's shells blank the screen white for a couple of frames, which could allow you to comfortably catch up with VRAM DMA if you could do VRAM DMA during a white screen. Though it now occurs to me that if you could force blank with HDMA and get VRAM to open up during HBlank, you could transfer a good bit of extra data with HDMA because a white screen doesn't need to display any sprites. Hmm... maybe such explosions are too rare and unpredictable to help much? At least you could clear a slot for the explosion graphic...

Re: How well can Metal Slug backgrounds be recreated with ti
by psycopathicteen on 2018-06-12 (#219761)

I think that would be possible. I could search for as many free slots in a row, and occasionally defrag whenever there is free DMA and VRAM left over.

Re: How well can Metal Slug backgrounds be recreated with ti
by 93143 on 2018-06-13 (#219770)

Bringing the threads of conversation together a bit: how much CPU time does your method take? Any idea how much this sort of thing would add?

...

Looking at the backgrounds for Mission 1, it seems that the use of colour is fairly modest; large areas could be done with no more than a single palette. However, it has become evident to me that there's a lot of checkerboard dither. This would have to be pretty carefully dealt with if one were to attempt to rescale the graphics horizontally. It may be possible to partially automate it...

I wonder if 8x8 attribute granularity (to partly make up for unaligned palettes in rescaled BG graphics) is worth the extra 2-3 KB of VRAM for the map data... my first instinct is that it's not.

Re: How well can Metal Slug backgrounds be recreated with ti
by Drew Sebastino on 2018-06-13 (#219772)

Quote:

I'm pretty sure it's a hypothetical at this point - maybe a team will come together around it someday, but I at least am certainly too busy right now. In any case I imagine Espozo would want to be involved; he started learning SNES dev with the idea of making this port himself.

Yeah, I would certainly be up for helping anyone if they were to attempt this. I've found out that I don't have near the perseverance to do something like this myself; I haven't programmed for the SNES at all since before the beginning of the year. Well, I found I'm never getting an Irem M92 with how prohibitively expensive they have become, so all my projects involving that are dead, so I have one less thing to distract myself with.

Quote:

Looking at the backgrounds for Mission 1, it seems that the use of colour is fairly modest; large areas could be done with no more than a single palette.

You'd be surprised though; I remember using PCX2SNES's limited screen tool and finding something like an average of six background palettes. The thing is, a lot of the palettes are identical except for five or so unique colors. Hypothetical or not, I still think you're insane for suggesting rescalling all the graphics. :lol:

Re: How well can Metal Slug backgrounds be recreated with ti
by 93143 on 2018-06-13 (#219794)

More insane than trying to port Metal Slug to the SNES in the first place? It's not like the graphics would have to be redrawn from scratch. With the proper tools up and running, the sprite graphics would just be a matter of light manual touch-ups. Backgrounds might be a bit more involved (they look really good even with fairly primitive rescaling, but you'd have to fiddle with palettes and checkerboard dither a bit), but it still doesn't seem out of proportion. Maybe because I haven't tried it seriously yet...

I really do think aspect ratio is important. Not so much the exact physical aspect ratio (which is difficult to figure out), but the size of the screen in game terms. For the port to be accurate, the physical aspect ratio should be about right, and you should be able to see the same amount of stuff, including BGs, and each element of the stuff you can see should take up the same fraction of the viewable area as it does in the Neo Geo version. This implies a scaling factor of 256/304 for all graphics (which actually implies a 67x80 large explosion; I don't believe I've mentioned that particular number yet).

Unless you trim the sides of the screen, but my understanding is that the Neo Geo's 320-dot active area was wider than standard, with the 304-dot area being pretty close to 4:3, so trimming the sides would be further from the physical aspect ratio and thus not desirable. On the other hand, if you trimmed the sides you might be able to get away with using just one tilemap per layer without having to use 16x16 tiles, which would give you 8x8 palette granularity, and you'd be able to get the full 20% size reduction for graphics... but the visual aspect ratio would be a bit off, and the resolution would be even lower... also, with 8x8 tiles you wouldn't be able to pack two horizontally-scrolling BGs into one tilemap... not to mention that you'd be perpetually tying up one window mask, leaving just one for anything else you might want to do...

You don't want to be getting shot from offscreen. Nobody likes that. Have you played the Mario Advance games? The smaller screen size does have a substantial effect; the gameplay suffers, and the gamefeel suffers. It's a constant reminder (along with the bad audio and sore hands) that what you're playing is a crunched-down portable version of the actual game.

Isn't the goal to produce the best possible port of Metal Slug? If it takes more work to get better accuracy, so be it. You gave up on rescaling when you were planning to actually do the whole thing yourself. With a team, there'd ideally be at least one person who'd rather spend time massaging pixel art than programming slope physics, so it could happen in parallel. And if it is just a hypothetical, like my port of BotW to the N64, then there's no reason to hold back because practicality isn't a consideration; clearly rescaling Metal Slug's graphics is not beyond human ability, because generating them from scratch wasn't.

Re: How well can Metal Slug backgrounds be recreated with ti
by tepples on 2018-06-13 (#219796)

One practical problem with a team is feeding and housing your team for the duration of development. This ultimately ends up leading to a requirement to find an agent for your team to negotiate with SNK.

Re: How well can Metal Slug backgrounds be recreated with ti
by rainwarrior on 2018-06-13 (#219804)

Well, a port of Metal Slug to the SNES probably would have had at least a million dollar development budget. Whether or not the graphics could theoretically be ported without sacrifice wouldn't have been an important question for such an endeavour, though. They would have altered the game to be practical enough to finish the project.

It's not really fair to compare to a commercial project, though. This is not a sane commercial undertaking. If you do it you'll do it because you're really interested in meeting this particular challenge. I don't think a lack of licensing from SNK is going to stop you.

Re: How well can Metal Slug backgrounds be recreated with ti
by psycopathicteen on 2018-06-13 (#219807)

93143 wrote:

Bringing the threads of conversation together a bit: how much CPU time does your method take? Any idea how much this sort of thing would add?

The last time I tested it, it was about 20 to 30 scanlines in the worst case scenario. However I made a bunch of tweeks to it since because it was spagetti code.

Re: How well can Metal Slug backgrounds be recreated with ti
by 93143 on 2018-06-14 (#219844)

rainwarrior wrote:

If you do it you'll do it because you're really interested in meeting this particular challenge. I don't think a lack of licensing from SNK is going to stop you.

Yeah, my idea of a "team" was less a bunch of guys in an office pulling a full-time salary while subsisting on pizza and Red Bull, and more a few like-minded hobbyists working in their spare time and somehow managing to harmoniously divide up the task over the internet. No schedule, no budget.

I'm not sure how demoscene teams manage themselves, but I'm pretty sure they don't pull full-time salaries either...

psycopathicteen wrote:

The last time I tested it, it was about 20 to 30 scanlines in the worst case scenario.

Not bad.

So I guess we're hoping that the original game was at least twice as inefficient as it could have been, ideally three times - given the difference between Metal Slug 2 and Metal Slug X, there's clearly some room for improvement...

Re: How well can Metal Slug backgrounds be recreated with ti
by psycopathicteen on 2018-06-14 (#219850)

The routine is still pretty long. This is how it looked a several months ago, viewtopic.php?f=12&t=10957&start=255 and I've been trying to squeeze the code down with macros so that it's less intimidating. But, I've also added a "single 32x32 sprite" and "single 16x16 sprite" mode so that single sprite objects don't need large data tables. In order to shrink data, I had to use more code.

Code:

animation:
-;
jsr do_animation
lda {next_slot}
bne -
lda {active_slot_pointer}
cmp {last_object_to_dma}
beq +
-;
jsr do_animation
lda {next_slot}
cmp {last_object_to_dma}
bne -
+;
rts

do_animation:
tcd
ldy {metasprite_request}
bne +            //no animation, if "metasprite_request" is blank
jsr clear_vram_slot
stz {frame_id}
rts
+;
lda {animation_update}      //sprite is animated if "metapsprite" is different from
bne +            //"metasprite_request" or "animation_update" is set
rts
+;
lda $000c,y
sta {vram_size}
clc
adc {total_dma_legnth}      //check if there is enough DMA time for sprite
cmp #$0081
bcc ++
lda {first_object_to_dma}
bne +
tdc
sta {first_object_to_dma}
+;
rts
+;
jsr clear_vram_slot      //clear previous animation frame
lda #$0002
trb {object_traits}
cmp {animation_update}      //if "animation_update" is 2, then frame is rotated 180 degrees
bne +
tsb {object_traits}
+;
stz {animation_update}
ldy {metasprite_request}
lda $000e,y
clc
adc {animation_index}
inc #2
sta {frame_id}
tax
lda.w {animation_copies},x
inc
sta.w {animation_copies},x
dec
beq +            //if animation_copies is not 0, then no further processing is needed
rts
+;
ldx #$ffff
lda $0008,y
sta {temp2}         //"temp2" is ROM bank
bpl +
jmp single_sprite
+;
cmp #$4000
bcc +
jmp single_small_sprite
+;

lda $000a,y         //find the ROM address of sprite graphics
asl #5            //ROM address = metasprite ROM address + (animation frame)*(metasprite ROM size)
sta {vram_width}
sep #$20
lda {animation_index}
lsr
sta $4202
lda $000c,y
sta $4203
rep #$20
lda $4216
asl #5
adc $0006,y
sta {temp3}         //"temp3" is ROM address

lda $0010,y
bpl +            //if $0010,y is $7fff or less, it is the metasprite data itself
tya            //if $0010,y is $8000 or more, it is the address pointing to metasprite data
clc
adc {animation_index}
tax
ldy $0010,x
+;
phd
lda #$0000
tcd
ldx #$ffff
-;
   lda $0010,y
   bne +
   jmp invalid_chr
   +;
   sty.b {temp5}
   lda $0012,y
   sta.b {temp_x}
   lda $0011,y
   and #$0070
   lsr #4
   sta.b {temp8}         //"temp8" counts down the horizontal sprite run
   lda $0018,y
   xba
   lsr #2
   adc.b {temp3}
-;
      sta.b {temp}            //"temp" is the ROM address of the sprite being added
      sta.b {temp9}            //"temp9" is the ROM address of the top sprite in a vertical run
      lda $0014,y
      sta.b {temp_y}
      lda $0011,y
      and #$000f
      sta.b {temp7}         //"temp7" counts down the vertical sprite run
      jmp find_vram_slot
find_vram_slot_done:
      ldy.b {temp5}         //this puts all the "OAM" information
      ora $0016,y
      sta {sprite_attributes},x
      lda.b {temp_y}
      sta {sprite_y},x
      clc
      adc.b {temp10}
      sta.b {temp_y}
      lda.b {temp_x}
      sta {sprite_x},x

      dec.b {temp7}         //decreases "temp 7" until all sprites
      bpl find_vram_slot      //in the vertical run are put on linked list
      dec.b {temp8}         //decreases "temp 8" until all sprites
      bmi +            //in the horizontal run are put on linked list
      clc
      adc.b {temp10}
      sta.b {temp_x}
      lda.b {temp10}
      asl #2
      adc.b {temp9}
      jmp -
+;
   stx.b {temp6}
   tya
   clc
   adc #$000a
   tay
   jmp --

macro find_slot(stack_index,stack,label) {
ldy {stack_index}
dey
dey
bmi {label}
txa
ldx {stack}-$a00000,y
sty {stack_index}
sta {next_sprite},x      //adds slot to linked list
lda x16_lut,x
ora #$4000
ldy {dma_updates}
clc
}

macro add_and_store_2x(a,b) {
sta {b},y
adc {a}
sta {b}+8,y
}

macro add_and_store_4x(a,b) {
add_and_store_2x({a},{b})
adc {a}
add_and_store_2x({a},{b}+16)
}

small_slot:         //this finds 16x16 VRAM slot
find_slot({small_slot_stack_index},{small_slot_stack},invalid_chr)
add_and_store_2x(#$0100,{dma_destination})
lda.b {temp}
add_and_store_2x({vram_width},{dma_address})
adc {vram_width}
sta.b {temp}
lda.b {temp2}
ora #$4000
sta {dma_bank},y
sta {dma_bank}+8,y
stz.b {temp4}
stz.w {sprite_size},x
lda #$0010
jmp +

invalid_chr:
   pld
done_with_animation_routine:
   txa
   ldx {frame_id}
   sta.w {animation_chr},x
   lda {vram_size}
   clc
   adc {total_dma_legnth}
   sta {total_dma_legnth}
   rts            //this is where the game exits the routine

find_vram_slot:
lda $0010,y
and #$0003
dec
beq small_slot
cmp #$0001
beq large_slot
repeat_slot:         //this finds repeat slots
ldy {repeat_slot_stack_index}
dey
dey
bmi invalid_chr
txa
ldx {repeat_slot_stack}-$a00000,y
sty {repeat_slot_stack_index}
sta {next_sprite},x      //puts it on linked list
lda.b {temp4}
ora #$0002
sta {sprite_size},x
lda.b {temp6}
jmp find_vram_slot_done

large_slot:         //finds open 32x32 VRAM slot
find_slot({large_slot_stack_index},{large_slot_stack},invalid_chr)
add_and_store_4x(#$0100,{dma_destination})
lda.b {temp}
add_and_store_4x({vram_width},{dma_address})
adc {vram_width}
sta.b {temp}
lda.b {temp2}
ora #$8000
sta {dma_bank},y
sta {dma_bank}+8,y
sta {dma_bank}+16,y
sta {dma_bank}+24,y
lda #$0001
sta.b {temp4}
sta {sprite_size},x
lda #$0020
+;
sta.b {temp10}
clc
adc.b {dma_updates}
sta.b {dma_updates}
txa
jmp find_vram_slot_done

x16_lut:
dw $0000,$0020,$0040,$0060,$0080,$00a0,$00c0,$00e0,$0110,$0120,$0140,$0160,$0180,$01a0,$01c0,$01e0
dw $0200,$0220,$0240,$0260,$0280,$02a0,$02c0,$02e0,$0310,$0320,$0340,$0360,$0380,$03a0,$03c0,$03e0
dw $0400,$0420,$0440,$0460,$0480,$04a0,$04c0,$04e0,$0510,$0520,$0540,$0560,$0580,$05a0,$05c0,$05e0
dw $0600,$0620,$0640,$0660,$0680,$06a0,$06c0,$06e0,$0710,$0720,$0740,$0760,$0780,$07a0,$07c0,$07e0
dw $0800,$0820,$0840,$0860,$0880,$08a0,$08c0,$08e0,$0910,$0920,$0940,$0960,$0980,$09a0,$09c0,$09e0
dw $0a00,$0a20,$0a40,$0a60,$0a80,$0aa0,$0ac0,$0ae0,$0b10,$0b20,$0b40,$0b60,$0b80,$0ba0,$0bc0,$0be0
dw $0c00,$0c20,$0c40,$0c60,$0c80,$0ca0,$0cc0,$0ce0,$0d10,$0d20,$0d40,$0d60,$0d80,$0da0,$0dc0,$0de0
dw $0e00,$0e20,$0e40,$0e60,$0e80,$0ea0,$0ec0,$0ee0,$0f10,$0f20,$0f40,$0f60,$0f80,$0fa0,$0fc0,$0fe0
dw $1000,$1020,$1040,$1060,$1080,$10a0,$10c0,$10e0,$1110,$1120,$1140,$1160,$1180,$11a0,$11c0,$11e0
dw $1200,$1220,$1240,$1260,$1280,$12a0,$12c0,$12e0,$1310,$1320,$1340,$1360,$1380,$13a0,$13c0,$13e0
dw $1400,$1420,$1440,$1460,$1480,$14a0,$14c0,$14e0,$1510,$1520,$1540,$1560,$1580,$15a0,$15c0,$15e0
dw $1600,$1620,$1640,$1660,$1680,$16a0,$16c0,$16e0,$1710,$1720,$1740,$1760,$1780,$17a0,$17c0,$17e0
dw $1800,$1820,$1840,$1860,$1880,$18a0,$18c0,$18e0,$1910,$1920,$1940,$1960,$1980,$19a0,$19c0,$19e0
dw $1a00,$1a20,$1a40,$1a60,$1a80,$1aa0,$1ac0,$1ae0,$1b10,$1b20,$1b40,$1b60,$1b80,$1ba0,$1bc0,$1be0
dw $1c00,$1c20,$1c40,$1c60,$1c80,$1ca0,$1cc0,$1ce0,$1d10,$1d20,$1d40,$1d60,$1d80,$1da0,$1dc0,$1de0
dw $1e00,$1e20,$1e40,$1e60,$1e80,$1ea0,$1ec0,$1ee0,$1f10,$1f20,$1f40,$1f60,$1f80,$1fa0,$1fc0,$1fe0

macro clear_slot(stack_index,stack) {
ldx {stack_index}
sta.w {stack},x
inx
inx
stx {stack_index}
lda {next_sprite}-$a00000,y
cmp #$ffff
bne -
rts
}

-;
rts
clear_vram_slot:   //this routine clears the VRAM slots of the previous animation frame
ldx {frame_id}
beq -
lda.w {animation_copies},x
beq -
dec
sta.w {animation_copies},x
bne -
lda.w {animation_chr},x
cmp #$ffff
beq -
-;
tay
ldx {sprite_size}-$a00000,y
beq clear_small_slot
dex
beq clear_large_slot
clear_slot({repeat_slot_stack_index},{repeat_slot_stack})
clear_small_slot:
clear_slot({small_slot_stack_index},{small_slot_stack})
clear_large_slot:
clear_slot({large_slot_stack_index},{large_slot_stack})

//////////////////////////////////////////////////////////////////////////////////
sram_bank_crossing:
lda {animation_index}
xba
and #$ff00
-;
cmp #$2000
bcc +
sbc #$2000
inc {temp2}
clc
bra -

single_sprite:
lda $0002,y
bmi sram_bank_crossing
lda {animation_index}
xba
and #$ff00
clc
+;
adc $0006,y
sta {temp3}         //"temp3" is ROM address
lda $0010,y
sta {temp5}
find_slot({large_slot_stack_index},{large_slot_stack},invalid_single_chr)
add_and_store_4x(#$0100,{dma_destination})
lda {temp3}
add_and_store_4x(#$0080,{dma_address})
lda {temp2}
sta {dma_bank},y
sta {dma_bank}+8,y
sta {dma_bank}+16,y
sta {dma_bank}+24,y
tya
clc
adc #$0020
sta {dma_updates}
lda #$0001
sta {sprite_size},x
lda #$fff0
-;
sta {sprite_y},x
sta {sprite_x},x
txa
ora {temp5}
sta {sprite_attributes},x
invalid_single_chr:
jmp done_with_animation_routine

single_small_sprite:
lda {animation_index}
xba
and #$ff00
lsr #2
clc
adc $0006,y
sta {temp3}         //"temp3" is ROM address
lda $0010,y
sta {temp5}         //finds open 32x32 VRAM slot
find_slot({small_slot_stack_index},{small_slot_stack},invalid_single_chr)
add_and_store_2x(#$0100,{dma_destination})
lda {temp3}
add_and_store_2x(#$0040,{dma_address})
lda {temp2}
sta {dma_bank},y
sta {dma_bank}+8,y
tya
clc
adc #$0010
sta {dma_updates}
stz.w {sprite_size},x
lda #$fff8
bra -

Re: How well can Metal Slug backgrounds be recreated with ti
by Drew Sebastino on 2018-06-15 (#219862)

Only 30 scanlines tops for finding vram for objects? If I'm interpreting that right, wow... You've already added so many features to your game engine that I don't think I should bother finishing mine. :lol:

I forgot, do you use ca65?

Re: How well can Metal Slug backgrounds be recreated with ti
by psycopathicteen on 2018-06-16 (#219893)

Just so you know, $a0 is now my default bank, because it is a mirror of bank $80, but with 8kB of SRAM. I did this to avoid register juggling.

Re: How well can Metal Slug backgrounds be recreated with ti
by Drew Sebastino on 2018-06-16 (#219905)

Oh, so it's pretty much always 3.56MHz; I know you're a great programmer, but less than 30 lines for that much work seemed insane.

I had Metal Slug in mind when designing it, but that dynamic palette changing idea could come in handy for just about any game with a fair level of verticality; I've been thinking about 4 player games on the SNES and how the players already eat up half of the sprite palettes.

Re: How well can Metal Slug backgrounds be recreated with ti
by lidnariq on 2018-06-16 (#219906)

Er. Pages $60-$7F in banks $80-$BF are still 2.7MHz timing... but usually RAM access speed doesn't add up to much, because so many cycles are spent loading instructions (using K bank) relative to I/O cycles (using B bank)

Re: How well can Metal Slug backgrounds be recreated with ti
by 93143 on 2018-06-16 (#219913)

Yeah, but most of $2000-$5FFF is fast, and large parts of it are unused. Any SRAM in that area could also be mapped into bank $00 for use with direct page and rewritable interrupt routines. All you need is the ability to wire up your own cartridge, or an emulator with manifest support.

How does using bank $A0 rather than $80 help avoid register juggling?

Is it really 20-30 lines for the whole frame, or is it 20-30 lines for one metasprite?

Re: How well can Metal Slug backgrounds be recreated with ti
by psycopathicteen on 2018-06-17 (#219921)

I don't have the tools to build a custom cartridge, let alone test it on one. That's why it's at $a0 instead of $80 or $00. It's funny how Nintendo never placed SRAM in the most optimal places.

It only takes approximately 30 lines because once it hits the max amount of DMA size, it ignores everything after it.

Re: How well can Metal Slug backgrounds be recreated with ti
by lidnariq on 2018-06-17 (#219923)

Unlike on the NES, where there would have been a clear advantage to overflowing regular code into save RAM, on the SNES it's most often exclusively for save data.

Also, decoding both $3xxx and $5xxx should have required another pin on the MAD-1, and couldn't be done with the 74'139 at all.

Re: How well can Metal Slug backgrounds be recreated with ti
by tepples on 2018-06-17 (#219924)

Perhaps Nintendo put SRAM on Super NES PCBs in out-of-the-way address spaces because it didn't expect SRAM to be used for anything but battery save. The less time the save chip spends enabled, the less likely it is to suffer data loss when losing power or otherwise running out of voltage spec.

Re: How well can Metal Slug backgrounds be recreated with ti
by psycopathicteen on 2018-06-17 (#219926)

Weren't there games that used non-battery SRAM?

Re: How well can Metal Slug backgrounds be recreated with ti
by lidnariq on 2018-06-17 (#219927)

Not significantly. Only GSU carts.

Re: How well can Metal Slug backgrounds be recreated with ti
by psycopathicteen on 2018-06-17 (#219929)

So you're telling me that if back in the day, if I tried publishing my game for Nintendo, they would put a lousy battery in the cart that will cause the game to malfunction after a while?

Re: How well can Metal Slug backgrounds be recreated with ti
by lidnariq on 2018-06-17 (#219930)

wtf?

No, what they would have told you was "You don't want to waste your money buying a small amount of extra RAM on top of the 128 KiB that are already in the console".

Historical production costs were huge, probably $10-$20 per unit, even in volume. Adding several more dollars on top of that wouldn't have been something you could have gotten anyone sane to finance.

Also, the battery's presence wouldn't cause the game to malfunction, it would just mean that if you were using cart SRAM for something other than just save data, the save data was more likely to get destroyed.

Re: How well can Metal Slug backgrounds be recreated with ti
by psycopathicteen on 2018-06-17 (#219931)

The primary reason for the SRAM, is for software sprite rotation, and not having to pad out levels to avoid software rotating sprites clashing with each other.

Re: How well can Metal Slug backgrounds be recreated with ti
by Drew Sebastino on 2018-06-17 (#219934)

So Alisha's Adventure uses the same 8KB of sram? If you ever wanted to have something tested on real hardware, I have an SD2SNES I can use.

Re: How well can Metal Slug backgrounds be recreated with ti
by psycopathicteen on 2018-06-17 (#219938)

It uses 128kB of SRAM, but it's split up into 8kB banks because it is using an existing cartridge memory layout. If you look carefully at the above code, I implemented an "animation mode" that is specifically for jumping across SRAM banks for rotating sprites.

Code:

sram_bank_crossing:
lda {animation_index}
xba
and #$ff00
-;
cmp #$2000
bcc +
sbc #$2000
inc {temp2}
clc
bra -

single_sprite:
lda $0002,y
bmi sram_bank_crossing
lda {animation_index}
xba
and #$ff00
clc
+;

Re: How well can Metal Slug backgrounds be recreated with ti
by Drew Sebastino on 2018-06-17 (#219941)

BSNES would have allowed you to put SRAM wherever you would have wanted, wouldn't it? I thought the roms had headers that define how much SRAM they need and where it is.

What did you need 128KB of SRAM for?

Re: How well can Metal Slug backgrounds be recreated with ti
by tepples on 2018-06-17 (#219942)

Caching software-rotated sprite cels, as an alternative to putting a GSU on the board to rotate them in real time like Yoshi's Island does.

Re: How well can Metal Slug backgrounds be recreated with ti
by 93143 on 2018-06-17 (#219943)

lidnariq wrote:

Unlike on the NES, where there would have been a clear advantage to overflowing regular code into save RAM, on the SNES it's most often exclusively for save data.

I have a reason. Speed.

My game uses an H-IRQ to pull off an elaborate raster effect, and it needs to run at 6 master cycles per byte to get everything done within the available window. Right now I use a trampoline in shadow RAM to get into a FastROM bank, but the IRQ plus a full slate of HDMA eats the bulk of the CPU time available during active display, and saving a JML per line plus two master clocks on every byte accessed on the stack might actually be worth it, even aside from the small speedup to regular code.

This is obviously an edge case, but it may actually be topical because there's a section in Mission 1 of Metal Slug that seems to want three 4bpp BG layers. And with the way it's arranged, it may be possible to use a combination of sprites and window masking to cover a scroll split executed with an H-IRQ. You might say it's overkill to add a custom SRAM configuration just to avoid having to reduce the bit depth of a BG layer, and you may be right. This particular section isn't even that busy, so it may very well not even be helpful (other than the small general speedup from having fast work RAM and a fast stack, and when porting Metal Slug to the SNES, any advantage is worth looking at).

...it may be possible to use sprites for the waterfall once the beam is below the HUD. There's not much else going on in that section, and the destructible part of the wooden structure is offscreen before the bulk of the waterfall comes into view. The ship and cliffs look like they'd reduce to multipalette 2bpp pretty well if you gave them a bit of HDMA and maybe some bridging sprites. This could be a good candidate for an OBSEL split, particularly if we decide to try to use real colour blending on the near-field waterfalls instead of checkerboard dither... it looks to me like the cliff on the left is out of view before the near waterfalls overlap any part of the far waterfalls, so the latter could be switched back to a 4bpp BG to permit layer blending.

I fear the water is going to have to slow down a bit. Even with tile reuse (and there are repeated elements in that far waterfall), there's just not enough bandwidth, or VRAM, to do 60 fps without butchering the graphics... wait, could it be possible to use colour math to combine a static 4bpp cliff+water background with mostly 2bpp animation? With enough tile reuse, the whole animation might fit into a useful amount of VRAM, or at least enough could be cached to leave the bulk of the bandwidth for the foreground. Still not hitting 60 fps, but might be faster than trying to use 4bpp for everything... One could also exploit the VRAM gate settings to overwrite half the bitplanes in a 4bpp tile set, but while that does reduce the bandwidth requirements, it also prevents compact tile caching/switching (which there may not be room for). Also, arranging tiles so they can be replaced selectively without a ton of overhead is harder when using 16x16 BG tiles. Using 8x8 tiles allows finer colour control but wastes VRAM on map data. Lots of work to figure out the best way to do this...

Re: How well can Metal Slug backgrounds be recreated with ti
by lidnariq on 2018-06-17 (#219944)

Sure. With 16-bit M/X, the effects of fast B bank seem to be very approximately equal to fast K bank. And with a standard LoROM cart, you can even use cart RAM with fast timings.

But with 8-bit M/X, the benefits of fast B bank are only roughly 1/3 ish of fast K bank. It's not clear whether that difference is big enough to matter.

Re: How well can Metal Slug backgrounds be recreated with ti
by Drew Sebastino on 2018-06-17 (#219945)

I thought I had shown in a picture that you can use BG3 for the middle layer in that scene in conjunction to a window layer, and you'd have enough color for everything but the rocky edge of the BG layer and a few highlights on the tree trunks that you could use a few 16x16 sprites for. By some stroke of luck, the layer doesn't actually extend up to where the status bar is.

Something that's a real pain though is that the wooden fortress is really two layers in of itself. Luckily, you can get by a lot of it by messing with tile priorities, but there are some parts you are going to need sprites for. I think both front and back parts use the same palette, so you might be able to get away with an Equinox style sprite masking system so sprites don't need to be there all the time (so you could potentially save vram space). There is so much layering in this scene that even the Neo Geo even displays sprite pixel per line dropout with the last explosion, but that's also because they weren't smart about lowering it. (The waterfall layer is presumably loaded in its entirety even while most of it is occluded).

Re: How well can Metal Slug backgrounds be recreated with ti
by 93143 on 2018-06-17 (#219963)

Espozo wrote:

I thought I had shown in a picture that you can use BG3 for the middle layer in that scene in conjunction to a window layer, and you'd have enough color for everything but the rocky edge of the BG layer and a few highlights on the tree trunks that you could use a few 16x16 sprites for.

I don't remember that, but it's been a while. I guess that's sorted, then, except for the wooden structure. I wonder if that would be a good candidate for OBSEL switching?

Man, there's really almost nothing happening once that wooden structure comes down. Couple of tanks, couple of soldiers, couple of POWs, then the boss. Also water. Water everywhere.

I wonder how effective the half-overwrite trick would be. It's kinda like 2bpp, but with per-pixel palette granularity, and you can overlap palettes. The far waterfall in particular looks like it might be well set up for it, but it's hard to know without trying...

Why does this video have such slow water? I actually went and looked up footage of somebody playing real hardware, hoping we got it wrong, but the water is fast on real hardware. This honestly looks better in some ways...

lidnariq wrote:

It's not clear whether that difference is big enough to matter.

If you're getting slowdown, it's almost certainly big enough to matter. And with Metal Slug you're probably getting slowdown. Whether it matters enough to justify the extra cartridge cost is another question. (With a modern MS port, I'd say yes, because the purpose is to test the limits of the console rather than to make money, and the market expectations of potential buyers, if any, are much more flexible. Even back in the day, shogi players were apparently willing to put up with a lot...)

For my game, the big reason for using fast SRAM would be to speed up my monster raster effect, as I said. Just the faster interrupt servicing and the elimination of the trampoline account for something like 15% more compute time for the main game loop. Whether I'll need it or not remains to be seen; most of the heavy lifting in my game is done by the GSU...

lidnariq wrote:

decoding both $3xxx and $5xxx should have required another pin on the MAD-1

Would it be any simpler to map SRAM to $2000-$3FFF and just ignore $21xx? (I'm guessing not, unless the CPU simply doesn't put $21xx accesses on the A bus at all.) How expensive would a custom address translator be?

Re: How well can Metal Slug backgrounds be recreated with ti
by Drew Sebastino on 2018-06-18 (#219965)

93143 wrote:

Why does this video have such slow water? I actually went and looked up footage of somebody playing real hardware, hoping we got it wrong, but the water is fast on real hardware. This honestly looks better in some ways...

The Neo Geo video hardware has a custom feature where it can automatically increment the graphics address for each 16x16 sprite block every frame until it reaches a defined point, and then starts over. That's why all the water operates at 60fps (even if, artistically, it really doesn't need to...).

Re: How well can Metal Slug backgrounds be recreated with ti
by lidnariq on 2018-06-18 (#219967)

93143 wrote:

Would it be any simpler to map SRAM to $2000-$3FFF and just ignore $21xx?

Nope. The only simple option is a 4K window, by decoding all of A12...A15.

Quote:

(I'm guessing not, unless the CPU simply doesn't put $21xx accesses on the A bus at all.)

When the S-CPU is accessing $21xx, both the A bus and PA bus have the same bottom 8 bits. If a cart device mapped something into $21xx according to the A bus (instead of a PA bus) the distinction would only be visible when trying to DMA to/from it. (It wouldn't work very well)

Edit: you might be able to do some cleverness with decoding $2000-$3FFF and /PARD ? Might have a problem with race conditions, though.

Quote:

How expensive would a custom address translator be?

Not bad. ROM-as-logic: SST39SF010 86¢/@26. GAL: ATF16V8 78¢/@26. GreenPak: 50¢/@100. Discretes: 74'1g86 + 74'138 21¢/@10 + 29¢@10

Re: How well can Metal Slug backgrounds be recreated with ti
by Señor Ventura on 2018-08-05 (#222697)

93143 wrote:

Sure, the Neo Geo had a 12 MHz 68000, and the game still had slowdown. But the game engine was not very efficient, and they had to rewrite it for Metal Slug X.

That is true, playing this game sometimes you have the sensation of it is executed by brute force.

Even in snes there are run and guns with heavy action, and almost without slowdowns. Starting from here surely a game seemed to the metal slug could be done with good animations (specially if it deactivates scanlines with the excuse of the image proportion).

All we know what that means that... better aspect ratio, and an additional extra bandwidth:

93143 wrote:

Also, the SNES CPU is perhaps close to twice as efficient per clock as the 68000. A homebrew port would be heavily optimized; I'd still expect slowdown, but it might not be all that horrible.

As i understand the situation, with an metal slug the priority is the animation and the size of the sprites.

Is a pending debt with the snes. Look at this image:

The SFA2 port has available more than 11KB per frame. Technically drawing two zangiefs with the same size and frame animations than the arcade is possible.

It could be some lack, for example if the two zangiefs lay to the ground at the same time, overloading the pixel fill rate, but there always are methods to solved that issues.

93143 wrote:

Note that the original game is 30 fps. This means that it has about twice as much going on as a hypothetical 60 fps game would be able to manage with the same CPU load, and comparisons with existing SNES software (which is almost all 60 fps) should take this into account.

And here another good point, yes.

You only have to look how well the contra 3 moves being a "first wave" game of the console... now multiplie that perfomance by 2, and the result would be monstrous.

Re: How well can Metal Slug backgrounds be recreated with ti
by 93143 on 2018-08-05 (#222719)

Señor Ventura wrote:

specially if it deactivates scanlines

Well, yes, that is the emergency fallback, but...

Quote:

with the excuse of the image proportion

...that's not a good excuse. Remember, SNES pixels aren't square; the image stretches to fill (approximately) a standard 4:3 TV screen. Neo Geo pixels aren't quite square either, but they're closer (actually, the display area was 320 wide, but most games didn't use the full width because the output had an unusually short HBlank period and the sides of the image were generally offscreen, kinda like the pointless overscan on the NES but sideways). The upshot is that a full 256x224 SNES screen is the approximate equivalent of the standard slightly edge-cropped 304x224 Neo Geo screen, which is what Metal Slug uses. The ideal situation for a port would be to only have to scale the graphics horizontally, retaining the 224-line display height and cramming all VRAM updates into the standard 38-line VBlank.

Quote:

As i understand the situation, with an metal slug the priority is the animation and the size of the sprites.

Yes, the DMA bandwidth is a potential issue. Still, with roughly 10 KB of tile data update capacity per "frame" (at 30 fps), you can do a lot more than with your typical 60 fps SNES game even without extending VBlank, and with prioritization of important information such as actor state changes, a bit of spillover now and then might not be the end of the world. If all else failed, you could take an extra frame to upload data before looping the game engine again, invoking slowdown for bandwidth reasons instead of CPU overload.

Quote:

The SFA2 port has available more than 11KB per frame. Technically drawing two zangiefs with the same size and frame animations than the arcade is possible.

If I recall correctly, with predictive animation it should usually be possible to do that with ordinary VBlank by double buffering and spreading the load across multiple frames. (I'm not sure if it would be better in a fighting game to occasionally delay animations if both players input bandwidth-heavy commands simultaneously, or to implement a global one-frame input delay.) Metal Slug has so much graphical data all displayed at once that double buffering is probably a bad idea, but unlike SFA2 it's not the end of the world if some animations happen a bit out of sync.

Re: How well can Metal Slug backgrounds be recreated with ti
by Drew Sebastino on 2018-08-05 (#222733)

All this talk about predictive animation and animation getting out of synch, but how jarring would it be to force VBlank down the screen for one frame, far enough to get all the graphics transfered? It couldn't look near as bad as the flickering tidal wave from Super Ghouls and Ghosts, at least...

Re: How well can Metal Slug backgrounds be recreated with ti
by 93143 on 2018-08-06 (#222776)

I don't know about that. It's a really obvious glitch, and as far as I'm aware it occurs nowhere in the commercial library (unlike, say, the cheese grater effect, which is acceptable because Konami did it first). I've only seen it in an early draft of psycopathicteen's Bad Apple video, and it looked pretty bad.

EDIT: Okay, maybe I was wrong. This video seems to suggest that it can happen even in Zelda 3. I honestly don't recall ever seeing it, but maybe that's because it's never big enough to make it past the bezel, which you really can't count on with Metal Slug...

If it were to happen only once every now and then, it might not be too noticeable, but with this game you've got a lot of objects that require continuous animation and stay on the screen for quite a while, so the effect would probably be almost continuous in spots. Much better to use real letterboxing if it comes to that.

In my mind, single-frame animation jitter would look better (you're going to need it anyway if you're spreading updates over multiple frames without double buffering), although I could be wrong and it should be tested at some point. Slowdown would surely be acceptable too, since players know what it is and are frankly expecting it. Furthermore, animation-induced slowdown wouldn't need to stack with processing-induced slowdown if the game were programmed right (ie: if the processing took too long and the animation engine was overloaded, you'd still only lose one frame), and I'd expect them to overlap a fair bit in real gameplay, so the impact could be minor.

On the flip side, extending VBlank situationally as you suggest might actually trigger slowdown, since it reduces your compute time for the frame, and if you're in a situation where you need it you could well be on the edge CPU-wise too. In that situation, you'd have been better off just delaying the next frame and taking one more VBlank to finish the updates. (To be fair, this is a bit of a corner case and doesn't prove much...)

...

It strikes me that predictive loading would be of limited utility in Metal Slug. If we aren't double buffering, any changes would become visible immediately, so all predictive loading would do is permit animation frames to be slid both forward and backward in time to take advantage of gaps in the DMA schedule. But you wouldn't want to load a cel early unless you knew that the next frame was going to be a doozy, and how would you know that before running the frame? I suppose you could simply project all current animations out to the next frame and see if they overload it, which would prevent all animations from running one frame early during sparse segments... But is the additional bandwidth leveling worth the CPU cost to do that? Especially considering that with 30 fps/no double buffering, half the animations are already running one (60 fps) frame early even without predictive loading?

It also occurs to me that it's probably acceptable to outright drop an intermediate animation frame, as long as it's already become obvious what the actor in question is doing. This could free up bandwidth for more important updates if things are really busy for multiple frames.

...

I sure do like typing...

Re: How well can Metal Slug backgrounds be recreated with ti
by Señor Ventura on 2018-08-06 (#222861)

93143 wrote:

...that's not a good excuse. Remember, SNES pixels aren't square; the image stretches to fill (approximately) a standard 4:3 TV screen. Neo Geo pixels aren't quite square either, but they're closer (actually, the display area was 320 wide, but most games didn't use the full width because the output had an unusually short HBlank period and the sides of the image were generally offscreen, kinda like the pointless overscan on the NES but sideways). The upshot is that a full 256x224 SNES screen is the approximate equivalent of the standard slightly edge-cropped 304x224 Neo Geo screen, which is what Metal Slug uses. The ideal situation for a port would be to only have to scale the graphics horizontally, retaining the 224-line display height and cramming all VRAM updates into the standard 38-line VBlank.

You mean reaching the original sprite sizes, stretching the image?... but then we loss definition.

I think that at 256x224 the image gains nothing without deactivated scanlines when you have to redraw graphics.

Look at this images, not having those black borders is useless, and you loose bandwidth:

93143 wrote:

Yes, the DMA bandwidth is a potential issue. Still, with roughly 10 KB of tile data update capacity per "frame" (at 30 fps), you can do a lot more than with your typical 60 fps SNES game even without extending VBlank, and with prioritization of important information such as actor state changes, a bit of spillover now and then might not be the end of the world. If all else failed, you could take an extra frame to upload data before looping the game engine again, invoking slowdown for bandwidth reasons instead of CPU overload.

I see an opportunity of having more than 20KB of tile animations per frame, deactivating scanlines, and functioning at 30fps.

Honestly, with 20KB you will animate all the snes can draw (128 sprites, 32 per line), due to it never will put on screen all what neo geo can do.

640 tiles per frame is terrifying, and i bet all you want that only a very few times you will need to come closer to that cipher. It is easyest than loss time managing double buffers, or whatever.

93143 wrote:

If I recall correctly, with predictive animation it should usually be possible to do that with ordinary VBlank by double buffering and spreading the load across multiple frames. (I'm not sure if it would be better in a fighting game to occasionally delay animations if both players input bandwidth-heavy commands simultaneously, or to implement a global one-frame input delay.) Metal Slug has so much graphical data all displayed at once that double buffering is probably a bad idea, but unlike SFA2 it's not the end of the world if some animations happen a bit out of sync.

How much it will costs to the cpu all that stuff about predictive animation, double buffers, etc?.

I'm still thinking that is better option the "brute force" option with 20KB per frame, and on top of that you save cpu (if you understand this expression xD).

Re: How well can Metal Slug backgrounds be recreated with ti
by 93143 on 2018-08-08 (#222992)

Señor Ventura wrote:

You mean reach the original sprite sizes, stretching the image?... but then we loss definition.

I mean this:

Attachment:

MS_NG_full.png [ 583.58 KiB | Viewed 8192 times ]

Attachment:

MS_SNES_full.png [ 633.34 KiB | Viewed 8192 times ]

Exactly the same screen size, with all graphics (other than HUD elements) rescaled to correct for the pixel aspect ratio change.

It may not be possible. But it's a goal to shoot for. (Also, you'd want some high-quality rescaling tools to minimize manual rework. These sprite sheets are not small.)

Quote:

I think that at 256x224 the image gains nothing without deactivated scanlines when you have to redraw graphics.

Your Final Fight example shows identical-sized graphics - no rescaling - with nothing at all of interest in the areas that got blacked out. (And it still looks nicer without the black bars when rescaled to 4:3.) Metal Slug is not like that. When five enemies with bazookas parachute in off the top of the screen, it's better to be able to see them right away.

But your earlier example was rescaled instead of just chopped. That way you can fit all the action in, but you absolutely do lose detail. Losing detail is inevitable because the SNES can't do 304-dot scanlines, and using 512-dot scanlines is impractical for this game. But keeping the detail loss to a minimum is (I think) a reasonable goal.

Letterboxing the screen is absolutely an option. A slight trim (8 pixels or so) might not even require graphics rescaling. But it does make the game less accurate and less impressive (and it makes the graphics more difficult to convert because if you have to rescale vertically too, you get attribute clash in both axes). If it's possible to do a good job without letterboxing, then it should be done without letterboxing.

The Street Fighter games on SNES suffered a fair bit of detail loss because they were redrawn for a shorter screen height. I'd rather not have to do that.

Quote:

I see an opportunity of having more than 20KB of tile animations per frame, deactivating scanlines, and functioning at 30fps.

Okay, yes, but do we need that? Animation delays, animation frameskipping, animation-induced slowdown - all of these combined might be less obvious and intrusive than letterboxing, and result in a better experience. If they do, then we don't need letterboxing. If they don't, then we may have to trim the screen.

Quote:

640 tiles per frame is terrifying, and i bet all you want that only a very few times you will need to come closer to that cipher.

The SNES can only address 16 KB of sprite data at a time, unless you change where it looks for sprite data partway down the screen, which is almost impossible to do intelligently except in very specific cases (mostly using sprites as a fake BG layer). Some of the animation in the game is 30 fps, but a lot of it isn't (and during the crazy sections where the most stuff is happening, the game tends to slow down anyway). It's entirely possible that 20 KB per frame is overkill for this game.

Quote:

How much it will costs to the cpu all that stuff about predictive animation, double buffers, etc?.

I don't think either predictive animation or double buffering is appropriate for this game. Double buffering eats VRAM that could be used for more sprites and/or BG tiles, and predictive animation doesn't work properly without double buffering.

As for what I have suggested - delaying unimportant animation cels, skipping them if they get delayed too much (and if the previous one wasn't skipped), slowing down to take an extra VBlank if important cels don't fit - I don't think it would be all that onerous. You'd just have to check every metasprite cel to see if it's important (you could probably just figure it out beforehand and store an importance bit in ROM), upgrade to "important" if the previous cel was skipped, and do the DMA allocation accordingly. A dynamic VRAM engine already exists (written by psycopathicteen) that takes 20-30 scanlines per frame to allocate 4 KB of sprite DMA; I'm not sure if it spills unallocated data to the next frame or just ignores it...

Now, a re-port of Street Fighter Alpha 2 might make good use of predictive animation and double buffering. It shouldn't be prohibitive CPU-wise; the Haunted games on NES (programmed by tepples) use these techniques in the context of a side-scrolling beat-em-up, and it seems to me that the extra CPU load associated with these techniques should scale more with the number of metasprites being animated than with the amount of graphics data involved.