Ashley's Forum Posts

  • The current design of Construct is that it uses an arbitrary instance placed in the project as the default. Some people add an unused layout for that. The assumption is either they are all the same, in which case it doesn't matter which it picks, or you set the properties you care about after creating it.

  • If you want to create an object with specific variables, just add 'Set variable' actions after the 'Create object' action.

  • giving vague ideas to the benefit of your userbase

    FWIW, I call this "telepathic debugging", and it's about as reliable as it sounds.

  • I have no idea how the Google ads service works, so I'm afraid I just can't comment. It's outside our area of control and knowledge. If you used rocket control software with Construct and your rocket crashed, it doesn't mean I know rocket science and can help you solve the problem.

  • Which browsers are you using specifically?

    Over the last few releases we identified a problem where Chrome and Safari have different ideas of where text baselines go, which makes it pretty much impossible to exactly vertically center text across browsers. I'm not sure if the browser issue will be fixed any time soon, so you might want to work around it by just using "top" alignment and positioning the text with that.

  • The Taking Screenshots example shows how to download and share canvas snapshots.

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

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