Ashley's Recent Forum Activity

  • Do not do this. See the warning in the addon SDK documentation. If you refer to undocumented engine internals, your project will be unsupported and could permanently break at any time.

  • You're wasting your time. Just use a HTTPS connection and everything is automatically encrypted on transmission and decrypted when received by the server. The Cryptography manual entry has a section on that ("HTTPS is already encrypted").

  • The SDK doesn't really support modules yet. It would probably be a lot of complicated work to make sure they are compiled/bundled properly on export (especially with no-minify mode) and have difficult compatibility implications (e.g. legacy file: protocol Cordova apps). However using dynamic import should work, or use the file dependency system to bundle a script (using the old-style browser script approach of adding to global variables instead).

  • Export as an Android Studio project, and then you can edit AndroidManifest.xml like you can with any other Android app.

  • I didn't mean to suggest object pooling via events isn't worth it - if you do want object recycling then that is the most efficient way to do it. However you'd probably be surprised how rarely you need to do such things. As Performance Tips says, the best thing to do is the most easy and obvious approach, and only optimize if necessary.

    Modern JavaScript GCs are very sophisticated. Generational collectors do make it especially cheap to handle short-lived objects (minor GC). However modern JS engine's major GCs are still parallel (using multiple CPU cores), incremental (running small jobs intermittently instead of one big stop-the-world pause to avoid jank), concurrent (running simultaneously with JS execution, preventing risk of jank), and also where possible schedule work in idle time to avoid interrupting smooth framerates. The V8 blog has some good entries talking about this, such as this 2019 blog post, and bear in mind there's been ~5 years more improvements since then. Overall the state of modern JS GCs is so good that I don't think I've seen any meaningful performance impact from GC in Construct games for a few years now. I just write modern engine code ignoring GC, and everyone's games are running perfectly smoothly, and where any problems come up, they are not because of GC. So, it feels pretty close to a solved problem really. I don't know if C#'s GC is as good - I would not be surprised if it was not as sophisticated, and so some people do have to code around it to some degree, but in my opinion that is not necessary with JS.

  • If you right-click the project name in the Project Bar and select Tools - View spritesheets, you can see the images that Construct is really loading. Since everything is placed on spritesheets, it may be that a new image is added and it increases the spritesheet size by more than the image size. Usually Construct will pack a range of images on to spritesheets to reduce any waste, but you can also tweak the memory impact of it by adjusting the max spritesheet size in Project Properties.

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,424,347 followers

Connect with Ashley

Trophy Case

  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Forum Wizard Made 5,000 posts in the forums
  • Forum Unicorn Made 10,000 posts in the forums
  • Forum Mega Brain Made 20,000 posts in the forums
  • x108
    Coach One of your tutorials has over 1,000 readers
  • x62
    Educator One of your tutorials has over 10,000 readers
  • x3
    Teacher One of your tutorials has over 100,000 readers
  • Sensei One of your tutorials has over 1,000,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • x35
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs