nesdev.org

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 .

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.

It's not immediately obvious

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

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 .

TOUKO wrote:

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.

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.

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.

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.

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.

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

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.

TOUKO wrote:

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.

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.

We have the GBA version as an example

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

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.

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.

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 .

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 .

TOUKO wrote:

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.

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.

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

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

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.

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

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

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

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

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