Chowdren: Fast Construct runtime for consoles/desktop

11 favourites
From the Asset Store
Casino? money? who knows? but the target is the same!
  • matpow2

    Down the road, what is the possibility of formally hooking up with Scirra / Construct and producing officially supported exporters?

  • NetOne

    It's an interesting idea, but if Chowdren were an official product, people would also assume full and official support for their games. Right now, Chowdren is extended whenever a game we are porting requires it, and that has worked well for us. It allows us to get real games running on Chowdren and to produce real results, and it is clear how our work will be funded.

    For now, Chowdren will remain its own runtime. However, I will try to keep Scirra in the loop about Chowdren, in case there is something to learn from the Chowdren approach and vice-versa.

  • matpow2

    Down the road, what is the possibility of formally hooking up with Scirra / Construct and producing officially supported exporters?

    +1 That would be awesome

  • Supporting the C3 runtime is a different matter, but it should still be doable. The C3 runtime uses a very nice and exciting expression compiler, but this will require some extra work for Chowdren to support. If someone has a use for Chowdren using the C3 runtime, please let me know!

    I have a C3 project running on C3's runtime that i'm interested in testing just to see how it works.

  • I'd be interested in seeing a performance comparison between the C3 runtime and Chrowdren when possible

  • In related news, our port of Iconoclasts (made in Construct 1) is releasing on Nintendo Switch on August 2!

    I hope we can announce some of the Construct 2 games we are working on soon as well.


    For now, I won't make benchmarks available here. You can contact me by mail or on the Discord server if you'd like more info.

    In general, Chowdren is significantly faster than the standard runtimes. However, making specific numbers available would undermine the fact that the standard runtimes are viable for the majority of users. Ashley & team are doing a great job of identifying performance hotspots, as can be seen in their work on the expression compiler.


    You can send me your project on e.g. the Discord server. Hopefully, I'll have time to take a look soon!

  • In a strange coincidence I was just reading today that Iconoclasts is rated as one of the best Metroidvania type games on PC ... according to

  • matpow2

    I couldn't locate the Discord for Chowdren or MP2 so i sent you a direct email with c3 file. Hope it works!

  • matpow2

    I sent you an email about 11 days ago, yet there was no response.

    Did you receive it?

  • I have some news: Chowdren can now automatically merge effects together. This means that most of the time, Chowdren does not need an intermediate framebuffer to render objects with effects, which the standard runtime will have to do in many cases. If you use a lot of effects, you can expect this to yield some large performance gains.

    With the effects merging feature, there is also support for most Construct effects now.

    Technical details

    Consider two GLSL fragment shaders as follows:

    // shader 1, constant multiply
    void main() {
     gl_FragColor = texture2D(texture, texture_coordinate);
     gl_FragColor.rgb *= 2.0;
    // shader 2, monochrome
    void main() {
     vec4 col = texture2D(texture, texture_coordinate);
     col *= vec4(0.299, 0.587, 0.114, 1.0);
     col.rgb = vec3(col.r+col.g+col.b);
     gl_FragColor = col;

    Now, consider the result of applying shader 1, followed by applying shader 2. When shader 2 calls texture2D on texture, this is actually the result produced by shader 1. Therefore, if we wanted to merge these shaders together, we could do it as follows:

    vec4 temp_color_1;
    vec2 temp_coord_1;
    void main_1() {
     temp_color_1 = texture2D(texture, temp_coord_1);
     temp_color_1 *= 2.0;
    vec4 sample_1(vec2 tc)
    { temp_coord_1 = tc; main_1(); return temp_color_1; }
    void main_2() {
     vec4 col = sample_1(texture_coordinate);
     col *= vec4(0.299, 0.587, 0.114, 1.0);
     col.rgb = vec3(col.r+col.g+col.b);
     gl_FragColor = col;
    void main() { main_2(); }

    When running this through glsl-optimizer, we get the following result:

    void main ()
     vec4 col_1;
     col_1 = vec4(0.598, 1.174, 0.228, 2.0) *
     texture2D(texture, texture_coordinate); = vec3(col_1.x + col_1.y + col_1.z);
     gl_FragColor = col_1;

    As you can see, the merged result is quite optimized, and we would expect this to be much faster than using temporary framebuffers.

    There are still some cases where we will need temporary framebuffers. For example, for large effect chains using complicated shaders, most shader compilers will choke on the merged result. For the games I've looked at, this has only been a problem with the following effect chain:

    noisemask, lottes, blurhorizontal, separatechannel, separatechannel, hsladjust

    The culprit here is Lotte's CRT shader, which is a large shader.

    To be fair to the standard C2/C3 runtimes, even though this optimization would be nice to have in them, I can see why it wouldn't be feasible to implement. For example, some users may depend on some very specific behavior from the renderer, and this could be a non-backwards compatible change. Also, dealing with large effect chains (like the one above) may not be straightforward.


    Please check your inbox, you should have received a reply!


    Thanks a lot! I will take a look when time allows :)


    Nice! I feel Iconoclasts definitely deserves all the praise it has received.

  • matpow2

    Hi Mathias , I also sent you an email a couple of weeks ago, did you receive it?

  • Another update: on some platforms, we can get rid of temporary framebuffers entirely for effects that do not use cross-sampling. Most effects do not use cross-sampling, so this significantly improves the performance of effects, especially popular ones like Overlay and Screen.

    This is achieved by using memory barriers on platforms that support it (such as console platforms, and Direct3D 11/OpenGL with glTextureBarrier). This allows us to read a texture while writing to it at the same time, so a temporary framebuffer isn't necessary. WebGL does not support memory barriers, which may be a reason why the regular Construct runtimes do not perform this optimization.

    As described in the effect compositor writeup from Ashley, objects sometime require predrawing in the standard runtimes, such as when objects are rotated. By using the right texture coordinates for the background texture, we can also skip this step, removing another case where temporary framebuffers are used.

    In Chowdren, there are now only a few situations where a temporary framebuffer is required:

    • When a layer has 'force own texture', is not fully opaque, or uses an effect, a temporary framebuffer is needed to render the intermediate result.
    • When an object uses a cross-sampling effect (such as WarpMask, WaterBg), a partial copy of the background is made.

    Headbang Games

    Please check your inbox :)

  • matpow2

    I couldn't locate the Discord for Chowdren or MP2 so i sent you a direct email with c3 file. Hope it works!

    Hi, unless I'm wrong, said Discord server is this one

    It's not specific to Chowdren. If such server exists I recommend that matpow posts it

  • matpow2 - heya were you able to get a chance to test my c3 project?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I was referring to the community Discord server, which skymen linked to above :)


    I'm busy with gamescom at the moment (we're showing off Baba Is You on Switch!), but I will see if I have some more time once I get back.

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