Ashley's Forum Posts

  • That is not what I said. I said: "Nothing that can't be done with Construct 2, one way or another"

    And there's nothing that can't be done in JavaScript alone, one way or another, without Construct 2 at all. Obviously there's much more to it than that.

  • Absolutely nothing has been added that cannot be done with Construct 2 one way or the other

    There's absolutely tons new in Construct 3, including a whole new runtime engine with vastly improved performance, timelines, JavaScript coding, a dozen new plugins/behaviors, etc. etc... I really think it's absurd at this point to try to portray Construct 3 as having "nothing new".

  • As we have moved the vast majority of our efforts on to Construct 3, and Construct 2 nears the end of its supported life, we have limited resources on which to dedicated to ongoing Construct 2 support. As such we focus this on to only the highest priority issues. So far this has been focused on a number of reports about random crashes, which is a very difficult and time-consuming type of problem to deal with. We're working on the theory that this is related to third-party libraries that we use in Construct 2, hence the recent updates. Despite this there have been a couple of other updates along the way too. If you need better support and more updates you can upgrade to Construct 3 which has a much more active update schedule and we spend a lot more time supporting with bug fixes and such.

  • One of the big problems is handling memory management. Suppose there's an array expression type and you store a 10mb array inside an object's instance variable. Now how do you set a single value in that array without needlessly copying the entire 10mb array? There is both an efficiency problem (e.g. using 'Set instance variable' with some expression that copied the entire array and just changed one element would be super inefficient) and a user experience problem (how do you do 'set element at' in values that are stored somewhere else, e.g. in an instance variable? Is the action to do that still in an 'Array' object? Do we have to start explaining by-value and by-reference semantics to understand expressions?)

    Keeping a single array in a separate object avoids all of these problems.

  • It looks like this issue which has already been fixed. (As ever it's best to post bugs to the bug tracker, they're not dealt with on the forum)

  • We made some changes and it should be working better again now - sorry for the trouble folks.

  • We made some changes and it should be working better again now - sorry for the trouble folks.

  • Windows has a hard-coded limit of a maximum of 10,000 images. If you add in an icon per image it could be hitting that limit. Try changing the icon caching setting. Also note Construct 3 was rearchitected to avoid this limit completely so can better handle such large projects.

  • I just rebooted both web servers, hopefully that will help in the short term.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I think this comes down to the sequence of how collisions are checked in the engine. If you check for all solids colliding with a sprite it goes along these lines:

    1. Collect all nearby objects using the Solid behavior (using collision cells)
    2. Run through list of nearby objects, skipping any disabled Solid behaviors (or with mismatched collision filtering tags)
    3. If solid collision enabled, test for overlap (which goes through its own process of bounding box, bounding quad, then collision poly, to try to use quicker checks to avoid a full poly check)

    If you have 1000 sprites all checking for collision against themselves, then that requires 1 million collision checks per tick. Obviously this is extremely demanding and even the tiniest variations in how the engine handles this will produce measurable performance differences.

    If the objects don't use the Solid behavior at all, then the process stops at step 1 (it gets an empty list). If the objects use the Solid behavior but they are all disabled, the process stops at step 2 (it collects a list of solid behaviors, then skips them all because they're all disabled). If the objects use the Solid behavior and they are all enabled, then it proceeds all the way to step 3.

    It kind of has to work like this, since the collision cells optimisation works by grouping object types in to regions of the layout for handling any type of collision (not just solids), which necessarily does not take in to account any enabled/disabled state for behaviors. So yes, in this case you can measure a performance difference between no solid behavior, and a disabled solid behavior. In practice though I don't think this will affect most games, unless they do something similar involving millions of collision checks per second (which is already an obvious thing to optimise in your game).

    While profiling the project I found an easy way to optimise the checks for disabled solids, which on my system boosted one test with 1000 objects from ~18 FPS to ~30 FPS, so that should help a bit. But checking for collisions between all combination of hundreds, or thousands, of instances is always going to be incredibly CPU intensive and is something that generally ought to be avoided. Also if these objects were spread across a large layout, collision cells would be more effective at eliminating collision checks for far-away instances.

  • Performance could well depend entirely on the specific events you're using, but unless you share an actual project file nobody can see that.

  • Actually I think it's also worth mentioning the "use worker" mode is pretty new and may have different jank characteristics. So it might be worth trying with that both on and off.

  • People have been bringing up jank from time to time over the past few years. Ultimately for flawless jank, a frame needs to be rendered every ~16.6ms without fail. Rendering a frame means running all the logic for a frame, issuing draw calls, which then go through a highly complex graphics driver and compositing stack, all the way to the physical display. This is a long and complicated process that all computer graphics go through, and the regular 16.6ms deadline is a demanding one. All it takes is something happening in the background, such as a backup, virus-scan, or other resource-intensive activity like launching an app or performing background work in the OS, which steals a few milliseconds of work and the frame deadline is missed, causing jank. Fullscreen games usually bump their priority up and pause background work to ensure rendering is smooth, but windowed content has to contend with everything else happening on the system. So I think jank is likely to always be possible in a windowed game, and the behavior tends to be non-deterministic since it depends on system-wide activity working towards millisecond deadlines.

  • Filed this NW.js bug for the crash issue.

  • All changes are listed in the release notes. The ones that apply to ads are:

    Mobile Advert: Deprecated 'Configure' action, as using the plugin properties for configuration is now a requirement

    Mobile Advert: remove any whitespace surrounding app IDs, pub IDs and unit IDs to fix typos