Does it run under the Compatibility renderer for a web export? The page lists the headless suite on 4.7.2, and since the effects are painted on the CPU, a browser build is where the cost would show first. Knowing that would help anyone making a small web game decide.
Good question. What I measured and what I haven't:
- Compatibility renderer: yes, on desktop. The demo project actually ships set to Compatibility. I ran the full demo and every effect under Compatibility (OpenGL 3.3), Mobile and Forward+ on Godot 4.7.2: both shaders (flash, dissolve) compile, no errors or warnings in the log.
- Cost (Compatibility, desktop, whole-frame time, i5-13450HX + RTX 4050 laptop, effects looping non-stop): 1 explosion ~1.2 ms, 5 ~1.8 ms, 10 ~2-4 ms, 30 ~4-4.5 ms; 30 small impacts ~2 ms. Forward+/Mobile were 0.3-1.3 ms faster in the heavy cases; most of the cost is the GDScript painting, which is the same in every renderer. An earlier run of the same benchmark gave higher numbers (10 explosions 6-9 ms, 30 about 17 ms), so treat these as a range, not a promise.
- Web export: not tested yet. I haven't exported it or run it in a browser, so I have no web numbers. The code uses no threads, no file access and no OS calls, and the shaders are plain canvas_item shaders, so I don't expect a blocker, but GDScript running in WebAssembly will be slower than the desktop numbers above, and I can't say by how much until I measure it.
- One known detail: the dissolve noise pattern differs slightly between GPUs (it uses a sin-based hash). It still works, it just won't be pixel-identical across GPUs.
The free sample (impact, sparks, ring, flash) is the same code as the full pack, so you can try it in your own web build before buying.
Follow-up: I've now exported the demo to web and measured it in a browser.
- Setup: Godot 4.7.2, Web export with the no-threads release template (so no COOP/COEP headers needed), Compatibility renderer (WebGL 2). Chromium-based browser on Windows, same i5-13450HX + RTX 4050 laptop.
- It runs. No errors or shader warnings in the console; flash and dissolve compile and apply under WebGL 2.
- CPU time per frame (effects looping non-stop, each frame stepping 1/60 s like a 60 fps game; desktop Compatibility in brackets, same method): 1 large explosion ~3 ms [1-2]; 5 ~6 ms [2.5-4]; 10 ~11 ms [4-6.5]; 30 ~23-30 ms [11-16]; 30 small impacts ~4-6 ms [2-3.5]. GDScript in WebAssembly came out about 2x the desktop cost on this machine.
- What that means: in a browser, up to roughly 10 large explosions on screen at once fit in a 60 fps frame, with not much room left for the rest of your game. 30 large ones at once don't (that's around 35-40 fps). Small impacts are cheap. Slower machines will be worse.
- Correction to my earlier numbers: the desktop figures I gave before (e.g. 30 explosions ~4-4.5 ms) came from a benchmark running at several hundred fps, which averages toward the cheap frames. At a fixed 60 fps step the same desktop is 11-16 ms for 30 explosions. Sorry about that; the numbers above use the corrected method.
- Not tested: Firefox, Safari, mobile browsers, integrated GPUs, and the threaded web template.
The free sample uses the same drawing code, so a quick web export of it in your project is the most reliable check.
Thank you for making a web export. For a small web game, 30 large explosions at once takes 23 to 30 ms, past a 60 fps frame, while 10 at about 11 ms still fits. Capping big effects near ten in a browser build looks like the safe rule. Web numbers on the page would answer this for the next person before they ask.