Ashley's Forum Posts

  • I just tried the 'Microphone input' example and it works fine for me.

  • The default settings by definition aren't experimental, they're the way it works by default. Everything should work with the default settings, but if you change experimental features to something other than the defaults, it could break things. In that case it's probably not a bug and you just turned on something unfinished, hence the off-by-default experimental setting.

    If turning on an experimental feature actually fixes something, it's good evidence it's a bug in Apple's code with the default settings, and so that would need to be reported to and fixed by Apple.

  • I filed an issue with Apple about poor performance in some cases. It looks like they're working on fixing it.

    That issue still rendered everything correctly (if slowly), and had nothing to do with sound. So any visible rendering glitches or sound issues will be unrelated. And as ever, it's generally impossible to investigate without a bug report following all the guidelines, as we need all that information to be able to look in to it. If things previously worked on iOS 14 it's most likely iOS bugs that Apple need to fix though, so you might want to cut out the middleman and report issues directly to Apple if your apps have new issues in iOS 15.

  • WebGL is now required. It should not be an issue, as WebGL is supported virtually everywhere now.

  • In Construct 3 you should only use WebM Opus (.webm) files. It's the only format guaranteed to work on all platforms.

  • In Construct SVG cannot have unlimited scale as it runs in to maximum texture size limit. Rasterizing SVG is also much slower than rasterizing bitmap images, although it does not have to be done constantly (only when scaling up). For low-color images like the ones in your screenshots, PNG should have very good compression. Construct's SVG Picture also does not support animations, collision polygons, and other Sprite features. So I would say just use Sprites with PNGs.

  • Changing this would also break all existing projects that rely on the current behavior. So it's tricky to change.

  • Yes, it would be difficult to add this feature, as Tilemaps draw in a much more complicated way than Sprites or Tiled Backgrounds and so it would be more complicated to support meshes for them.

  • "Ex" means "extended" as it also supports a wider dynamic range and higher precision. But the main reason is that the name "rgb" was already taken, so we had to think of something else to call it. The "rgb" and "rgba" parts of the name refers to the components it uses.

  • Well, it does look like it's tricky to integrate that with the engine, as it works differently to the existing engine.

    Could it be an effect in Construct instead? That will still be efficient and batch well providing the specified colors are the same.

    Is this feature widely used? Perhaps you could skip it for the first release?

  • If you run in to a problem please file an issue following all the guidelines, as we need all that information to be able to help.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • rgb is an old expression from C2 that was deprecated years ago, so you'll most likely never encounter it unless importing an old project. One of the reasons it was deprecated is it is inconsistent with the new expressions, and removing it was meant to avoid this kind of confusion, but it still comes up with old projects.

    I think the manual entry is clear if you note that rgb is not in the list as it's deprecated. The four existing expressions are consistent: rgbEx and rgba work 0-100, and rgbEx255 and rgba255 work 0-255. In other words if it says 255 then it's 0-255, otherwise it's 0-100. But the old rgb expression breaks that rule: it uses 0-255. But it's hidden in Construct 3.

  • Answer your own performance questions with measurements. If I had to guess, I'd say using collisions/overlap would be faster, as the collision cells optimisation is an important way to improve efficiency (that's an old blog post, but the overall approach still applies in C3).

  • in Spine, each Quad can be two color-tinted differently (normal color and dark color).

    I'm not clear what this means exactly. Do you mean adding a gradient over the image or something?

  • Construct determines whether to call the Draw() method, so your plugin shouldn't need to worry about that.

    You don't need your own viewport check either - you can implement logic along the lines of "if Draw() hasn't been called for a few ticks, assume I'm now outside the viewport, and stop doing processing work".