Ashley's Forum Posts

  • Safari doesn't support prompting to install a web app. You can do it manually though with the "add to homescreen" feature in Safari.

  • Well, C3 doesn't pool objects, and it still significantly outperforms C2 on many benchmarks, including intensive destroy/create benchmarks, so it's not like it's made C3 slow.

    In Construct, there are two different things that happen when creating an object: firstly allocating the necessary memory, and secondly running a bunch of engine code to initialize the object. It's important not to conflate these things. Object pooling only helps with allocating the necessary memory. Even if you get an object from a pool instead of allocating a new one, the second task of running a bunch of engine code to initialize the object still has to be run. And that is much more work than allocating a bit of memory, and so object pooling has little benefit to improving performance there. If you make a Construct project that recycles objects, note that is not running the engine initialization code as it is keeping the object alive, so that will measure much faster, but mainly because it's not running the engine initialization code when creating objects. So if you want maximum create/destroy performance, you'd still be best off doing it in the project, as you can design the project to work with objects that continue to exist, whereas the engine cannot do that. Pooling also has downsides: it adds complexity right the way through the engine, as it means class constructors run at allocation rather than initialization, so all the initialization stuff needs to be moved to a separate method; it opens up a whole class of bugs where a created thing has the wrong state because it was recycled and something wasn't reset correctly, plus memory leaks from pooled objects holding on to things that weren't reset; it opens up memory management questions about just how many objects can be held in the pool and for how long; probably some other stuff I've not thought of.

    So C3 doesn't do any in-engine pooling for entire objects, and I think time has shown that to be the correct decision - it just doesn't matter, and even if it does, doing it within the project is the best approach anyway. I think the engine does pool things in a couple of specific cases like for individual particles. I still doubt it makes much of a difference. The main problem with JavaScript performance these days is that everyone continues to underestimate it, when you can usually write basic obvious code and it'll be competitive with C++/C#.

  • It depends on the type of the thing that you call GetSdkInstance() on... and whether it's editor or runtime code. It's hard to tell from your post.

  • As I said before, usually the only things that will create a conflict is where two people try to modify the same part of the project at the same time. It's explained more in this tutorial.

    I'd recommend a workflow where people have clear roles to try to avoid conflicts. For example your proposed workflow does not guarantee that, as "add interactivity" could include a wide range of potentially conflicting changes, e.g. two people could modify the same event block in the same event sheet and still cause a conflict. However if two people are working on separate layouts or separate event sheets, that should avoid a conflict.

    Remember even if you do get a conflict, it can be resolved, but it can be tricky - the easiest way is just to roll back and try again. Over time you should get a feel for what kinds of changes are safe and which risk conflicting with your team members, depending on who is working on what.

  • I thought construct ran an internal pool of objects in order to recycle objects destroyed objects and improve/reduce overhead for object creation/destruction in game.

    No, it doesn't.

    IIRC maybe the C2 runtime did that, but the C3 runtime doesn't, so this hasn't been the case for years. JavaScript and modern GCs are so good that kind of pooling approach doesn't matter any more.

  • As far as GC goes though, for example, I thought you said vector2 were dangerous because of gc.

    I think I wrote about that kind of thing in a blog post in 2012. Things have come on a long way in the intervening 14 years!

    You might want to focus on reducing object overhead if you're writing something like a high performance custom physics engine, but I think these days most of the time, it's probably fine.

  • I'm not sure what you mean? What pool? The code you showed will just GC normally so there's no need to specifically clean that up in a release method.

    If you want to know when another object is destroyed, you can listen for the runtime "instancedestroy" event.

  • Normally in JavaScript unused things just get garbage collected, but this does not cover all possible kinds of resources like GPU textures, active WebSocket connections, etc. So the engine provides release methods that are called just before objects are discarded and left for GC, so you can release any other kinds of resources that do not normally GC. (It's also sometimes helpful for development/debugging purposes - clearing references, or setting a 'isReleased' flag, can help identify dangling references to released objects.)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Applying editor-side changes while the editor is open is an extremely difficult problem. What happens to the project you are looking at if the addon has a breaking change made while you have a project open? There are probably hundreds of ways the editor could crash after that, and it's infeasible to spend weeks or months doing all the work to sort out all those possible cases instead of doing other things like new feature development, just so you don't need to reload the editor during development.

    That doesn't apply to the runtime though, so you can in general make any runtime change and it will apply on the next preview.

  • You do not have permission to view this post

  • In normal usage of Construct, it should be impossible to save a project with invalid expressions.

    If you do something like addon development and make a mess of a project, e.g. by saving it with one expression, making breaking changes to the addon, and then trying to open the project again... that's kind of on you!

  • I realized this is confusing and renamed it for the next beta to "set min/max delta-time", as that better describes what it does - it's essentially a clamp on the value of dt.

  • If you're using a local server for addon development, and you end up in a mess, the easiest way out is to clear browser storage (which has the effect of uninstalling all addons).

  • It's expected. In general as a dynamic language like JavaScript, it is not possible to identify exactly where all properties are consistently used and automatically update them. You can use a text-based find-and-replace but you should review every match to make sure it doesn't update something incorrectly.

    One of the benefits of Construct's object model is it can rename things for you automatically and exactly (except where string "by name" references are used). TypeScript also uses static typing and tools like VS Code can use "Rename symbol" which should help.

  • The general coding standard is properties and functions beginning with an underscore are private, and anything else is public. To follow that convention, this._worldInfo is a private property that the class itself can use, but outside callers can use GetWorldInfo().

    Honestly, JavaScript performance is so outstanding these days that worrying about references/GC is very likely premature optimization and a waste of time. These days I ignore all that stuff for engine code and 95%+ of the time it works out fine. The main problem is people underestimating how good the technology is. See the manual section on Performance tips most of which applies to JS coding too.