Ashley's Forum Posts

  • Well, if we did document it, I'd point out it's not a fast way to render meshes. It is designed for dynamic rendering of 2D sprites, and so uploads all the vertices to the GPU every frame. A low-to-mid range device might have a budget of maybe 10,000 quads to still hit 60 FPS, which is fine for the vast majority of 2D games. 3D shape uses such simple "models" that it essentially counts as just two or three sprites in terms of performance impact, which is also fine. However a single complex mesh could use that all up if you render it that way. Normally a 3D engine would upload the mesh vertices to the GPU once in a static buffer and render repeatedly from that, using techniques like instancing to re-use the same vertices if multiple models are on-screen at once, all of which is far more efficient - but Construct doesn't support that because those are 3D engine features, and it's still at its core a 2D engine. Are you aware of the limitations of what you are doing when you are asking for this API? It won't scale well and will probably be very difficult to improve given the constraints of Construct as a fundamentally 2D engine.

  • Again, if you are considering only a few off-screen sprites to track variables and such, any discussion of 1000+ sprites is simply irrelevant to the use case and not worth discussing. I'm sure you can measure performance impact with a million sprites. But that has no relevance whatsoever to using a few off-screen sprites. The question is can you measure any significant performance impact with a few off-screen sprites? The answer is no, the performance impact is negligible.

    Even if we added an empty object to do things like orbit other objects around it, the engine would still have to track its position, and flag it as invisible. That's exactly what an invisible sprite does too. So I don't see how an empty object would improve anything in that case - the engine still has a tiny amount of work to do, similar to an invisible sprite, and so if you go and make a million of them there will be some performance impact. But the per-sprite performance impact is already so tiny, it doesn't seem to matter at all.

  • When you make for example 1 000 000 sprites...

    I don't think anyone is suggesting using a million empty off-screen sprites. The alternative is to use just a couple of off-screen sprites. Try to measure the performance impact of that - not some other far more intensive case. I doubt you will be able to measure any difference at all, because the overhead of just a few off-screen sprites is negligible. Hence there is no performance reason to add a separate object for this purpose.

  • FYI as Quad3D2() is not a documented feature, it's not actually officially supported for the SDK in the runtime yet either.

  • I would guess you just need to access any global variables via globalThis, as described by our guide on changes for modules.

  • We posted this guide for addon developers back in November.

  • A new type of folder is just a variant of the "add a setting" approach.

  • All modern browsers support WebGL. The error message usually means there's a problem with the graphics driver on the device. Installing any system updates may help.

  • Those scenes take a moment to load because our own code discards them when you're not looking at them... to save memory! It's nothing to do with Chrome. And if you have a bunch of other tabs open using memory, I don't see how that has anything to do with Construct. If you have them open while you work, then even if we made a native app, presumably you'd still have those other tabs open?

    Whenever anyone says "I don't like using Construct in the browser" I always ask these questions to try to figure out what the real problem is, since if there is some real problem, we can try to fix it. But I can never seem to work out what any real problem might be. Which is part of the reason I still think it's absolutely fine - in fact great - to have browser-based software.

  • Oh I see - it does change the visible area, but then you can compensate for that via System: Set layout scale to resolutionScale, which looks like it then gets the result you want.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • There are ads on the arcade - for Construct 3.

  • These errors are usually actually browser errors, not problems with Construct itself. Construct uses the entire available view area, but if the browser tells Construct the wrong size, then the display will appear at the wrong size.

    The first issue appears to be a Chrome bug I already filed here. I'm not aware of an issue on iOS. It's difficult to tell what's going on without more information, which is why we ask issues are filed here following the guidelines.

  • "Add a setting" as the answer to a problem does end up causing a lot of work. It results in difficult and confusing bugs as things go wrong depending on specific settings, and users get confused as to why requests sometimes work in some projects and not others (because again it depends on settings). If you add a few more settings like that you end up with pretty poor usability. So I really try to resist that. It's better in the long run to stick to one or the other. That's why the legacy scripting setting was ultimately removed, so we don't have to have and maintain two separate modes.

  • Here's our SDK guide on script minification.

    I can't comment on why other people make things. Sometimes people make things that look like they improve security, but are actually pointless. You have to understand what you're doing, why you're doing it, what you're trying to protecting against, and whether certain measures will actually be effective.

  • Use the Wake Lock feature of the Platform Info object.