Load URL image and memory usage?

Discussion and feedback on Construct 2

Post » Sun Jun 23, 2013 11:09 am

I am wondering about loading images by way of URL?

If I say
blockSprite.loadurlimage("tree.jpg")

then later on the same layout, same sprite
blockSprite.loadurlimage("rock.jpg")

what happens in the memory. Does C2 keep tree.jpg in ram, or does it clear?

The reason I ask is because I want to create a stream loaded world. Where I need to clear up images I don't want to use anymore. If C2 reserves the image space then I could end up using a vast amount of ram.
B
90
S
18
G
9
Posts: 2,455
Reputation: 15,013

Post » Sun Jun 23, 2013 1:07 pm

It releases tree.jpg from memory. There would be no point in keeping it!

I would still recommend you actually use images in objects rather than loading from URLs. Construct 2 can't preload images loaded from URLs, so you're liable to jank, and external images don't go through a number of great optimisations at export-time, some of which also save memory (e.g. spritesheeting, WebGL format tagging, etc.)Ashley2013-06-23 13:08:38
Scirra Founder
B
384
S
227
G
86
Posts: 24,144
Reputation: 190,816

Post » Sun Jun 23, 2013 10:19 pm

@Ashley - what's webgl format tagging? Does that mean sprites loaded from URL could perform worse than regular sprites aside from potentially using more memory?
Moderator
B
92
S
32
G
33
Posts: 3,005
Reputation: 27,582

Post » Mon Jun 24, 2013 2:33 pm

Ah yes, I forgot to mention this in the export-time optimisations tutorial, but it's not usually a significant saving. At export time, C2 counts the colors to determine if images will fit in to PNG-8 - but it also checks if the color values can be losslessly converted to a lower bit-depth texture in memory. We generally say all images are decompressed to 32-bit ARGB in memory, and this is indeed generally true. However if an image has a fully opaque alpha channel, it marks it as 24-bit RGB instead of 32-bit ARGB. This potentially allows the driver to save 25% of the memory by skipping the alpha. However I think most memory-constrained devices only support 16 or 32-bit textures, so in practice this will still turn in to a 32-bit texture in memory, and the driver will add an opaque alpha channel anyway.

It's also possible C2 will notice the image fits in to a 16-bit format, like 1-5-5-5 ARGB, or 5-6-5 RGB. This reduces the memory usage by half, and can actually render faster too (since less data is involved). However it's usually pretty rare for images to be able to be marked as a 16-bit format, since C2 only does so when it's truly lossless. A single pixel that can't be losslessly represented by, say, 5-bit values instead of 8-bit values, means the image must be encoded back to 32-bit ARGB - and this happens at the level of an entire spritesheet.

It's also possible to use compressed texture formats. These are like simple forms of JPEG with light compression ratios that are handled natively by the GPU, so the texture can actually be stored and directly rendered from a compressed format in memory. This can save loads of memory, but has several problems: there is still not one compressed texture format that all GPUs support; some formats are patented and we would not be able to ship encoders with Construct 2 games; most of them are lossy, so will slightly tarnish artwork (like low quality JPEG settings); some of them don't support alpha; and so on. It's possible one day these problems will be solved, and we'll add compressed texture support to exported projects, but again this will probably only happen to images in the project and not images loaded from a URL (since C2 can pre-process them).

A much more important saving is memory use: a 130x130 image loaded from a URL is not spritesheeted, so is probably placed on a power-of-two surface in memory at 256x256, using about 4x as much memory as necessary. If the image was in the project, it'd probably be spritesheeted in a way that wasted much less memory.

Construct 2 works really hard to both compress images to be as small as possible, and save as much memory as possible, using all sorts of tricks. Every time you load an image from a URL, you are missing all of those optimisations. If you make heavy use of loading images from URLs, you can end up with a significantly less efficient game than if you had everything imported to the project as object images.
Scirra Founder
B
384
S
227
G
86
Posts: 24,144
Reputation: 190,816

Post » Mon Jun 24, 2013 6:19 pm

That is a lot of excellent working behind the scenes in C2.

As a thought, basing the idea that "Sounds" does importing. Maybe a similar one for images. Where C2 imports images and packs them in the optimized spreetsheet. Yet use the custom naming convention to refer to them.

That way players can import by URL(or another) which will get the optimized version. Yet still offer the benefit of removing from memory if needed for streaming content. Streaming from local files not internet source.
B
90
S
18
G
9
Posts: 2,455
Reputation: 15,013

Post » Mon Jun 24, 2013 6:27 pm

The ability to export, and import sprites along with frames/ animations etc, as a single file/ object would go a long way to solving several issues.
Image ImageImage
B
167
S
49
G
155
Posts: 8,112
Reputation: 100,770

Post » Mon Jun 24, 2013 7:10 pm

Interesting, thanks for the info, Ashley.
Moderator
B
92
S
32
G
33
Posts: 3,005
Reputation: 27,582

Post » Fri Oct 18, 2013 7:54 pm

[QUOTE=Ashley]

It's also possible C2 will notice the image fits in to a 16-bit format, like 1-5-5-5 ARGB, or 5-6-5 RGB. This reduces the memory usage by half, and can actually render faster too (since less data is involved). However it's usually pretty rare for images to be able to be marked as a 16-bit format, since C2 only does so when it's truly lossless. A single pixel that can't be losslessly represented by, say, 5-bit values instead of 8-bit values, means the image must be encoded back to 32-bit ARGB - and this happens at the level of an entire spritesheet.

[/QUOTE]

Is it possible to design images to fit this format, say by using a Highcolor palette (pulled from wikipedia) when creating them, or converting to 16-bit.bmp (then back to jpg or png before import)?

Does this 16-bit memory savings only affect mobile devices?
B
7
S
1
G
1
Posts: 9
Reputation: 560


Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 5 guests