Ashley's Recent Forum Activity

  • Construct 2 only issues draw calls for objects that are visible and on-screen. Invisible layers are skipped completely and issue no draw calls at all regardless of their content.

    In extreme cases (which I guess you might be seeing) a huge number of off-screen objects can still cause overhead in draw calls due to all of them having to reject the bounding box test which checks if they are on-screen. This is a tiny super-fast check though so you will need thousands of objects to see any effect here. This is precisely the problem render cells are designed to solve: it means it only checks instances near the viewport, rather than everything on the entire layout. (But note the restrictions on render cells.)

    Invisible layers on the other hand skip their contents entirely (since it makes no difference if they are on or off screen), so it is faster to hide large numbers of instances by putting them on an invisible layer than moving them offscreen. This is a micro-optimisation though, so again is only important with thousands of objects, and render cells should in theory avoid the need to use this workaround.

  • The User Media object already supports this. There's a "speech synthesis" demo built-in to C2 that demonstrates it.

  • Closing as by design. This has come up a few times in the past and it's not feasible to change it.

    The problem is the event system is nested, and internally the engine will be half-way through iterating the instances list while running various aspects of an event. Creating a new instance adds a new instance to the instances list, and destroying an instance removes it from the instances list. Modifying these lists while they are being iterated for running events causes bugs and crashes, because it's unpredictable to modify a list while you're simultaneously using it. A long while ago user's projects were crashing because of this problem, so we made this change intentionally to fix it. The end of top-level events are the only safe place to actually update the instances lists, because they are guaranteed to not be in use at that point. After top-level triggers also counts, but not functions (or other triggers fired from inside conditions/actions/expressions), because then you're still nested inside another event.

    Note that creating works the same as destroying, i.e. a destroyed instance does not really stop existing until the next top-level event, although this tends to be less of a problem.

    Working around this from within the engine would degrade performance for all projects, because it would mean every loop inside the engine that deals with instance lists has to have a per-iteration check to see if the instance list was changed while it was looping, and then do extra work to mitigate that. Not only does this slow down everything (particularly tight loops which do little work), it is also a very complex engineering project that would probably take months and involve a whole load of follow-on bugs and further corner cases that need fixing. I really don't see that as a reasonable thing to do when it will also degrade performance everywhere, just to fix a slightly weird corner case which is possible to work around, so this is not something I think we will ever change.

  • Closing as not a bug. You must still specify the return type flag with the deprecated flag, which is what the error message is telling you. Otherwise you are saying the expression is hidden and has no return type (which affects projects that still use it).

  • I already had a lot of experience with it from Construct Classic, so as R0J0hound suggested it made sense to stick with what we knew. Also at least at the time the whole .NET thing made the installation a bit more complicated and could have meant lots of users having to do large .NET installation updates, probably would have meant dropping XP support, and other implications like that. (Remember this might not be a big deal now but we were deciding in ~2010.) C++ apps are nice in that they can be set up to run on a brand new computer/OS install with no extra config, which is a nice benefit for a tool aimed at non-technical people.

  • Just file what you've put here on the NW.js bug tracker, describing how the NW.js process does not close. I could report it for you but in the past I end up just being a middle-man between you and the NW.js developers, so it's more efficient to just report it directly. If you're asked questions about C2 you don't know the answer to, you can tag me on github as

  • Plugins are also stored in your %appdata% folder. If any of the official addons caused this message, everybody would be seeing it, but only you are so it must be a third-party addon in %appdata% which you have not cleared.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Okay, I think I found that there was a mistake in our build script, where it was copying the 64-bit audio tools for the 32-bit build. This meant our previous attempts to update the 32-bit audio encoders did not work. I've corrected it for the next build so hopefully it will (finally) be OK there.

  • Actually I can't reproduce, the provided demo works fine for me. Also the .capx file uses third party plugins which is not allowed in bug reports - please read the bug report requirements - so closing.

  • I can reproduce, but it's clearly an NW.js bug, not Construct 2, so please report it here: https://github.com/nwjs/nw.js/issues

    If the issue is specific to NW.js you can save time in future by reporting it there directly.

  • More of a feature request, but straightforward to add, so it's in the next build.

  • This is by design and documented:

    [quote:7bapmfwb]Note: backups are only made when pressing the 'Save' button. Simply opening a project that somebody has sent you will not make a backup for it unless you modify it and click 'Save'.

    In other words, autobackup means "upon save, make backup if time since last backup is longer than the interval given". Autosave is meant to be the mechanism to trigger that on a regular basis automatically without having to press save, so closing as won't fix.

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,779,190 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
  • x126
    Coach One of your tutorials has over 1,000 readers
  • x74
    Educator One of your tutorials has over 10,000 readers
  • x5
    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
  • x42
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs