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

Discussion and feedback on Construct 2

Post » Sat Dec 13, 2014 2:03 am

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
Last edited by Lunatrap on Sat Dec 13, 2014 8:23 pm, edited 1 time in total.
B
23
S
6
G
3
Posts: 316
Reputation: 3,461

Post » Sat Dec 13, 2014 2:25 am

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?
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
54
S
22
G
18
Posts: 2,123
Reputation: 17,150

Post » Sat Dec 13, 2014 3:48 pm

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 .
B
21
S
5
Posts: 196
Reputation: 1,984

Post » Sat Dec 13, 2014 8:23 pm

@ggibson1

i save the images as .bitmap and it matches the way the size increases in memory, maybe @Ashley could confrim it?
B
23
S
6
G
3
Posts: 316
Reputation: 3,461

Post » Sun Dec 14, 2014 12:00 am

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.
B
21
S
5
Posts: 196
Reputation: 1,984

Post » Sun Dec 14, 2014 12:27 am

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
Last edited by TiAm on Sun Dec 14, 2014 1:58 am, edited 1 time in total.
Don't lose your work. Backup your game with Dropbox.
B
44
S
10
G
10
Posts: 1,106
Reputation: 9,202

Post » Sun Dec 14, 2014 1:22 am

@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
B
23
S
6
G
3
Posts: 316
Reputation: 3,461

Post » Sun Dec 14, 2014 3:42 am

@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?
B
21
S
5
Posts: 196
Reputation: 1,984

Post » Sun Dec 14, 2014 8:08 am

@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
B
42
S
17
G
2
Posts: 850
Reputation: 6,209

Post » Sun Dec 14, 2014 2:08 pm

ggibson1 wrote:@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).
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
54
S
22
G
18
Posts: 2,123
Reputation: 17,150

Next

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 1 guest