Ashley's Forum Posts

  • I don't think we really have the resources to dedicate much time for developing ads features - they are particularly complicated and time-consuming to implement, and require a lot of on-going maintenance work. I would recommend looking in to third-party ad plugins.

  • If you have problems with a third-party ad service, it's best to contact them for support.

  • Instance variable values belong to instances. If there are no instances in the project, there are no instance variable values to display. So Construct can't show you a value or let you edit it. You should add at least one instance somewhere in your project, if necessary on an unused layout. And then an instance exists, which has instance variable values, which you can then edit.

  • An invisible object does not render anything. The engine merely checks the "is visible" flag, and then skips it. This is a tiny, tiny amount of CPU work. But if you make hundreds of thousands of sprites, you can measure it. It should not be meaningful to any real-world game. I am open to being persuaded otherwise by an example Construct project.

    There's also the render cells and collision cells optimisations in Construct which have been around for a long time. Using these, providing you don't have events or behaviors that are CPU intensive, and that everything is spread out across a large layout, far away instances should have exactly zero CPU performance overhead, as the engine won't need to consider them for anything at all. So assuming you do that, it's already possible, and so again there is no need for a further optimised object to achieve that.

  • Well if we naively add a "disabled" flag, the engine would probably still have to check if that flag is set in a number of places, which still involves a tiny amount of work, which you can probably still measure if you went and made a million disabled sprites. It's difficult to eliminate these types of overhead in a general-purpose engine. So you may as well have a sprite, which also has a tiny amount of overhead, but is most likely negligible for all reasonable uses.

    We strive to make Construct as efficient as possible in general, and results like the recent post comparing performance across different engines show we've actually done really well with a super fast engine that can even beat some compilers. However striving to achieve exactly zero performance overhead even in obscure cases is likely impossible and very likely not worth the trouble as it would make no measurable impact to virtually all real-world games.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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.