Could C2 Use PNG-8 instead of PNG-32

0 favourites
  • 4 posts
From the Asset Store
94 Inside buildings views - Isometric view - PNG transparent - 2048x2048
  • Not sure if Ashley or someone else in the forum could shed some light on this for me, but I was wondering if it were at all possible to just use the sprites as PNG-8's instead of converting them to PNG-32's? My game is pretty animation intensive and I've noticed that 116 megs of memory is used just for the player character while the download size for the entire game is only 6 megs.

    Not sure if its possible or could be a feature in Construct 3. Any explanation is appreciated.


  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • In the image editor there's a button on the toolbar where you can specify the "export file format" where png-8 is one of the options. As far as actual memory usage by your game, it doesn't matter what file format is used because when an image is loaded it's loaded as a uncompressed 32bit image in video memory.

    The best that could be done if the game designer was happy about a loss of color depth would be for c2 to use compressed textures in webgl. The issue is support of it. According to the stats here:

    The most supported texture compression format is s3tc and even then it's only supported by about 75% of devices.

    s3tc gives a 4:1 compression at the loss of the amount of colors. ... Comparison

  • rojohound Thanks for the reply. I knew about the export of PNG-8s. I was just curious about the use of them at runtime. I'm just starting to sweat about my memory usage. I'd love to know what the average memory usage the C2 user has. I've definitely had to get smarter about my asset creation.

  • Construct 2 automatically detects images which can be losslessly converted to PNG-8 and converts them on export. See Construct 2's export-time optimisations. However as R0J0 says, this has no effect on memory use, only download size.

    WebGL texture compression is tricky: it is usually lossy, so you lose detail in your artwork (a bit like converting your entire project to JPEG); its compression is not good enough to serve over the web; and encoding it in Javascript would probably increase the loading time a lot.

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