Load URL image and memory usage?

0 favourites
  • 8 posts
From the Asset Store
Elevate your games with our AI Chatbot Integration! Seamlessly connect your Construct 3 projects with GPT-4 for dynamic,
  • 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.

  • 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.)

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • 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?

  • 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.

  • 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.

  • 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.

  • Interesting, thanks for the info, 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.

    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?

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)