Is there anyway to predict the size of a PNG file on memory?

hi i would like to know if there is a way to predict the size of a PNG image when is loaded to the GPU?

i mean, this have happened many times, where a graphic we make, is too big and we need to go back and optimize it, but is there any way to predict the size?

for example

we made a big smoke effect sprite with 1 animation

on creation 1.7 mb on memory 15 mb

and we made a sprite smaller but with 8 animations

on creation 1.62 mb on memory 5 mb

i heard that one way to optimize is to always try and keep the images to 16x16, 32x32, 64x64 in those kind of intervals so they will fit better in the spritsheet on export.

any more ways to optimize PNG image size in the GPU¿

im also curious on the format is mentions here that is supossed to be superior to PNG

http://mainroach.blogspot.com/2014/03/t ... droid.html

well, in memory, the image is not compressed (so no compressing format will save you), in memory, I think they take (Width*Height*4) Bytes upped to the just above power of two

if width is 50, height is 100, you should have 50*100*4=20 000 Bytes = 20 kB (1 kB is 1 000 B, however some prefer talking in kiB where 1kiB = 1024 B, some computer OS and some people do not respect the norm and say 1kB=1024B, but I will respect the norm).

the just above power of two of 20 000 B is=32 768 B = 32.768 kB = 32kiB

Can someone confirm that?

I would think saving the image as a bmp file should show you what size it will be in memory since uncompressed images are bitmaps .

ggibson1

i save the images as .bitmap and it matches the way the size increases in memory, maybe Ashley could confrim it?

I figured that would be the case because in the 90s I made an image file format and wrote software that drew directly onto video cards... what I learned was that compression only applies to the files saved on disk.

Raster image types jpeg, png, pcx, etc all get turned into bitmaps in memory because that allows the fastest image manipulation even though it eats up more space.

I think one other consideration is what has been mentioned on these forums several times... images get padded with extra transparent pixels to make the images "power of two" e.g. 64x64 or 256x256 which means the size will be increased even more than just the plain png saved as a bitmap.

Actually, going with images that are an exact power of 2 (32x32, 128x128, etc) can mess you up if you don't build in dead space, because you may end up having to use high downsampling to avoid frame bleed. This can lead to a bunch of wasted memory.

EDIT: Actually, there is a bit about this in the online manual, but not the offline. Here are some links:

spritesheet-padding-bug-power-of-two-size-images_t118151

https://www.scirra.com/construct2/releases/r169

https://www.scirra.com/manual/183/memory-usage

TiAm

oh! wow!

i dont know why did not see that before, i have spent hour in the manuals and tutorials and i naver saw that! thansk XDDD

TiAm

That is good info.

The point I was trying to make however was that padding is being done in the sprite sheets.

The images in my game are not power of two and they have padding added to them since I am using high quality downscaling.

I do not know if this padding ever actually ends up in the video cards memory or not... is the entire sprite sheet loaded or are the individual images cut back out at run time and put into the video memory?

ggibson1 the images are the power of two when on the gfx card if they didnt dot that some cards wouldn't be able to use them and making them power of two make it easier for the gfx card

TiAm

That is good info.

The point I was trying to make however was that padding is being done in the sprite sheets.

The images in my game are not power of two and they have padding added to them since I am using high quality downscaling.

I do not know if this padding ever actually ends up in the video cards memory or not... is the entire sprite sheet loaded or are the individual images cut back out at run time and put into the video memory?

AFAIK, the spritesheets are loaded in memory (that is the whole point, they take less space in memory because of being loaded together like that as the adding to the next power of two will be done to the ensemble of them), with high quality downscaling however, they will take more space in the spritesheets and so more memory (which is why you should not use it unless specific graphical issues, tiam link talks about that I think), as basically it negates the point of using spritesheets (maybe not on the download size aspect, but in memory, it negates it completely).

I only use medium downscaling, have not had the need for high, which can cause a lot of problems with bloated memory usage.

Also, it's correct that the final image within the GPU's memory is an uncompressed format. The texture size is always a power of 2. Even a thin line of 400 x 1 pixel becomes a texture of 512 x 512 pixels.

The texture size is W x H x 4.

A 512^2 texture is therefore 1MB.

1024^2 texture is 4MB.

2048^2 texture is 16MB.

Most GPUs (ever since OpenGL 1.3 and Dx6!) these days do support compressed texture formats (S3TC etc) which saves a lot of memory use, but to use, game engines have to support it.

The texture size is always a power of 2. Even a thin line of 400 x 1 pixel becomes a texture of 512 x 512 pixels.

That's not quite right. Yes, on older graphics cards the texture size is padded to a power of two. But they are not forced squared. So, in your example, the 400x1 pixel line would become a 512x1 texture.

For older graphics cards, 32x64, 128x8, 16x1024 are all valid formats that won't be padded, but taken as is. (Just a few examples)

Modern graphics cards don't have any of these restrictions anymore. They deal with non-power-of-two textures natively, and graphic languages like OpenGL (which WebGL is based on) also support NPOT textures. WebGL's only limitation is that mipmapping and wrapping is not supported for NPOT textures. (See https://www.khronos.org/webgl/wiki/WebGL_and_OpenGL_Differences#Non-Power_of_Two_Texture_Support)

Most GPUs (ever since OpenGL 1.3 and Dx6!) these days do support compressed texture formats (S3TC etc) which saves a lot of memory use, but to use, game engines have to support it.

It looks like WebGL supports compressed textures, but not on mobile (where it would be the most useful, IMO). I guess even desktop support would be good, but it looks like the desktop implementation is a bit shaky too.

Memory usage describes how to calculate the memory use for an individual image, but remember spritesheeting and power-of-two padding will make it vary on export.

[quote:3flus19s]i heard that one way to optimize is to always try and keep the images to 16x16, 32x32, 64x64 in those kind of intervals so they will fit better in the spritsheet on export.

That's actually the worst size for sprites, since sprite animation frames go on a power-of-two sprite sheet with an extra 1px border added around every frame. So the ideal size is two pixels less than a power-of-two size, e.g. 14x14, 30x30, 62x62 etc. In fact I'd recommend just totally ignoring the power of two sizes and using whatever size you like and letting C2 spritesheet it on export. More info in Construct 2's export-time optimisations.

> The texture size is always a power of 2. Even a thin line of 400 x 1 pixel becomes a texture of 512 x 512 pixels.

>

That's not quite right. Yes, on older graphics cards the texture size is padded to a power of two. But they are not forced squared. So, in your example, the 400x1 pixel line would become a 512x1 texture.

For older graphics cards, 32x64, 128x8, 16x1024 are all valid formats that won't be padded, but taken as is. (Just a few examples)

Modern graphics cards don't have any of these restrictions anymore. They deal with non-power-of-two textures natively, and graphic languages like OpenGL (which WebGL is based on) also support NPOT textures. WebGL's only limitation is that mipmapping and wrapping is not supported for NPOT textures. (See https://www.khronos.org/webgl/wiki/WebGL_and_OpenGL_Differences#Non-Power_of_Two_Texture_Support)

This is all true, except not in the case of Construct 2.

Construct 2 will export your sprites to fit into the smallest power of 2 spritesheet that gets loaded into memory as a texture.

There is also no usage of compressed texture so that even large black areas take up the memory budget. I understand the constraints, mobile hardware differ greatly, thus the base needs to be covered.

Until it changes, devs need to be careful not to underestimate how much memory is actually used even for simple sprites and thus with any large project intended for mobiles, this needs to be taken into account during game design. Making a PC game offers a lot more freedom due to most PCs having 2gb vram, and many systems that use integrated GPUs like Intel HD3000/4000 etc, have a lot more due to using system ram as vram.