Maybe, you still remember that I said not to use too many sprites in your project, or if you need to use an image repeatedly, then it's better to use a Tiled background object instead, because Construct 2 counts it as one object. Another thing you must keep in mind is you shouldn't use image files that are extremely big or detailed in your game. If you're a designer and want to use an HD image for your level, just know that it won't work, especially on a mobile.

The reason is a bit technical, but let me try to explain. Images are made up of pixels, so an image of 1920 x 1080 pixels will consist of 2073600 pixels. Each pixel takes up 4 bytes in the memory for red, green, blue, and alpha values. To find out the memory space used by this image, we only need to do some simple math: 2073600 x 4 = 8294400 bytes, or about 8 megabytes.

Many mobile devices don't support images whose size is not a power of two, such as 32 x 32, 64 x 64, 128 x 128, and so on. Images that are not the size of a power of two will be placed in a memory block big enough to contain them. In the case of our HD image file, it will be placed in a memory block of size 2048 x 2048; this means our 8 MB file will use 16 MB of memory.

Maybe you're wondering, where's the problem when today's computers have more than 4 GB of memory? Desktop computers often have video memory / VRAM for rendering, and for maximum performance, all images must fit into it. If the system only has 256 MB of VRAM, you can only put 32 of your HD images there, and this is assuming that you have access to all the VRAM. The operating system will use some of the VRAM as well as other applications, so most of the time, you can't use all the VRAM, and don't forget that you'll also use sprites other than the HD images.

This is even more of a concern on mobile devices, since most mobile devices don't have VRAM and use system memory for everything. It is possible that a mobile device has about 100 MB of free memory available. Assuming that your game will use half of the available memory, which is 50 MB, and your HD image uses up 16 MB of memory, you'll only have room for two images. Not so many, huh?

Let me tell you a little secret: no one creates a game level with a lot of big images/sprites, not me and not any other game developer. You can't make a fast game with big backgrounds like that. What you can do, instead, is to use the Tiled Background object to repeatedly use a sprite without a performance hit and use several other sprites to add up the variations. You can also rotate and scale the objects to make your level less repetitive.

The next screenshot is an example of how you can use a lot of smaller sprites to create a level. One advantage of doing it this way is that you can reuse them to make another level without more work from your artist. Another plus point is that you can have your programmer create a custom-level editor specifically for your game, and the designer can use these sprites to create a level, while the programmer and artist are busy with their work; it's a productivity boost!

The following screenshot shows an example of a level that consists of several small objects, with some of these objects circled:

Another good point when crafting your level this way is that you can add this to your gameplay mechanic. Maybe you can push the boxes, or a bomb could blast the cliff; it depends on your creativity.

In Construct 2, textures are loaded per layout, which means that it will load all the textures that a layout will use before starting. This is to make the game run faster, because loading the texture while playing might cause the game to pause a bit. When switching to another layout, Construct 2 will remove all the textures that are not used by the next layout and load the next layout's textures.

This means that the peak memory usage of your game is a result of the layout with the most images, not the total number of images used in the game. This allows you to have a set of sprites for a forest level, another set for a mountain level, and a different set for a lava level.

Each pixel on mobile devices can only draw three times per frame while maintaining 60 FPS; this means that you can only use three images of the size of the screen to keep the 60 FPS performance. I mentioned at the beginning of this chapter that an image also includes transparent pixels, so if you have an image that has a lot of transparent part in it, you should consider cropping this image into several smaller parts to avoid getting a performance hit.

The GPU processes an image regardless of its color and alpha values' composition; this means that the transparent parts of an image are also rendered. This is a hardware limitation, and there's nothing Construct 2, or any other framework, can do to avoid this. The solution is to use a lot of smaller images rather than one big image, because rendering a lot of images is easier than drawing a big image in one operation.