Addon SDK: Support for GPU Compressed Textures (KTX2 / BC / ETC2 / ASTC)

Post reply

❤Follow Topic(4)

0 favourites

2 posts

From the Asset Store

Gif

Super Platformer 3 Engine

$14.99 USD

Controller Support ,TouchScreen Support , Keyboard Support , Action Platformer, Lots of Animations

GameHouse

- mistouluf
- - Joined 3 Jul, 2020
  - 30 topics • 40 posts
- 1
- 30 Sep, 2026
- Quote
Hi,

I'm investigating the possibility of creating a Construct 3 addon for **GPU-compressed textures**, using formats such as KTX2 / Basis Universal and GPU formats like BC, ETC2 and ASTC.

The goal would be to reduce GPU memory usage for texture-heavy 2D games.

For example, a 4096×4096 RGBA8 texture normally requires about:

**64 MiB VRAM**

Whereas the same texture could require approximately:

- BC7: ~16 MiB

- ETC2 RGBA: ~16 MiB

- ASTC 4×4: ~16 MiB

- ASTC 6×6: ~7.1 MiB

- ASTC 8×8: ~4 MiB

The ideal implementation would allow compressed textures to be used with normal Construct rendering and batching.

In particular, I would eventually like to support:

- Sprite

- Sprite animations / frames

- Tiled Background

- 9-patch

- Tilemap / tilesets

My main question is about the current Addon SDK / renderer API.

**Is there currently a supported way for an addon to create/upload a native GPU-compressed texture and expose it as an `ITexture` usable by Construct's renderer?**

For example, something conceptually equivalent to uploading BC / ETC2 / ASTC compressed texture data rather than creating a texture from an `HTMLImageElement`, `ImageBitmap`, canvas, etc.

Ideally the addon would:

KTX2/Basis file

→ detect GPU capabilities

→ transcode to BC / ETC2 / ASTC

→ upload compressed blocks directly to the GPU

→ obtain an `ITexture`

→ use normal Construct rendering/batching

A second question:

**Can an addon provide/replace the underlying texture used by built-in objects such as Sprite, Tiled Background, 9-patch or Tilemap?**

Or are their internal textures intentionally inaccessible to addons?

If replacing native textures is not supported, another possibility would be implementing custom objects such as `CompressedSprite`, `Compressed9Patch`, etc. However, this would duplicate functionality already present in Construct.

It would therefore be useful to know whether the renderer abstraction could eventually expose something along the lines of:

`CreateCompressedTexture(...)`

with implementations for both WebGL and WebGPU.

The objective isn't primarily reducing download size — WebP/AVIF already help with that — but reducing **actual GPU texture memory and memory bandwidth**, while keeping textures compressed on the GPU.

Would this be possible with the current Addon SDK, or would it require a new renderer API from Construct?

Thanks!
Tagged:

addon
gpu
memory
texture
Try Construct 3

Develop games in your browser. Powerful, performant & highly capable.
Try Now Construct 3 users don't see these ads
- Ashley Construct Team Founder
- Moderator
- - Joined 21 May, 2007
  - 673 topics • 31,159 posts
- 2
- 1 Oct, 2026
- Quote
I'm afraid currently neither is supported: compressed texture formats aren't exposed by the renderer, and there is no way to replace the textures used by other objects. This kind of thing often requires deep integration and so may well have to be built-in to the engine rather than implemented from an addon.

Supporting compressed texture formats is awkward for a number of reasons:
- All compressed texture formats are lossy, which makes them a poor fit for 2D content - Construct defaults everything to lossless formats. Usually compressed textures are designed for things like 3D model textures which are shown scaled and at oblique angles which make artefacts harder to notice. They also use lossy algorithms designed for fast GPU decoding, not nicer-looking perceptual coding like AVIF.
- Compressed texture formats have poor compression ratios relative to formats like AVIF/WebP. This means shipping them with your game would significantly increase the file size. If you continue to ship AVIF/WebP and then intend to encode compressed texture formats on startup, this can be very performance intensive and could significantly increase loading times, especially with larger images. Compression is often much more CPU-intensive than decompression, especially if there are different ways to compress data and identifying the best involves trying multiple options. You might be able to trade-off between performance and quality, but choosing between fast loading with poor image quality or slow loading with good image quality isn't a great choice to make.
- Hardware support often means you have to support multiple formats, which means shipping multiple encoders and dealing with the above complications in each case.
- Historically some compressed texture formats have been patent-encumbered which in some cases actually makes it infeasible to ship an encoder with the game, but I believe with modern formats this is less of an issue.
Meanwhile with the capabilities of modern hardware, small to medium size games don't tend to have significant issues with performance or memory usage. Where necessary there are also several options for reducing memory usage as well.

So overall it just doesn't seem like a great tradeoff which is why Construct doesn't currently support it. The recent addition of more 3D features somewhat strengthens the case for compressed texture formats, but it doesn't really solve the key problems.