2D fighting games [technical question].

[Kirian]

Recently, on another forum, the topic of Street Fighter [IV] came up. Again.
One of the participants claimed that 2D games will be unfeasible on the new consoles, due to graphical and size limitations. Several suggestions were made. Side-on camera with a 3D engine was suggested. Vector-drawn characters and animations was also suggested, but I think such games might look like 'The RumbleFish' if the programmers and artists are not given large amounts of time and space to carefully implement this system, but I am probably wrong.

Anyway, one chap suggested that a sprite-based system would have characters in HD [assume HD is used, no low resolution version] weighing in at 240MB or so. His calculations are below.
I think there is something wrong. Obviously, if compression techniques could reduce the size dramatically, it would be wonderful to know.
Personally, I think hashing the resolution up has played with the numbers, and that doubling the size for 60FPS play is wrong.
Anyway, thoughts, input, opinions and further ideas would be most welcome.
In advance:
Merci. Grazie. Danke. Thank you. Gracias. And so on...

His calculations, quoted directly:

A sprite rip from street fighter III is around 6.5 MB. It uses an 8bit colour table (256 colours).

The framerate is 30 fps.

I don’t know the exact resolution of the sprites, but we know the CPS III resolution: 512x384.

The resolution for HD is 1280x720 (and 1920x1080 for PS3).
1280x720x32 (colour depth)/8/ (bits to bytes)/1024 (bytes to Kbytes)=3600
512x384x8 (colour depth)/8/ (bits to bytes)/1024 (bytes to Kbytes)=192

So while we don’t know the sprite’s resolution we know how much more memory it will require for HD: 3600/192=18.75 times more.
18.75x6.5MB (sprite rip size)=121.875MB

But we want super fluid 60 fps animation, not 30 fps; so 121.875x2=243.75MB


Garrett addendum: We are talking simple upscaling of the hugely detailed SFIII and KoF sprites, possibly with even more fiddly drawing added.

[Charles]

First off, you never have an animation frame for every actual rendered frame in 2D animation. Almost everyone does it at a half rate or lower. I think the only animation I know of that uses a full natural framerate is Disney cartoons, which use a full 24FPS compared to standard animation (which I believe is 12). I seriously doubt SF3 used 30FPS for their sprites.

Plus, on top of that, you aren't going to measure based on the framerate, you are going to measure based on how many seconds of total animation there is for a character. And yes, you could still work texture compression in there on systems that support it, although I think most people wouldn't due simply to the fact that you could see all the little compression problems on an HD screen pretty easily.

[Reldan]

I think you assume that they are using optimum compression with the sprites in Street Fighter III. If the requirements of a game I was implementing only actively required 6.5 MB then I'd really doubt that memory or bandwidth would be a concern.

A situation where the uncompressed sprites take up 40x that would require a different approach but should be doable. It isn't like you actually need 60 unique sprites to have a second of smooth animation.

I mean, are you doubting what the Cell can do? We need some more discipline around here.

[Coca Cola Zero]

I don't know if it will be in the form of Street Fighter IV, but I wouldn't be surprised to see some developer make a SF-like game for next gen consoles that uses 3D models and animation data but uses some combination of shaders and render-to-texture and post processing effects to render everything with a 2D/high-def-but-retro-spritey look.

[mouselock]

I think you assume that they are using optimum compression with the sprites in Street Fighter III. If the requirements of a game I was implementing only actively required 6.5 MB then I'd really doubt that memory or bandwidth would be a concern.

A situation where the uncompressed sprites take up 40x that would require a different approach but should be doable. It isn't like you actually need 60 unique sprites to have a second of smooth animation.

I mean, are you doubting what the Cell can do? We need some more discipline around here.

Decompressing the sprites in video memory is the problem, nto how much space they take up compressed vs. uncompressed. I'm not sure how you could get away with decompression helping all that much if it's such a high character. Basically, you'd need to render the data as compressed and still be able to fit it in memory, unless there's a huge disparity between cache/processor memory and video memory. I don't believe that's a problem they're worried about.

[Kirian]

Are there any problems with the maths, such as the upscaling being disingenuous [qm]. Apparantly he has changed the colour palettet too.
More maths:

Now, in the calculations I did, I didn’t just boost the resolution. I increased the colour depth too. The SFIII sprites use 8 bit colour palettes, which I increased to 32 bit colour. I also doubled the frames drawn.

If we went for a straight conversion we would get:
512x384 (CPS III resolution)x12 (colour depth)/8 (bits to bytes)/1024 (bytes to kilobytes)=288

While the CPS III can display 4096 colours at once, each sprite has a 256 colour palette (to reduce memory requirements). But since we go for “straight” conversions I will use 12 bit colour for everything.

1280x720 (HD resolution)x32 (24 bit colour depth+8 bit alpha channel)/8 (bits to bytes)/1024 (bytes to kilobytes)=3600

3600/288=12.5 times more.

CPS III Ram
RAM : SIMMs on the left will physically hold 16M of data each (each has 8x 16M Flash ROMs, there's 4 SIMMs plugged in on this board). The SIMMs on the right will physically hold 8M each (there's 4 Flash ROMs on each board and there are 2 SIMMs plugged in)

