Questions about image memory

Hi Ashley,

Is there an updated blog post for REMEMBER NOT TO WASTE YOUR MEMORY from 2013? Does the power-of-two rule still apply to images today? Maybe the recommended 60-80 MB image memory is higher now? That's mainly what I would like to know. How far can I push the image memory, mostly for today's mobile devices.

In the section NO FRAMEWORK CAN HANDLE THAT, you do some pixel math, and I've tried that, but it's not adding up for me, and I'm not sure what I'm doing wrong.

I have a PNG image that is 650x1030. That's the size it is on the layout in C3 too. On disk it's 328 KB. If you do the math like you do in the blog post, 650 x 1030 x 4 = 2,678,000. So about 3 MB. But in the debug inspector, the image memory is 8.1 MB for some reason. Why so much more? If it involves the power-of-two then it would be around 16 MB? The size of the layout/viewport is 1280x960. As I scale up and down that viewport in the inspector, the image memory changes. To get the image memory down to 3 MB, I have to scale the viewport down to 80x60. So is the image memory dependent on how many pixels used in the viewport and not so much on the actual size of the image?

I'm confused. The reason I want to understand this is because it's frustrating to work on a game just to find the game is too image heavy and takes too long to load. Can you or anyone else help me better understand this and set me on the right path?

Given the blog post is about 10 years old now some parts are out of date.

It's hard to give a specific number for image memory as it depends on the devices you want to run it on and the amount of memory used for other parts of the game. As a guess I'd say 500mb image memory is probably OK on most devices these days, but you should test it yourself.

To be honest I'm not sure to what extent the power-of-two rule applies in terms of memory usage. Most modern GPUs support non-power-of-two textures, but that could be achieved while internally placing it on a power-of-two texture and pretending it's a smaller non-power-of-two texture, so it depends on internal details of the GPU and driver. It doesn't matter much with spritesheeting though, as all spritesheets are power-of-two sized.

Construct's image memory measurement is for the entire project and includes the overhead of the backbuffer, which is related to the viewport/window size. So you can't use that to measure the memory usage of a single image. Even then the image memory usage is based on a simple width x height x pixel size calculation, and cannot account for the GPU changing the memory representation internally (e.g. with padding, or in some cases lossless compression).

I forgot C3 creates its own spritesheets. I'll aim for around 500mb and just use Construct's image memory measurement as a guide. Thank you for taking time to answer my questions!

Try to use platform specific guidelines, image memory depends on format, compression and viewport settings. Experiment with resolutions and use debugging tools for optimization.

Note that the compression format of images (e.g. PNG vs JPEG) or the degree to which they are compressed has no effect on memory usage. See memory usage in the manual for more details.

Construct's image memory measurement includes the main render surface which can depend on the viewport size, but this is not a useful way to reduce memory usage, as the vast majority of a large game's image memory will be from object images, and changing the viewport size has no effect on that.

The discrepancy in reported image memory may be due to compression, mipmapping, or engine-specific optimizations. Modern GPUs handle non-power-of-two textures well, and memory is often influenced by viewport size and scaling. To reduce image memory, consider using compressed formats and optimizing resolutions.

This is, I'm afraid, in the context of Construct and this discussion, largely nonsense.

If you are using AI to generate replies, don't do that. It will generate things that sound plausible but are in fact completely irrelevant and misleading.

Would it be interesting/possible to allow compressed texture formats in video memory? Is the issue one of compatibility between different hardware support (since webgl/webgpu do support compression, if hw supports it.)

It's possible but comes with a lot of complications. Off the top of my head:

• Most texture compression formats are lossy, so they will affect how the artwork appears. Often this doesn't matter in 3D games, as perspective and texture styles make it less noticable.
• It looks like not all texture compression formats support alpha, or if they do it has to be via a separate texture, which is either a major limitation for 2D games (again not as relevant for 3D games) or a major complication for the engine
• The file size compression isn't very good, so you'd still want to export PNG/JPEG/WebP for smallest download size. That means compressing textures on-the-fly at runtime, which could substantially increase loading times (possibly with a slow/high quality to fast/low quality tradeoff)
• I think some texture compression formats are patented and shipping encoders could incur fees, much like some patent-encumbered video formats, which more or less rules out using them at all as it makes them uneconomical, unless there's some other encoding system used beforehand and you ship your game with pre-encoded textures, which would then have a much larger download size
• Not all platforms support the same compressed texture formats, so you might have to support encoding to multiple formats (making some of the previous points even worse)

I wouldn't be surprised if there were further complications I haven't realised yet. Compressed textures look like a feature best suited to large-scale 3D games with gigabyte-size downloads or dedicated installers. It seems to me like they are much less suitable for 2D indie games.

Meanwhile I've heard GPUs can use lossless texture compression automatically - but if they do that it's undetectable to the app and doesn't need anything special to be done. So sometimes that might help anyway. But Construct doesn't know about that - its texture memory usage is based basically on just the number of pixels in the image.

Thanks for the reply. I was wondering how it would work for web/html5 games. I definitely see it used in 3D or some 2D games focused on PC or console 'native' runtimes, though for larger titles with resources to do the compression for different platforms / GPUs.