frame padding
by USC - IMD student 2 · in Torque Game Builder · 07/07/2009 (6:22 pm) · 3 replies
This article discusses how frame padding can make your images waste space if you aren't careful. I'd prefer to simply make my textures the right size to achieve efficiency:
http://tdn.garagegames.com/wiki/Torque_2D/ImageMap_Tutorial
...I understand that it's best to put all of your images into celled imagemaps even if you don't need those images grouped for any organizational reasons:
" try to keep as many frames in as few textures as possible. Also, grouping similar frames into the same texture can be of benefit."
I understand if you have a "FULL" imagemap with frame padding enabled, it should be, say, 254x254 and it will get bumped up to 256x256 (because of frame padding). If a 256x256 image got bumped to 258x258 for the same reason, it would take up much more memory as it would get stored as 512x512. Which is a waste.
It describes a (square) celled image map that is made up of 4 cells, each 128x128. With frame padding they end up being 130x130, which puts the overall dimension at 260x260, rather than an idea power of 2 like 256x256.
Is one solution to make the cells 126x126? and the overall image 252x252?
And say your image was 1024x128, make up of four 128 cells - four rows and one column. Would you need to make the cells 126x126 as well?
Thanks
http://tdn.garagegames.com/wiki/Torque_2D/ImageMap_Tutorial
...I understand that it's best to put all of your images into celled imagemaps even if you don't need those images grouped for any organizational reasons:
" try to keep as many frames in as few textures as possible. Also, grouping similar frames into the same texture can be of benefit."
I understand if you have a "FULL" imagemap with frame padding enabled, it should be, say, 254x254 and it will get bumped up to 256x256 (because of frame padding). If a 256x256 image got bumped to 258x258 for the same reason, it would take up much more memory as it would get stored as 512x512. Which is a waste.
It describes a (square) celled image map that is made up of 4 cells, each 128x128. With frame padding they end up being 130x130, which puts the overall dimension at 260x260, rather than an idea power of 2 like 256x256.
Is one solution to make the cells 126x126? and the overall image 252x252?
And say your image was 1024x128, make up of four 128 cells - four rows and one column. Would you need to make the cells 126x126 as well?
Thanks
About the author
#2
What exactly will this improve? Performance and/or RAM used?
(As my game is one enormous level I came up with a way to load an unload sprites' imagemaps based on a number of criteria, such as distance from the camera. It has cut the game's RAM use into a 1/3 and the game starts in 4 seconds, which is great, but I get a stutter here and there during gameplay. I think it's because by my I'm loading and unloading too frequently. So I have to find a balance and wonder if putting everything into cells will improve this performance situation).
Thanks
07/08/2009 (12:23 pm)
You're very clear, ty. Frame padding aside, I'm thinking about grouping all of my textures into celled imagemaps. So instead of having, say, 160 512x512 "full" imagemaps, I'll have 16 celled images at 2048x2048.What exactly will this improve? Performance and/or RAM used?
(As my game is one enormous level I came up with a way to load an unload sprites' imagemaps based on a number of criteria, such as distance from the camera. It has cut the game's RAM use into a 1/3 and the game starts in 4 seconds, which is great, but I get a stutter here and there during gameplay. I think it's because by my I'm loading and unloading too frequently. So I have to find a balance and wonder if putting everything into cells will improve this performance situation).
Thanks
#3
07/10/2009 (11:44 am)
Basically, having one large image map will improve two things: load times and texture thrashing. The problem with larger image maps is that older video cards don't support them. In this day and age, most video cards can do 2048x2048 but I wouldn't go larger than this. The image map reference guide referenced by the original poster states these concerns fairly well. I have quoted the relevant parts below:Quote:
*** TECHNICAL NOTE ***
When TGB uploads your imagery into the graphics card, it attempts to place them into the same graphics object called a "texture". Current graphics cards have limitations on the dimensions of these texture objects. Older cards can only handle 256 wide by 256 high textures whereas more modern cards can handle up to 4096 by 4096.
There's also a limitation (on some cards) that the dimensions of these texture-objects have to be a power-of-two in size e.g. 2,4,8,16,32,64,128,256,1024,2048,4096 etc.
Another complexity is that when TGB is rendering your sprites, it needs to tell the graphics card which texture it requires and the graphics-card selects the appropriate texture accordingly. This is no problem until TGB is selecting frame after frame which all reside on different textures. Because the graphics-card can only select one texture-object at a time, this can lead to the graphics-card swapping between different texture-objects continuously. This is commonly called "texture thrashing" and generally reduces performance, sometimes quite considerably. TGB objects such as the t2dTileLayer can cause this as it renders lots of tiles (therefore frames) during a single screen-update.
There are a couple of ways to counteract this problem; rendering the objects in a specific order so that all objects that use the same image are rendered together or alternatively, try to keep as many frames in as few textures as possible. Also, grouping similar frames into the same texture can be of benefit.
The good news is that TGB has an intelligent packing routine that will take the frames from your bitmap images that you supply, reorganize them internally to ensure that the texture card not only gets textures that it can handle but also to try to produce the best performance texture-objects that it can, totally automatically. Put another way; unlike the older versions of TGB (v1.0.2-), your input bitmap sizes DO NOT have to meet the above conditions. TGB will extract the frames and reorganize them into compatible textures. Feel free to create bitmaps that you're happy with!
The only exception is that no individual frame can be larger than that supported by the graphics hardware. In the future, even this condition may be removed with TGB automatically splitting-up the frame into manageable chunks allowing TGB to render it seamlessly albeit at a loss in performance.
More details on this later.
Torque Owner Matthew "Ashteth" Kee
Default Studio Name
// Pad frames if selected. for ( U32 n = 0; n < mTotalFrames; n++ ) { // Get Frame Reference. cFrameIn& frameIn = mVecFrameIn[n]; // Copy to Target Pixel Area. // NOTE:- We're actually not interested in the position in the Target pixel area! frameIn.mTargetPixelArea = frameIn.mOriginalPixelArea; // Padding Frames? if ( mFilterPad ) { // Yes, so pad by two pixels. frameIn.mTargetPixelArea.mWidth += 2; frameIn.mTargetPixelArea.mHeight += 2; } }So yes, if you have an imageMapDatablock with filterpad = true, it would be ideal to scale your images so that the overall bitmap size is a power of 2.
Yes
Well to start off with:
128 x 4 = 512
So four 128x128 cells would be better off as four 126x126 cells for an overall size of 504x126. So your math is wrong, but you got the right idea. Keep in mind that you only need filterpads if your frames touch the border of the cell. So for instance, I tend to use filterpads with map tiles but not with character sprites because there is no border contact in my char sprites.