• Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!

The relation between image sprites and Memory / size of games

S

sousou

Guest
Research: The relation between image sprites and Memory / size of games

Software verson:
I use GM8.0 to test but this feature is available to ALL version

Viewpoint: The memory occupy of the image sprites in GM only relevants to the dimension(width and height,eg 100X120.NOT sizes, eg 12KB) of these sprites , not any other elements such like size of images, compression algorithm or formats.

hello guys,:p
The memory occupy has always been a key point when making a game, an oversize memory occupy will result in CANNOT EXECUTE,EXECUTE ERROR,LOW FPS,SYSYTME DOWN and so on. The condition of different kinds of materials directly influences the size of memory occupy, in this case, I treat those materials( especially image sprites ) as important as coding.

1. CACHE of Sprite Editor in Gamemaker
We know that the memory occupy of current image will be shown on the lower right corner of the image editor window. At first let’s see with one image in basically SAME QUALITY, how the DIFFERENT CONTAINER(file format) of image influence the memory occupy.

For the convenience of comparison, I did copy 50 frames.

As shown blow, the sizes of the png, jpg, gif are 48k, 28k, 11k; all black color(Monorchrome) png size 6k, same with the dimension of testing sample; their memory occupy shows up totally the same in the image editor window:
图片1.png

Nearly same memory occupy in PC when running the game( a result by testing several times in post preload):
图片2.png

And the same result with other samples(bmp,tif,pgm etc.), just skip them.

Several days ago I discussed with my friend LuanLuan about the FPS of gamemaker’s game, he said “ It might because when we put these images in GM, GM will automatically change them into same container, so the memory occupy became just the same.”

About auto-transcoding:when using external image editor,we could find that GM creates a temporary files which named “ gm_ttt_+’number’ ” in cache path in disk C.

built-in image editor will not do the same thing, but the mechanism may be the same, like LuanLuan said that all changing into png automatically.

I was persuaded by that time, but next day I made another thought: what about different images but in the SAME DIMENSION? Or same content with DIFFERENT COLOURWAY?:rolleyes:

2. Low colourway to test the relation of memory occupy
The size of an image is decided by the number of pixels, color sensitivity and compression algorithm of different container and so on.

Images with different containers have different compression,and result in a huge difference in compression rate.

A image from my friend.(She allows me to do this)
QQ截图20170605123703.png
image 1: COLOURWAY:256bit,CONTAINER:gif 17.3KB / jpg 33.8KB / png 234KB(most PC game)
image 2: COLOURWAY:64bit,CONTAINER:gif 10.9KB / jpg 12.3KB / png 14.2KB(NDS, 3DS etc.)
image 3: COLOURWAY:32bit,CONTAINER:gif 7.93KB / jpg 9.28KB / png 11.1KB(PS GBA etc.)
image 4: COLOURWAY:16bit,CONTAINER:gif 5.1KB / jpg 6.8KB / png 8.47KB(SFC, MD etc.)
image 5: COLOURWAY:8bit,CONTAINER:gif 3.21KB / jpg 4.5KB / png 6.74KB(FC)
图片3.png
OK, also totally same.

what do you think?:eek:
 
Not sure exactly what your question is?

If you are asking if this is normal, I think this is the correct behaviour.

STEP 1: Import Image into GameMaker

When you import an image into GameMaker, it converts it to a 32bit colour image with no compression, similar to a BMP file, where each pixel takes up 4 bytes, 1 byte for each colour channel (Red, Green, Blue, and Alpha)

So lets check the calculations. The size of the image above is 155 x 171 pixels.

155 x 171 = 26505 pixels in the image.

Each pixel takes 4 bytes of memory:

26505 pixels x 4 bytes = 160,020 Total Bytes of memory = approx 106 KB (As you can see in your picture above)

STEP 2: Running the Game

When you build/run the game, GameMaker takes all your images and puts them onto Texture Pages.

You can set the size of the Texture Pages yourself. By default, the texture page size is 2048 x 2048 pixels I believe.

SO - Even if you have just one single sprite of 151 x 171 pixels, GameMaker will still create the 2048 x 2048 Texture Page for use in the game.

If all your images can fit on one Texture Page, and you add another image which can also fit on the same page, then the actual memory used by the game doesnt increase.

HOWEVER, once you have filled the first 2048 x 2048 texture page, and then you add another image, GameMaker will then create a Second Texture Page of size 2048 x 2048.

Then you will see an increase of memory usage (when running the game) by the size of the Texture Page.

