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, 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? 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?