1. Hey! Guest! The 35th GMC Jam will take place between November 28th, 12:00 UTC - December 2nd, 12:00 UTC. Why not join in! Click here to find out more!
    Dismiss Notice

The relation between image sprites and Memory / size of games

Discussion in 'Programming' started by sousou, Jun 5, 2017.

  1. sousou

    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:

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

    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)
    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)
    OK, also totally same.

    what do you think?:eek:
  2. IndianaBones

    IndianaBones Member

    Jul 5, 2016
    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.
    Guest likes this.
  3. sylvain_l

    sylvain_l Member

    Sep 18, 2016
    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
    sousou and IndianaBones like this.
  4. IndianaBones

    IndianaBones Member

    Jul 5, 2016
    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.
  5. sousou

    sousou Guest

    This is why there is a gap between the game screen and the poster

    NICE yeah. I will think about that again:rolleyes:
    Last edited by a moderator: Jun 11, 2017
  6. sousou

    sousou Guest

    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: Jun 11, 2017
  7. icuurd12b42

    icuurd12b42 TMC Founder GMC Elder

    Apr 22, 2016
    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,

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice