Atlas sheets were one of the things discussed at some point that may be in a future construct release.

when you say 9-sample boxblur.. so do you mean just a 3x3 sprite of solid color and stretched? can't get it working..

No, it's what happens inside the WebGL shader code.

That's what I thought after reading your release notes for r160.

But as you can see above: it does not work.

I tested "medium" (the default) and "high" downsampling modes. It always comes out like this, the mipmap bias on the texture2D lookup has no effect.

Last night I asked Ashley on twitter if it was possible to expose mipmap-filtering in addition to linear and nearest neighbor ("point") to users. He encouraged me to ask this publicly, so here it is. I also felt it belonged in here and not the Effects-subforum.

I'm in the process of writing a bloom-shader. Many indies rely on relatively cheap assets (boxes, stick figures etc.) combined with fancy schmancy glows and effects. As of now, C2 is lacking one, which is kind of a sore spot.

[Disclaimer: technical babble ahead]

What you normally do to write a post glow is to take the cheapest blur filter you can get (typically a 9-sample boxblur, 3*3), and put it ontop of the thing you want to make glow, using the screen-blend formula. The trick to get this good looking is to not just sample the texture, but use a rather large mipmap bias in your texture2D lookup. By that you don't sample the crisp texture but rather a mushy version of it, due to the filter - that's super cheap, computation wise. If you were only to use the regular linear filtering, a 9-sample boxblur looks like c***.

Here's a little example.. first is the GLSL-fragment shader for the bloom implemented in Shadertoy, using a 3*3 boxblur and mipmap filtering on the texture:

Simple, el cheapo and good looking.

Now the same thing, with linear texture filtering:

You clearly see the jaggies from the filter, the wider the blur the more noticable it is, of course.

I then implemented this for C2, hoping that mipmap-filtering was enabled by default, which it isn't, obviously. This is the running C2 version of the shader:

(it looks a bit more jaggy than the shadertoy-version in this shot, but that's only because it was resized, it basically looks identical).

Now there are of course some workarounds to get this done even with just linear filtering, you can use more samples, and typically you also

mush together several passes of them with varying sample numbers and radii - still, it is *far* more expensive to compute and does not look as good, especially on clean shapes like quads or lines, which is the No.1 use case for indies.

Would this be a lot of work to expose? Or is there a way to do it already? I would really like to use this and I think others might, too.

The debug mode will eat performance. It's not exactly representative of the final performance.

I tested it without debug, runs perfectly jank free (latest chromium, nvidia graphics).

Have you tested it with the debug mode? And if so: What are your PC-specs?

It's pretty amazing that games like The Iconoclasts aren't on there.

While The Iconoclasts was a CC game, today it only serves as a prototyping tool. The release version is done by another partner company which use the CC game as a reference and recode it some other engine (I asked him a few days ago because I was curious and that's what he said).

So including it in the frontpage features would be counter-productive, since it would immediatly spark a discussion about why he decided to do it this way instead of porting to C2 and releasing it

Rats! Thanks for the info. Godot's looking sweeter and sweeter by the day.

If you ever get Godot to export a project without janking (even with ONE sprite, even in fixed update) hit me up

Every engine has its quirks.

I see two options: Dynamically destroy and create assets as I progress through the level to keep the object count low, or put asset outside the screen on an invisible layer. My question is, will this last option have any effect?

Are you sure the draw calls are caused by objects off-screen? Because - they shouldn't. As long as it's offscreen, C2 doesn't render them. So you have some logic going on, but there should be no draw calls.

Dynamically creating and destroying objects has its own share of problems and caveats.

The first thing I would test is move the cam somewhere with one or no objects on screen and check if something changes. I'm almost 100% certain that the offscreen stuff isn't your problem.

Dude.. there was an e-mail by Scirra on April, 27th.

Is it possible you turned all the newsletters and notifications off?

Your images don't get through. Maybe upload them to a service like imgur first and post the links?

Any update on this?

Unfortunately, the situation is unchanged, no news. Even if the official plugin integration was to arrive now in beta, it would take weeks to get it into a stable release.

The situation is the same insofar as it's still a HTML5 engine, the exports are still wraps. If a device performed badly 2 years ago, it will do so now. And chrome-blacklisted video cards from 2014 won't have improved.

On current gear things will run better, of course. Still, you will have a hard time matching gamemaker's output performance. On some target devices it won't be possible.

You can test the performance (for the most part) with the free version. Using chrome on desktop and mobiles, you get an (almost) 1:1 preview of the final performance, because most wrappers are just that - chrome neatly packed.