I’ll assume that the SIMMs on the left are used for the graphics (that’s 64 MB). So 64x12.5=800MB! If we double the frames drawn we get 1.6GB!

But a straight conversion is wrong, since we don’t know how the Ram is used. So I used the size of sprite rips (from the DC version) which are about 6.5MB.

Anything else wrong[qm].

[mouselock]

Anything else wrong

Well, I find it unlikely that the sprites would scale to the WS proportions of HD. Things would look weird. So let's just double the sprite resolution. (We can only double, because 384x2=768 > 720 vertical resolution of HD. So we're already talking about sprites that are slightly bigger, but I'll assume that's okay.) For proper proportion we'd have to double the sprite's horizontal resolution too, so the sheer resolution scaling factor is not the pixel multiplication being used, but rather a factor of 4. (This should actually drive the memory down, since the thing that's killing the scaling is the 16:9 widescreen vs. a 4:3 SD screen aspect in the horizontal ratio.)

I'm also rather dubious that we'd actually get any use out of a full 8 bit transparency buffer considering current fighters apparently use a 0 bit transparency buffer. But it may well be that it's so inefficient to not use 32 bit wide data paths at this point that we have to take the extra loss. (And we don't really care about the on-disc space of a sprite since a DVD is plenty big in comparison.) So in a more apples-to-apples comparison I'd say we're looking at a factor of 4 (8->32 bit color) times another factor of 4 (doubling resolution) or 16 times as much memory to hold a sprite with the same 30 frames of animation.

It should probably be pointed out that 30 frames of animation is 60 fields per second, if interlaced, which is what a TV draws anyway. It's also more than enough to get fluid animation assuming your de-interlacing isn't horrible. Ultimately I'd think you could get 4x the character detail at full 32 bit color for a sprite with fluid animation at roughly 115MB/char (for the same characters that are currently 6.5MB). Again assuming we're not dealing with the vagaries of compression somewhere along the way.

Alternatively if we are compressing you could get the same character detail in high def just as easily. Getting more detail with compression is more problematic because if you're not careful more detail means more texture frequency which shows compression artifacts worse. Of course the inverse is true; if you don't have that many high frequency textures, the compression ratio of the characters will actually be better at HD. (Because you can tokenize more consecutive pixels in the same space, roughly.)

[Reldan]

I'm not arguing the math but I would definately consider 3 things:

A) As you pointed out, we don't know how the RAM is being used. Your figure of 1.6GB assumes that every single byte of RAM is beng used to concurrently store all the sprite data - I would highly doubt that to be the case.

B) Why on earth would you need to double the frames drawn? You'd just do it exactly the way its done now - showing the same sprite for multiple frames to obtain 60fps. There may be only 12 uniquely drawn sprites in a given second and it would still look like smooth animation.

C) If the game required 800 MB total to run everything in HD using a "straight" conversion, I would imagine they could easily halve that with compression and caching techniques. That should make it within the boundaries of modern hardware.

[Jonathan Blow]

There may be only 12 uniquely drawn sprites in a given second and it would still look like smooth animation.

Really, no it wouldn't.

[Aszurom]

So now it's even more unlikely that they'll remake "Rise of the Robots" for 360.

[shift6]

All of his math also makes other assumptions, such as that a complete, full-size sprite is redrawn for any given frame of animation. Sitting here elbow deep in a carton of cheesy gold fish, I thought to myself: wouldn't the trunk and head of the character be fairly static (mod rotation and translation)? and if so, why not just keep a couple of body sprites and redraw legs and arms into the video buffer most of the time? Shit even Primal Rage with it's insane amount of 2D animation had fairly static main bodies from what I remember.

[Fugitive]

I'm with CCZ in that they'd probably just go with 3D models rendered in real-time and flattened down to a 2D perspective. I'm sure some fans are so hardcore that the very thought of a 3D process being behind it offends every fiber of their being, but...so what.

[Brendan]

Is it just me, or does anyone think it strange that we have progressed so far that we are unable to do something that was possible 20 years ago? Take Target : Renegade for the 128k ZX Spectrum. Sure it only had a tiny palate but then again it only had a tiny fraction of the CPU power and RAM.

Sad really.

[Reldan]

Really, no it wouldn't.

If we're talking what passes for animation in a 2d sprite-based fighting game, then yes, 12 uniquely drawn sprites would easily look fine to cover a second's worth of animation. We're not talking a Pixar production here (although Pixar as well only renders 12 unique frames in a given second and people think it looks marvelous).

[Coca Cola Zero]

Is it just me, or does anyone think it strange that we have progressed so far that we are unable to do something that was possible 20 years ago? Take Target : Renegade for the 128k ZX Spectrum. Sure it only had a tiny palate but then again it only had a tiny fraction of the CPU power and RAM.

I wasn't aware Target : Renegade ran in HDTV resolutions, which is what introduces the problem here. And really it isn't an unsolvable problem. I'd solve it by using 3D data and using the vast, vast amounts of CPU and GPU power at my disposal to emulate a 2D look. But even if you didn't do that, most of this discussion is assuming you need every frame of animation for every on-screen character in vram at the same time, which you really don't, there's all sorts of predictive magic you could use to make it work along with texture paging systems, similar to what they are doing with "megatexturing" in QuakeWars but for 2D sprite animation.

[Kirian]

So, the consensus is that the maths is misleading, and a smooth, detailed 2D Street Fighter or King of Fighters is possible on the newer consoles in HD, but that an erzatz 2D look would be better.
Does anyone know what sort of resolution King of Fighters 2003 will display in, as it looks fantastic [qm].

Oh, and my thanks are extended.

[BaconTastesGood]

I'm also rather dubious that we'd actually get any use out of a full 8 bit transparency buffer considering current fighters apparently use a 0 bit transparency buffer.

Properly feathered/blended sprite edges vs. the background are pretty important to avoid the jaggy pixely look (unless you're using FSAA).

My first thought is that you'd use, say, 15fps animation and then lerp between them using some type of image warp (paper mario style).

[Jonathan Blow]

If we're talking what passes for animation in a 2d sprite-based fighting game, then yes, 12 uniquely drawn sprites would easily look fine to cover a second's worth of animation. We're not talking a Pixar production here (although Pixar as well only renders 12 unique frames in a given second and people think it looks marvelous).

The problem is that you are blending it with things that are much smoother. For example, particle effects, or when the camera pans, etc.

If you want to get a feeling for what this would be like, go back and play GLQuake. It'll be running at like 100fps, but the character models only update at 10fps (because they are pre-defined frames' worth of vertex positions). It is disorienting as hell. Back when Quake was being made, the actual game didn't run much faster than 10fps on most peoples' machines, so it was fine. But now... yech.

In a Pixar movie, they don't render half the frame at 12fps and half at 24fps. (And even if they did, it still wouldn't be a good analogy, because a Pixar film is full of animation tricks like stretch and motion blur that you most likely would not be able to have in the 2D sprite case).

So I am agreeing with Mr. Bacon that some kind of image warping scheme would be gainfully employed here.

[BaconTastesGood]

If you want to get a feeling for what this would be like, go back and play GLQuake. It'll be running at like 100fps, but the character models only update at 10fps (because they are pre-defined frames' worth of vertex positions).

Yep. And with Quake2 this was fixed (or at least, hacked around) by adding vertex lerping. So...do the same thing with sprites.

You could do a lot of pretty killer 2D post-process in conjunction with the image warping to make a pretty interesting looking 2D fighter.

[mouselock]

Properly feathered/blended sprite edges vs. the background are pretty important to avoid the jaggy pixely look (unless you're using FSAA).

Or higher resolution is. Which, y'know, you have on an HD TV. I don't recall SF III looking bad with basically a one bit alpha mask (unless I'm missing something about how a palettized 8-bit sprite works). Increasing the resolution certainly isn't going to make things more jaggy.

[BaconTastesGood]

Or higher resolution is. Which, y'know, you have on an HD TV. I don't recall SF III looking bad with basically a one bit alpha mask (unless I'm missing something about how a palettized 8-bit sprite works). Increasing the resolution certainly isn't going to make things more jaggy.

What matters is pixel density. HD is nice -- until you're running it on a 60" screen, which isn't going to give you the same pixel density you'd get running HD on a 24" widescreen.

Anti-aliasing still matters.

[ElGuapo]

I just had a vision of a sweet 2D fighting game that had graphics, including the fluidity of motion and animation, right out of Spirited Away.

Awesome.

[Reldan]

The problem is that you are blending it with things that are much smoother. For example, particle effects, or when the camera pans, etc.

If you want to get a feeling for what this would be like, go back and play GLQuake. It'll be running at like 100fps, but the character models only update at 10fps (because they are pre-defined frames' worth of vertex positions). It is disorienting as hell. Back when Quake was being made, the actual game didn't run much faster than 10fps on most peoples' machines, so it was fine. But now... yech.

In a Pixar movie, they don't render half the frame at 12fps and half at 24fps. (And even if they did, it still wouldn't be a good analogy, because a Pixar film is full of animation tricks like stretch and motion blur that you most likely would not be able to have in the 2D sprite case).

So I am agreeing with Mr. Bacon that some kind of image warping scheme would be gainfully employed here.

Thank you, I understand what you mean much better now.

The most visually impressive 2d sprite fighting game I've seen is probably Guilty Gear XX Slash. The animation has always looked very fluid to me. Does anybody have a rough idea on average how many unique sprites they use to pull off animating a character in this game?

[shift6]

I'd solve it by using 3D data and using the vast, vast amounts of CPU and GPU power at my disposal to emulate a 2D look.
Is this idea funny to anyone else? Here we finally have really powerful GPUs and CPUs and alot of memory, and we're having a genuine, serious discussion about how to get good 2D animation out of it. :)

[Unicorn McGriddle]

Why not? The screen's a 2D surface. Guilty Gear is beautiful.