New this build: an experimental front-to-back renderer, the Scirra Arcade plugin is back and can submit scores to the Arcade's new leaderboards, and a change to how 'On destroyed' triggers.
Construct 2 has always used a back-to-front renderer, starting at the bottom of Z order and drawing objects on top of each other. This is simple and works well but is a problem for games with a lot of overdraw, which is when there are lots of objects on top of each other and the GPU repeatedly fills the same pixels over and over which consumes memory bandwidth. Front-to-back rendering is complicated and will be covered in more detail in a future blog post, but in essence it works in two passes. The first pass is the front-to-back one where it doesn't actually render any pixels: it basically fills a special buffer on the GPU with the Z index of each object on the screen. It can only do this for the fully opaque areas of objects to ensure background blending works. Then the second phase renders back-to-front again, but uses a rendering mode that skips rendering any pixels which overlap something with a higher Z index. In other words, nothing is rendered underneath the opaque areas of objects. This saves all the memory bandwidth of repeatedly writing to pixels that are covered up.
However there are several caveats to this feature:
- Front-to-back mode requires WebGL, which most systems support, but canvas2d can only work in back-to-front mode.
- The extra front-to-back pass adds more CPU overhead since there are more draw calls, and filling the buffer at this stage also consumes memory bandwidth, which will degrade performance if there is not enough overdraw to offset this cost.
- Only fully opaque pixels prevent overdraw. Alpha channels, opacity, blend modes and many WebGL shader effects all need background blending so can only render back-to-front. If most of the objects in your game use these features, there may not be much to be gained by front-to-back rendering.
- IE11's WebGL implementation does not appear to be complete enough to support this feature, so it is disabled on IE (but not Edge).
- In our testing it appears Adreno GPUs are still not able to avoid overdraw even in front-to-back mode. As a result enabling front-to-back mode can actually significantly degrade performance, since it pays the overhead of the extra pass and then saves nothing. We don't know why this is and are trying to get help from Qualcomm about this. If we cannot solve this by the time the next stable release comes around we will simply disable front-to-back mode if "Adreno" appears in the rendererDetail expression.
To test the performance impact we made a test to deliberately stress overdraw as hard as possible. You can test the back-to-front fillrate test and the front-to-back enabled fillrate test. Maximise the window so it has to fill the largest area, then hold a mouse button or touch to create more large sprites. In this artificial test measuring sprites at 30 FPS we see improvements of up to 13x more sprites on a high-end desktop GPU, 9x more on a modern tablet, or 2-3x more on older tablets. In our testing some very old devices stayed about the same, and the Adreno GPU seemed to be worse.
We are very interested to see as many performance measurements from real-world games on as wide a range of devices as possible, as well as measurements across different devices for the artificial fillrate test as well. The question is whether this should be enabled by default come the next stable release, but this depends on if it generally improves performance or if it only helps in specific cases, which we need your help to identify. For now it is disabled by default so try enabling it in Project Properties and see how it works! Let us know in the comments here or on the forums about any interesting performance measurements you find.
Please note if you find any bugs they must be reported to the Bugs forum following all the guidelines - any issues reported in the comments here will not be investigated.