Ashley's Forum Posts

  • Nothing. The preset dropdown just fills in the viewport size and orientations fields, so you can see it just sets a resolution of 320x180. For retro games you can also check 'Optimize for pixel art' to set various project settings suitable for retro games, and if you click the 'Help' link on that dialog the manual explains what it does.

  • Well you've basically figured it out already - Google have plans to add support for local file access in web apps, which might turn up some time early next year. By that point virtually everything that previously could only be done in the desktop download will be possible in the browser. Then there's no real justification for having a separate desktop download, so we'd probably retire the desktop download. This would reduce a lot of the maintenance overhead (since there's a bunch of desktop-specific code to handle things like folder saves, clipboard access etc. which we could remove, as well as eliminating the need for a parallel update process of the NW.js build used), and avoid NW.js specific issues such as various crash bugs that have come up lately that only affect NW.js.

  • Is there a particular feature or other reason you are looking for the upgrade?

  • We've done tons of work directly addressing many top user requests for Construct 3. If you don't care about those features yourself, it doesn't mean there aren't loads of new improvements in Construct 3 that save loads of time for other people. For example having a built-in build service saves tons of time for people publishing to Android. I think you're deliberately trying to mis-represent the situation, perhaps to try to add pressure for your own personal feature requests. We have a public feature request platform where users vote on the best ideas - you can always add to that.

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

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