You might have noticed that sometimes the Export project option takes a couple of minutes to complete, especially with larger projects. This is because Construct 2 is working hard to optimise your project, such as by reducing the download size and memory use as much as possible. This tutorial covers exactly what Construct 2 is doing on export, as well as how the export settings affect it, and finishes with some time-saving tips.
image deduplication
It's relatively common that projects contain duplicate images. For example you may have cloned an entire object type, or have an animation which re-uses the same frame in several places (e.g. in A B A C A D form). In this case there may be duplicate image files in the project folder.
To ensure previews are fast, duplicate images are not removed when previewing. However when exporting, Construct 2 looks for and removes duplicate images. This helps reduce the download size and memory use, since there's no point having identical images downloaded twice or loaded in to memory twice.
Note the size of images is still taken in to account: a 10x10 solid black image is considered different to a 11x11 solid black image, because it cannot be guaranteed that the project will look and behave identically if one was removed in favour of the other.
Due to engine limitations, there are two quirks in this process: firstly, images set to export in JPEG format are not deduplicated. Secondly images are not deduplicated between Sprite objects and other objects, since Sprite object images are spritesheeted and other objects are not. For example, a Sprite and a Tiled Background with identical images will still export two images, but two Sprites or two Tiled Backgrounds with identical images will only export one image. Usually these are both edge cases and it should not be a serious problem.
spritesheeting
Images are stored in the project in separate files. For example a Sprite with 10 animation frames will have 10 separate image files in the project folder. If animations were also exported like this, it could cause a few problems. Each image has to be downloaded separately in browser games, so this will mean 10 separate HTTP requests, and each HTTP request has a certain amount of extra overhead. Sprites often have animation frames with lots of similar parts, and this image data will be duplicated in each animation frame file. Also many systems will actually place images on a power-of-two size surface in memory (e.g. 128x128, 256x256, 512x512 etc). If all the images are 130x130, they may all actually be placed on separate 256x256 surfaces in memory, which makes it more likely the device will run out of memory.
Spritesheeting is the process of making a single large image with lots of animation frames on it. It solves all these problems: there are fewer HTTP requests in browser games; the PNG or JPEG compression can eliminate similar parts of the images across animation frames, making the download smaller; and Construct 2 always uses a power-of-two size sprite sheet, minimising any wasted memory. Here's what a spritesheet for the player's ship in Space Blaster looks like:
The combined spritesheets for this single object is a 300kb download and uses 2mb of memory. Without spritesheets the separate images would have been a 460kb download and used about 3mb of memory. So when applied to the entire project the savings can be quite significant.
Only Sprite objects get their images spritesheeted. This is mainly because when introducing the feature it could have broken third party plugins if it applied to other objects. However usually sprite animation frames make up the majority of a project's images, and also have the most redundancy between images, so it still makes very good savings. Construct 2 also does not mix two different objects on the same spritesheet; this is to make it more likely that the spritesheet is under 256 colors so it can use PNG-8 recompression, and also because typically there is usually little redundancy between different object types. (Recompression is described in more detail later on.)
The maximum size of a spritesheet is 2048x2048, since this is the maximum size that is widely supported by all hardware including mobile devices. Also, to avoid adjacent image's colors "bleeding" or "fringing" across to other frames, Construct 2 leaves a 1 pixel space between all frames on a spritesheet. This means it won't be able to fit four 128x128 images in a single 256x256 spritesheet, so try to ensure Sprite animation frames are just below a power-of-two size. The optimal size is two pixels less than a power-of-two size, e.g. 30x30, 126x126 or 254x254. (Note that Tiled Backgrounds on the other hand usually work best when exactly a power-of-two size.) You should also avoid using images over about 1000x1000 since they are very wasteful of device memory and will be awkward to fit in to spritesheets. (If Construct 2 cannot fit objects in to a spritesheet, it just exports them as individual images again, missing out on the benefits of spritesheeting.)
Construct 2's priority is to minimise memory use at runtime since that is usually the most significant problem, especially on mobile devices. To this end Construct 2 may opt to export two or three spritesheets of a smaller size if the images can fit. For example if the images fit across two or three 512x512 spritesheets, it will export that instead of a single 1024x1024 spritesheet, since it uses less memory. In some cases this can actually make the download slightly larger - there is a little bit more redundant image data saved. However it is usually more important to minimise memory use than save a few percent more on the download size.
The fact most images come out a power-of-two size has another benefit: some platforms, especially mobile ones, only support mipmapping with power-of-two size source images. Mipmapping is a rendering technique that basically enables high-quality downscaling, so objects resized small use real antialiasing to look better. This means after exporting some sprites may be able to resize smaller with better rendering quality on some platforms.
Note that if you set the Downscaling project property to 'High quality', images on spritesheets are always padded out to power-of-two sizes in order to mitigate two minor rendering issues. This negates the memory saving of spritesheets and so should not be used for no reason. For more information see Memory usage.
image recompression
Once Construct 2 has arranged all the images in to spritesheets, it then turns its attention to making the download size as small as possible. A number of tricks are used here. This is by far the most intensive step, and will usually take the majority of the export time.
First of all, Construct 2 respects the format you've set for any images in the Image Format dialog. All images are stored in the project as lossless PNG-32 files to prevent degradation while editing. If any images are set to use JPEG or PNG-8 format, they are recompressed at this point. This is a lossy (quality-degrading) operation if you have chosen JPEG, or chosen PNG-8 with an image using over 256 colors. Note this means there is no point importing JPEG or PNG-8 files to Construct 2 itself - Construct 2 will still simply convert any imported images to PNG-32, and wait until export to recompress it to your desired format set in the Image Format dialog. Therefore prevent unnecessary degradation of image quality, only ever import PNG-32 images to Construct 2, and set the intended format in the Image Format dialog.
Also note images are fully decompressed before rendering, so the file format (whether you choose PNG-32, PNG-8 or JPEG) will have no effect on runtime memory use - only the download size. However note it's often important to choose the JPEG format for any large, detailed scenery images, since it can make the download considerably smaller. Be warned that JPEG does not support transparency - if any parts of an image set to use JPEG are transparent, the transparent parts will turn opaque black.
By now Construct 2 has spritesheets for the entire project, all in the intended format. However it has more work to do! Next it counts how many colors are in any spritesheets that are still set to use PNG-32. If any of them come in under 256 colors, it recompresses them to PNG-8 automatically. This is lossless since the image can fit in 256 colors, and can often reduce the download size of that image to half or even a third. Often this means you get a huge download size reduction without even having to set PNG-8 in the Image Format dialog!
Any spritesheets that are over 256 colors are still processed - they're run through a tool called PNGCrush, which tries lots of different ways to compress the image, and picks whichever results in the smallest file size. This often gets an automatic and lossless 10-15% saving on the download size.
If you choose None for the PNG recompression setting on export, the color counting and PNGCrush steps are skipped. This can make exports very quick, but can also make the download size significantly larger. If you choose Brute, the PNGCrush step will spend considerably longer looking for the best compression method. This can make the export time take significantly longer, and usually only results in a few percent extra saving. So overall it's usually best to use Standard.
As you've learned, Construct 2's recompression of project images is relatively sophisticated. It is also totally lossless (preserving the image quality exactly) unless you explicitly set a lossy format in the Image Format dialog. As a result, usually there is nothing to be gained by using other image compression tools or services after export; you can trust Construct 2 to do an excellent job of compression by itself upon export. (And as before, there is nothing at all to be gained from using such tools when importing to the Construct 2 editor, since it immediately converts them to PNG-32 and you might have unnecessarily degraded the quality of your images.)
script minification
Finally, the resulting javascript code is minified using Google Closure Compiler's 'advanced' mode. This renames everything possible in the javascript code to use the shortest names possible, which makes the script smaller and quicker to download. It also has the nice side effect of making it incredibly difficult to reverse-engineer the exported project, since what were previously useful terms in the script become nonsense. It may also make the resulting Javascript slightly more efficient, since it employs some basic optimisations like inlining and removal of unused code.
In some rare cases, especially with third party plugins, minifying can cause bugs. The option to turn it off is mainly there as a diagnostic to help resolve such issues. It also requires Java to run the minifier. Therefore you should always enable minification, unless you are investigating a bug or don't happen to have Java installed (and it's worth installing just to get the benefits of minification).
Omission of audio files
To support audio playback on all platforms, it's necessary to dual-encode all sounds and music to both AAC and Ogg Vorbis, which the Import Audio dialog usually takes care of for you. If importing WAV files, Construct 2 also leaves these in your project in case you ever want to recompress them at a different quality level, or do some processing on the source audio.
The compressed AAC and Ogg Vorbis formats cover all platforms and are always considerably smaller than WAV, so the WAV files are never actually exported by Construct 2. Also Construct 2 will omit either the AAC or Ogg Vorbis files if the supported formats of the chosen platform is known in advance. For example packaged Chrome Web Store apps, packaged Firefox Marketplace apps and node-webkit apps are only ever run by Chrome or Firefox, both of which support Ogg Vorbis, so in this case the AAC files are skipped since they will never be used. Similarly if exporting to Windows 8 or Windows Phone 8, Ogg Vorbis files are skipped since the platform only supports AAC and the Ogg Vorbis files will never be used. On the other hand, exporting a HTML5 website, hosted app, or for the Scirra Arcade means both formats are necessary, since there isn't one format that covers all web browsers.
In short, you should never need to manually delete audio files before exporting your project - Construct 2 will always omit WAV files, and will omit one set of files automatically if it's possible.
Multi-core processing
The deduplication and recompression steps are processed on all available CPU cores to speed up the export. (Spritesheeting and some other export tasks are still single-threaded, but they are usually still very fast even for large projects.) For example on a quad-core machine Construct 2 will be able to recompress four images at a time in parallel, making that step four times faster. If you find exporting is taking a long time and you're looking to buy a new computer, find one with lots of CPU cores!
Conclusion
Construct 2 does a lot of work for you on export. The key lessons are:
- Don't worry about having duplicate images - they're automatically removed.
- The image format (e.g. PNG-8, PNG-32, JPEG) only affects the download size, not the runtime memory use.
- If possible make sprite images just under a power-of-two size, so they can pack in to spritesheets efficiently. However try to make Tiled Backgrounds exactly power-of-two sized.
- Don't import lossy image files (e.g. PNG-8 or JPEG) in to the Construct 2 editor. They are always stored as lossless PNG-32 until you export, at which point it respects what you've set in the Image Format dialog.
- Don't worry about the fact Construct 2 splits up spritesheets in to separate files when you import them to the editor. It will re-spritesheet them in a memory-efficient way when you export.
- Don't bother trying to run the exported image files through other compression tools or services. Construct 2 is probably already doing a very good job.
- Install Java so you can use script minification.
- Don't try to manually delete audio files before exporting. Construct 2 automatically removes any that are definitely not needed on export.
- If exporting is slow, try getting a machine with more CPU cores!
Knowing what Construct 2 does for you at export can help you work effectively with Construct 2 and avoid any unnecessary work.