Sorry your browser is not supported!

I started playing with dummy sprites and found a good use for them but I need to understand how it impacts memory?

Does anyone know if dummy sprites take Video memory?

If not how does it operate and how much memory does it take ?

Thanks for any help / answers

My experince is that it is the shapes that uses resources on dummy sprites.
In my platformer so did i use shapes for all the sprites first and got extreme impact on performance.
Then i optimized the use of shapes to under half an got an high performance boost.

Thanks Cliff that tip makes some sense.

Defining the shape would be the point where it takes screen realestate.

I'm trying to figure out if for instance a PNG with transparency is less memory use than a dummy sprite on top of a flat rendered background that has the image of a button on it?

I remember Paul writing once, that as soon as you call LoadImage, the image will be loaded and stored in GPU memory.

While I couldn't locate that specific post anymore, I did find a few other relevant posts that Paul has made. So I'll quote him for reference, with my notes below the quotes:

http://forum.thegamecreators.com/?m=forum_view&t=191961&b=41

Paul wrote:
"Cloning a sprite is the same as creating a new one, it just saves you having to copy the parameters. Sprites themselves don't use that much memory, the images assigned to them use far more so as long as they share images (and don't each load their own copy of the image) it should be fine."

NOTES:

The sprite data (including physics shapes) is not stored in GPU RAM. But of course general application performance will be effected when a large number of shapes is defined. (The shape data is likely recalculated when sprites containing shapes are rotated, scaled or moved, but this has no impact whatsoever on GPU memory usage.)

http://forum.thegamecreators.com/?m=forum_view&t=195060&b=41

Paul wrote:
"Currently all images are stored as 32bit RGBA images in GPU memory. Any images that aren't a power 2 in size are scaled up to the nearest power of 2 internally on mobile devices."

NOTES:

Wise usage of atlas images allows you to save GPU RAM.

Just as an example, assuming you had an image with dimensions 160x100, when loaded to GPU RAM, that image would take as much space as one that was 256x256 (the next largest dimensions for a power of 2 size image, able to contain the 160x100 image).

If you loaded TWO of those images, they would take up 2x256x256x4 (RGBA) bytes of GPU RAM. However, both images would fit on a single 256x256px atlas image (you can fit them within 256x256 in vertical alignment).

So, to repeat - in general, wise usage of Atlas images can save a lot of GPU RAM. Use them!

http://forum.thegamecreators.com/?m=forum_view&t=194664&b=41

Kamac wrote:
"Just a small counting:

One 32x32 RGBA (.png) image is 4096 bytes.
One MB is 1048576 bytes.

Then, if we have 60MB GPU memory free, we could store 15360 32x32 RGBA images."

Paul wrote:
"The math checks out. However, whilst the RAM may be hundreds on MB the graphics memory is usually smaller, for old iOS devices (e.g. 2nd gen iPod Touch) we recommend not using more than 24MB of graphics memory. Newer devices may get away with more."

NOTES:

The important thing to realize, here, is that the images will consume GPU memory, whether they contain transparency or not. The alpha channel is stored to GPU RAM along with the image data, even if it is just full of zeros! So, you do not save any GPU RAM by using transparency.

http://forum.thegamecreators.com/?m=forum_view&t=200996&b=41

Paul wrote:
"If you load too many images and overflow GPU memory then subsequent images may overwrite old ones or fail to load their pixels."

NOTES:

The important thing to note, here, is that there are currently NO commands to check the amount of GPU RAM used. Hopefully this will be fixed at some point... It should at least be simple to add an internal counter which shows how much image data has been copied to GPU RAM using LoadImage/GetImage (and other similar) commands.

But that would not reflect the total amount of GPU RAM used on a device... so, the usefulness of this solution would be limited,
but not non-existent.

http://forum.thegamecreators.com/?m=forum_view&t=195762&b=41

tessoft wrote:
"is there an internal image cache system - for example loading an image for one sprite is reused if I try to load the same image for again?"

Paul wrote:
"The image will be loaded 3 times. When we release image manipulation commands you would be able to modify the contents of an image ID so an image cache would be difficult to implement. "

NOTES:

Not much to add to that. Loading an image multiple times will consume as many times GPU memory, this should be obvious to everyone.

SUMMARY:

Dummy sprites do NOT consume GPU RAM at all - but there is an associated performance impact anyway, depending on what, and how, they are used.

Cheers,
AgentSam - the grumpy old software engineer

erebusman:



So as not to fail to answer your actual question, I'll give a specific answer to that question:

A dummy sprite will definately consume LESS memory (both GPU and main ram), than a loaded image for a button.

It is the image resources which consume the GPU RAM (and a minor amount of main ram for the associated data structure).

Cheers,
AgentSam

wow AgentSam that is probably the most commanding use of the forums I've ever seen. You glued a lot together to answer my question, I am extremely appreciative thank you!

Agreed, it's not often someone goes to such length. Nice work Sam!

There is some incredibly useful information here in this thread about image sizes - thanks very much.

I have a couple of questions - the answers may be obvious but I'm seeking clarification.

If you create a sprite from a 32x32 image and then resize the sprite to 80x80 does that result in the sprite image being resized to 128x128 in GPU RAM?

Also should the images be square, i.e. 32x32, 128x128, 256x256, etc? Would a 256x128 image be resized to 256x256?

No the amount of memory taken up by an image is not affected by the size of the sprite on screen.


No, if an image is power of two to start with it will not be padded out. 1, 2, 4, 8, 16, 32, 64, 128 etc sized images are not padded. An image 112x130 for example will be padded out to 128x256.

That's great - thanks baxslash! Just wanted to check...

So, which is correct? Sam's example essentially states that the image should be a square...


~Plystire

Images don't have to be square to be power of 2. Baxslash is (as always) correct in this instance.

Well, here's the fundamental question: "What is the power of two rule?"

And here's a fairly good article about out it, which gives you the answer:
Making better textures for games, 'power of two' and proper image dimensions

However, we still have no guarantees that the AppGameKit texture sizing algorithm is implemented exactly like this. So, excuse me while I remain skeptical until I see the source - or hear from Paul, who actually wrote it.

But, it's fairly safe to assume that the information given by Baxslash is correct.

A few links for more background information:
iPhone Development: OpenGL ES From the Ground Up, Part 6: Textures and Texture Mapping
Why do images for textures on the iPhone need to have power-of-two dimensions?

Cheers,
AgentSam

EDIT: Some hardware, texture format (especially PVRTC compression on iPhone), and OpenGL ES implementation combinations also require textures to be square.

I would not be surprised to hear that AppGameKit also scales textures to power of two squares on some hardware, but not all... So.. hello, I love you, won't you show me your source.

What baxslash says is accurate and for those who need proof (and have a T2 iOS setup) you can access the image pointer.

E.g


The commands of interest are ptr->GetTotalWidth() and ptr->GetTotalHeight. These functions return the padded sizes. On a Windows pc, these commands won't show any difference which is why one should try this method on iOS (maybe Android).

Picture attached.

Well, I don't have any proof and haven't access to tier 2 to check Hodgey's code but Paul did explain that images did not have to be square as I originally thought from the start. I only found out that the images were padded out to a none square power of two size fairly recently.

As usual though Agent Sam you have provided some very interesting links on the subject, thanks for the read!

If you have an atlas image sized 1024 x 1024, that contains all your game sprites, with a "subimages.txt" to go with it and load an image from the atlas image that is 56 x 86 (using LoadSubImage), does the sub image get resized to a power of 2 - in this case 64 x 128?

Hi Ian,

No, the subimage will not be resized, nor will a new image truly be created from it. It will be applied onto your sprite as a UV-texture, from the texture atlas, which remains at the said 1024x1024 size in your case.

The coordinates in the "subimages.txt" file can be thought of as UV-coordinates. (But few people think of these sprite bitmaps as textures, though that's what they really are, under the hood in the OpenGL pipeline.. Just like your sprites are actually a couple of polygons to make up a square box, on which that texture is applied.) But again, I guess I should keep this answer simple, few people need to care about what AppGameKit does under the hood, as long as your app works.

So, I hope the answer helps...

Cheers,
AgentSam

Hi AgentSam,

Yes, thank you. That is the answer I was looking for.

Thanks for the detailed response - it is interesting to know how it is handled "under the hood",

Ian