> The images go in to RAM and also in to VRAM (graphics card memory) if the rendering is hardware accelerated, which it usually is these days.

>

> They get decompressed to the same size as the image saved as a 32-bit bitmap, so yes, a 1000x1000 pixel image will always take about 4mb of memory alone. This isn't much when both your computer and graphics card have gigabytes of memory, but bear in mind 4mb is still a lot for a single image on mobile.

>

> The various compressed formats just package the data in to a smaller filesize. Compressed images cannot be drawn though, so it's normal to decompress the images in to memory whenever they are loaded.

>

> We have plans for a feature to load textures layout by layout (like Classic can) somewhere on the todo list, to save memory with very large projects.

>

And thank you again. Now it's cleared for me.

You should provide some images or a capx file at least to help Scirra resolve this matter.

The source images from your project are loaded into memory at start up.

Thank you. And what about the GPU memory? If I remember right, the images are all loaded there as bitmaps. In that case the source files load in with their full size?

I know that the images get loaded into the memory when they're displayed, but there's one part I'm not sure about:

When I use a high resolution sprite (for ex.: 2048x2048 px) and it get's displayed on a small screen (let's say for ex. on a 640x480 resolution) how much memory will it take up? Will it take up memory based on the source file (which is a high resolution image) or based on the downscaled image shown on screen?

Ashley this would be a pretty nasty bug to keep, and nobody should ever expect it to work like that, so it should really be at least documented as it is a complete false result.

It's the minimum that this should be in the documentation. Ashley You already made fixes that broke previous projects, I don't think that this should be an exception. I think the way these things should go is that if there's a bug to be fixed, it must be fixed. Don't leave known issues in the engine if you can help it. Please fix it.

That's a good idea! http://c2wiki.org now redirects to the Construct Wiki!

That is great

Congratulations Scirra

It's a good idea. Now it only needs a custom domain name, like c2wiki.net or something like that.

I guess you can. This is why they're called royalty free assets.

Have you tried using Ludei's own compiler and not the WebView?

Can you post those result on the bug report too?

Of course.

I tested it with a Samsung Galaxy Core Plus.

CPU: Dual-core 1,2 GHz ARM Cortex-A9

Decode times:

Firefox (OGG): 10.4s

Firefox (M4A): Before I updated Firefox, it did it in 20.38s, after the update it just crashes.

Chrome (OGG): 35.14s

Chrome (M4A): 26.55s