Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

What would be a good way to save memory to achieve an effect like this one? http://www.youtube.com/watch?v=K89LkvL9JZ0

Sonic 2 Bonus Stage

We're using pre-rendered 3D.

I'm asking this because this naive approach of just rendering all frames and putting them into a single file (sprite sheet) is producing a gigantic file, would we have to manage this loading creating multiple files?

If it helps, we are using Flex SDK.

share|improve this question
    
If you're concerned about memory, measure some numbers, and then profile. Don't assume you have a problem if you don't. –  ashes999 May 2 '12 at 17:12
    
Already did. With just turning left we're using 39 MBs. Using a rough calculation our game is going to take about 200 MBs to just have this background effect, surely most computer can handle it, but we are thinking in porting it to mobiles later, and that use of memory is prohibitive. –  user9471 May 2 '12 at 17:15
    
I suspect they used a pseudo 3D technique similar to what is described here. –  NoobsArePeople2 May 2 '12 at 21:57

1 Answer 1

up vote 5 down vote accepted

I dont know how technically Sonic 2 bonus stages are done, they could be computed by the cpu/special custom chip (and thus realtime) or totally precalculated and stored inside cartridge (like a very low resolution movie).

If you are using same color range, resolution and low framerate as sonic example you give, you should be able to get really lower than those 200MBs.

Here is what you could do to help to reduce the size:

  • reduce color palette size as much as possible (eg: to 8 bit) (i dont know if its possible in Flex)

  • use vertical/horizontal symmetry to only store the half/quarter.

  • If you look closely at the first animation you provided (the straight tube) : only light yellow parts change, blue/dark yellow regions are static. To show the animation, you could use more than one layer : one that is static, one that is animated, on the top of the first one (this one will compress very well since it contains lot of transparent pixels)

Of course if your animation is running at 30 fps, and contains complex details (eg : not using flat shaded, but textured polygons) it won't help. Maybe you should give a little more information about animation you want to store ?

It your animation looks like a movie (like those laserdisc racing games in the 80's) you should check if its possible to store your animation as a H.264 file movie and play it inside Flex (dont know very well that platform so i dont know if its possible).


EDIT : I recently had a chance to take a look at a Sonic 2 disassembly.

Here is how special stage is done :

  • there is no realtime rendering, everything has been precalculated and is stored in ROM
  • it run at a very low frame rate : around 8 frames per second
  • the internal resolution of each frame is 128x112 (when in game, it is played double size (256x224)). that's why you have vertical black borders when playing special stage (megadrive resolution is 320x224).
  • it use a 8 colors palette (3 shades of blue, 4 shades of yellow and one transparent color) this mean a single pixel can be stored in only 3 bits.
  • some frames are re-used in a single animation. an animation is stored as an array of frames indexes. eg for turning : 0, 1, 0, 1, 2, 3, 4, 5, 4, 5, 6.
  • it use horizontal flipping for left animations (eg : left turn animation is just a h-flip of right turn)
  • each frame is compressed. compression scheme is unknow (RLE maybe?) but it must use a very simple algorithm to allow megadrive to decompress frames on the fly. there is not enough RAM to store all frames uncompressed.

some stats for special stage :

  • there is 56 frames in total.
  • there is only a few animations : slope up, straight, slope down, curve right, begin curve right. during special stage, the game then play theses in a predefined sequence eg : straight, curve right, straight, curve right (h-flipped), straight, slope up, straight, slope down, etc...
  • all frames (when compressed) take only 72.3 KB (around 1500 bytes per frame). this is pretty small compared to size of ROM (which is 1 MB)
share|improve this answer
    
Really nice trick this one of reflection. –  user9471 May 2 '12 at 17:57
    
I'll try using your tips to see if we can solve our problem –  user9471 May 2 '12 at 19:46

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.