Size of One Texture Page [2048x2048] = 2048 pixels x 2048 pixels x 4 bytes per pixel = 16MB

I don't remember if GameMaker then compresses the Texture Pages. If it did, you would get possibly ugly looking pixel graphics, so I don't think it does.
 

sylvain_l

Member
I don't remember if GameMaker then compresses the Texture Pages. If it did, you would get possibly ugly looking pixel graphics, so I don't think it does.
I'm not an expert of hardware tech, but as far as I understood it not only depends on the engine but the hardware&driver, with most last generation of graphic cards like nvidia pascal serie compression is handled. (ref: http://www.anandtech.com/show/10325/the-nvidia-geforce-gtx-1080-and-1070-founders-edition-review/8 ). I'm not sure what it involve exactly so :oops: :p
 
Very interesting article @sylvain_l , thanks for sharing. I didn't know about this colour delta compression. Good to know.

What I was actually thinking of in this case was more along the lines of S3 Texture Compression and PVRTC compression used for game textures to reduce the size - but also has a loss in quality which is especially noticeable on 2d pixel art games.
 
S

sousou

Guest
Very interesting article @sylvain_l , thanks for sharing. I didn't know about this colour delta compression. Good to know.

What I was actually thinking of in this case was more along the lines of S3 Texture Compression and PVRTC compression used for game textures to reduce the size - but also has a loss in quality which is especially noticeable on 2d pixel art games.
This is why there is a gap between the game screen and the poster
QQ截图20170611133323.png
QQ截图20170611133539.jpg

I'm not an expert of hardware tech, but as far as I understood it not only depends on the engine but the hardware&driver, with most last generation of graphic cards like nvidia pascal serie compression is handled. (ref: http://www.anandtech.com/show/10325/the-nvidia-geforce-gtx-1080-and-1070-founders-edition-review/8 ). I'm not sure what it involve exactly so :oops: :p
NICE yeah. I will think about that again:rolleyes:
 
Last edited by a moderator:
S

sousou

Guest
Not sure exactly what your question is?

If you are asking if this is normal, I think this is the correct behaviour.

STEP 1: Import Image into GameMaker

When you import an image into GameMaker, it converts it to a 32bit colour image with no compression, similar to a BMP file, where each pixel takes up 4 bytes, 1 byte for each colour channel (Red, Green, Blue, and Alpha)

So lets check the calculations. The size of the image above is 155 x 171 pixels.

155 x 171 = 26505 pixels in the image.

Each pixel takes 4 bytes of memory:

26505 pixels x 4 bytes = 160,020 Total Bytes of memory = approx 106 KB (As you can see in your picture above)

STEP 2: Running the Game

When you build/run the game, GameMaker takes all your images and puts them onto Texture Pages.

You can set the size of the Texture Pages yourself. By default, the texture page size is 2048 x 2048 pixels I believe.

SO - Even if you have just one single sprite of 151 x 171 pixels, GameMaker will still create the 2048 x 2048 Texture Page for use in the game.

If all your images can fit on one Texture Page, and you add another image which can also fit on the same page, then the actual memory used by the game doesnt increase.

HOWEVER, once you have filled the first 2048 x 2048 texture page, and then you add another image, GameMaker will then create a Second Texture Page of size 2048 x 2048.

Then you will see an increase of memory usage (when running the game) by the size of the Texture Page.

Size of One Texture Page [2048x2048] = 2048 pixels x 2048 pixels x 4 bytes per pixel = 16MB

I don't remember if GameMaker then compresses the Texture Pages. If it did, you would get possibly ugly looking pixel graphics, so I don't think it does.
get it thanks,
this is a discussion not question, I didn't find the right BBSSection, so post here
I just think about that the relation between image sprites and Memory - the title
I tried and tried to reduce memory about image sprite.
can not solve fundamental harm from large memory ,even use external resources or cleanmem.

What's the Texture Pages? I didn't understand this part:oops:
 
Last edited by a moderator:
I

icuurd12b42

Guest
Studio introduces texture pages which is a large image were all your sprites and backgrounds and fonts are combined into one... So long story short is does not matter the compression on the source image. these larger images/textures are png files, which again the file size does not matter since those images/textures are decompressed before going into memory...

See it in action here:

You mention GM8 which is so old it does not work on windows 10 mostly... but in any case in this older version each sprite was held in it's on smaller texture page, and again it did not matter if the source image was compressed or not, the resulting memory footprint would still be the width and height of the image times the number of bytes each pixel take,
 
Top