- Home /
Sprite sheet size and memory of machine
hi everyone ,currently I am working on 2d street fighting games for pc , I am confused for using sprite sheet or load individual sprite at a time , when I tried with sprite sheet I got memory problem cause sprite sheet size is become large (14136 x 632) with 30 frame's. and what is the relation of max sprite sheet size with pc video memory. thanks in advance.
Answer by citizen_rafiq · Sep 04, 2014 at 04:29 AM
I found my answer a long while ago , I am posting it if anyone need it.
Do not waste a single pixel memory if it is possible to use. If we believe on that only it is possible to give support in 256MB VRAM
PS: YOU can skip fist part here will be some early concept I believe that already you know.
Part 1:
Texture:
Raster Grid: Today’s display is raster based. A raster is a two dimensional grid so called picture elements. We can call it as pixels. The grid has a limited width and height, which we usually express as the number of pixels per row and per column, like we considered for this game 1920 x 1080
VRAM: The Graphics processor has access to a special memory area known as video memory or VRAM. Within VRAM there’s a reserved area for storing each pixel to be displayed on the screen. This area is usually called the frame buffer. A complete screen image is therefore called a frame. For each pixel in the display’s raster grid there’s a corresponding memory address in the frame buffer that holds the pixel’s color
Color: Physically, color is the reaction of our retina and visual cortex to electromagnetic waves. All a monitor does is emit specific electromagnetic waves for each pixel, which we experience as the color of each pixel. Every pixel on the screen is made up of three different fluorescent particles that will emit light with one of the colors red, green or blue.
Color Models: If we want colors other than the three base colors we can achieve that by mixing the base colors. Producing a new color from a specific mix called Color Model. There are many popular Color model RGB, YUV, CMYK. In most graphics programming APIs, the RGB color model is pretty much the standard.
Encoding Colors Digitally: How can we encode an RGB color triplet in computer memory? If any one have interest I will go with part 1 more (“_”)
Part2: When a game is mostly sprite animation based, there is two evil things comes in front
1.Amount of memory need; 2.Loading time of sprite or texture into computer memory. There is optimal solution for both but when you go for one other will show with max problem (‘_’).
1.Amount of memory need: Most game load all texture at once when a stage / level / round begins due to avoid loading time in the middle of game play. With a average machine loading filled_bule.png (a texture described bellow) will take 500 -1000 millesecond, in that time everything will hang, processor will release all other application even our game, first he will load that resource / texture then will come back to normal operation. (@ abdullah multi-thread comes in concern (‘_”)).
Loading time depends on directly computer hardware:
Texture: Exporting a texture (width x height) 5000x5000 pixels with regulation 72DPI filled_blue.png will take 123 KB in hard disk max due to compression did by Photoshop itself. But it’s actual size or it will achieve computer memory 5000*5000*3 = 75,000,000 Bytes = 71.52 MB of VRAM.
VRAM: VRAM is a dedicated memory area for storing graphics element it stays in Graphics card, like IntelHd 4000 graphics card have VRAM 512 MB. This day’s we see NVDIA GeForce or ATI Radeon has extensive VRAM memory support more then or equal 4GB.
With a 512 MB graphics card we can store Max 7 copies of filled_blue.png;
71.52MB (per filled_blue.png size) * 7 = 500.64 MB;
If we want to add more then 7 copies we will get memory overflow in other word crash.
In a round total memory need to load:
Amount of memory taken by HUD element: m1 MB
There will be n player in a round each player have l num of sprite sheet, each sprite sheet hold x size of VRAM memory:
Amount of memory taken by Players: n l x = m2 MB;
Amount of memory taken by Background: m3 MB.
So total size of texture in pixels = m1 + m2 + m3 = m MB
If m > VRAM_SIZE then memory overflow will be occur (crash).
Loading Time From analysis of other game I saw there is standard of giving min VRAM support 256 MB up cause lots of good graphics card have 256MB max support. If we go for 256 MB min we can load at a time max 3 copies filled_bule.png. But we need minimum 512 MB or max to load all sprites in a round, after calculation we found it. From where these memory will come. User machine have only 256 MB.
There are two solutions: 1. Load and unload memory at run time like player_1 want to give a supper load the super sprite, after when finished super, release the memory / unload the super sprite. 2. Give user minimum requirement of VRAM of what we need. Like we need 512 or max to load a level / round, there will be a restriction with out min 512 user cant play the game. (Personally every one will hate this option but if we go for first one there is N% work remain for graphics engine, 20 % work remain for game engine)
Delay: When we will give command our programe to load a sprite, he will hang every thing until he finished loading operation. Amount of delay totally depends on user hardware and size of texture / sprite sheet we are going to load . There is no way we can minimize with the help of programm.
Amound of delay: Amount of delay depends on the size of the texture / sprite sheet. If a machine have average hardware to deal with compressed texture. 5 copies of 5000x5000 texture’s will take more then 4 second.
Texture Compression: http://blog.wolfire.com/2009/01/dxtc-texture-compression/
AVOID: If we want to load and unload texture in game play, we should avoid sprite sheet, cause sprite sheet are become huge in size, instead of them we should deal with individual sprite / texture;
Like user give a super and it is 16-frame animation:
Each frame size 400x500 then total memory need to be load: 1600*2000*3 = 9600000Bytes = 9.15 MB If we going to load all 9.15 MB at first then play the animation. Game will hang for 300 millisecond before start the animation smoothly. I believe user won’t like much the delay he saw (in user view it’s called game is jerking or hang for a bit).
In other way we can divide amount of delay into 16 pieces and distribute it each frame.
In first frame we will load first texture (size: 400x500) to VRAM then render it will take time to load 300/16 = 19 millisecond max, in next frame first we will release the first frame then load 2’nd farm. …
The fantod: So we will not use sprite sheet any more, cause we want to load and unload each individual frame at runtime. Okay every thing is fine, until you read next line.
(Loading a texture need hardware operation)
When program access hardware rapidly multiple time with in a short time, hardware did not give ensure he will not failed. So if hardware failed program will get caught , may be there will be a crash.
So accessing hardware rapidly is very bad Idea.
Part3: How we will deal with Loading Time and Amount of memory need: I believe there are many ways we can deal with that: but I came up with a Idea after studying everythings.
If our total size of texture exceeds min VRAM size we gave to user (256 MB or 512 MB):
We will use both methods sprite sheet and individual frame:
Sprite Sheet: we will only use sprite sheet for those animation, which is very common and user gave commend in multiple time in game play time: like, stand animation, walk animation, all jump animation, crouch animation, dash animation …
Individual Frame: we will use individual frame method for those animations, which occur only few times in a round: like, Super1, Super2,
Part 4:
Max Sprite Sheet Size: it is in testing period need some more times for final result
Max sprite sheet size dose not depends on user VRAM, It is directly depends with the API we are using for accessing graphics hardware: open gal, DirectX
I tested in my machine I believe DirectX will did not give permission to load a texture that has size more then 7000x7000 or close
And it will not be a good Idea make a sprite sheet more then size 4000x4000
It is always a good Idea to use each pixel in a sprite sheet have, as possible as can.
Do not waste a single pixel memory if it is possible to use. If we believe on that only it is possible to give support in 256MB VRAM
If any one have question feel free to ask me or if any one want to know more further just let me know it.
Answer by Giantbean · Sep 06, 2019 at 03:16 PM
Sorry for the Necro but this may help another user down the road. I did not read your long post for the solution but I did a search in the post for power of two or 2x and saw no results so I will put a simple answer that your long answer likely addresses.
Any sprite or texture in Unity should be square. It should be power of two or 2x meaning 64x64 1028x1028 512x512 or any other base dimension with equal width and height.
If the file is not set with a power of two then Unity will fill in the blank space with empty pixel data. This means a sprite that is 10 x 64 will still be seen as a 64 x 64 in unity bloating a few kb to mb
Thus your original 14136 x 632 file is trying to become a 14136 x 14136 file and wasting memory. It also may not load at all due to DirectX texture size limitations. I would stay under 4K
Moral of the story, Keep it square.
I did read all of citizen_rafiq's post and I also managed to get the gist of it through the broken English: Your point about keeping it square is the first and most important thing to get right.
But if you want to make a 2D game with a lot of animation on today's hardware; It's worth noting that 2D games from the 90's didn't have a load time - they used RO$$anonymous$$ chips to store all the frames which could be accessed and drawn to the screen immediately, without any loading times. Nowadays we store the game on the HDD - this is much slower than a RO$$anonymous$$ chip and the images need to be loaded into the video card RA$$anonymous$$ before they are drawn to the screen, which is of limited size and may easily overflow with a game that uses 2D animation for everything, especially large sprites like a fighting game, and especially storing these at modern resolutions. If your game is loading and unloading these images during a fast and furious fight sequence, you're going to notice frame drops.
citizen_rafiq discusses using square sprite sheets for frequent animations that need to happen quickly, and then load complex animations frame by frame as individual images, for animations that don't need to happen often - like the "Super" move in a fighting game.