Ashley's Forum Posts

  • Our policy for some time now has been that Construct 2 is no longer going to get any new features and is only receiving occasional bug fixes. It was first released in 2011 and won't last forever - at some point it will be retired. So I would suggest starting to move over Construct 3 now so you have time to figure out details like any changes that need to be made in the switch (see our guides on Importing C2 projects and The C3 runtime). If you delay, the risk is you will end up being forced to do this work anyway but on a tight deadline. There's loads of new features in C3 over C2 too.

    • Post link icon

    The goal is to eventually delete all the desktop app specific code in Construct. A quick search shows over 60 places in the editor code where we branch off and do something different for desktop apps. It adds a lot of complexity and maintenance cost to the codebase, such as dozens of often awkward desktop-specific bugs, when we'd rather be spending our limited development resources on other things,. It also kind of defeats our generally very effective strategy of having a single product and single codebase, which is one of the reasons we've been able to keep up with much better resourced competitors.

    Removing this code means even third-party launchers will no longer be able to activate desktop features in Construct 3. Besides we could not offer support for that code if anything went wrong with it after that part of the product had been officially retired. Therefore even if we just left it behind and ignored it, there's a high chance it will eventually break and stop working anyway. So I'd rather fix any remaining problems, then retire the desktop builds, delete all the code they used, and get everyone to migrate off it in one go. Having a lingering usage of unsupported desktop apps with people still getting upset when it breaks is something I specifically want to avoid. I think dealing with the pain of a change up-front is actually better for everyone in the long run.

    There are still a few things to do, such as sorting out an NW.js preview alternative. I think Remote Preview should be able to handle that. Part of the plan is to identify these gaps and fill them in before we make the change. So please plan on the assumption you will be switching over - don't assume that there will be any support for desktop builds at all in the long term.

  • Collisions have nothing to do with SVG or the GPU. So I'm still confused as to what you're testing or asking about.

  • I just tried it and it worked fine. This is exactly what I would expect: without a full bug report following all the guidelines, it's impossible to investigate the problem, which is why we ask for all that information.

  • I'm not clear what you're testing any more. Are you now looking in to intensive collision benchmarks or something? That doesn't sound specific to SVG Picture in any way.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Please file a bug following the guidelines so we can look in to that. I've never heard of that before and it should not be the case.

  • 1. No, Construct does not support dynamically changing behaviors. However you can add multiple behaviors and disable the ones you don't need.

    2. The supported plugins and behaviors in scripting are listed in the scripting manual reference. If it's not there it's not supported yet, and we haven't covered Physics yet.

  • The console log messages don't indicate a crash, just that it's slow.

    Coming up with good tests is difficult, I'd advise just replacing sprite with SVG Picture in one of the official tests, which is what I did with the quad issue performance test to measure a ~6x improvement. That test is focused on the drawing performance - the bounding box test is mainly about recomputing rotated boxes, which works the same regardless of the object, so will obscure the real results.

  • You shouldn't need to do that. It should work in any folder. If it doesn't, please file a bug about it.

    • Post link icon

    Publishing to the web also avoids the 30% cut that the app stores take, which if you have a popular app is a huge deal. There's also a much lower barrier to entry - visiting a link is a lot easier than searching the app store and installing something. Construct 3 itself is only on the web and not in any app stores, and it's working out great for us.

    I think the main reasons developers still make mobile apps is inertia - it's still seen as "the obvious thing to do". It does simplify taking payments too, if your business is small enough that integrating something like Stripe or Paypal is a significant hurdle. And frustratingly there's still a lot of misconceptions out there, as has been mentioned in this thread already - people keep saying "I need a native app for XYZ", all of which can be done on the web too.

    • Post link icon

    The NWjs plugin only works in NWjs, not the Chrome browser.

  • Updated the original post with new downloads based on Chrome 79 (NW.js 0.43.1).

    Note: local file/folder saves are experimentally supported in the Chrome browser. With this there are no longer be enough unique features to justify the desktop downloads, so they will be retired early next year. I'd recommend switching to the browser version already if possible - see the linked thread for information on using local project files/folders in Chrome.

  • I added a note to the manual page on expressions which hopefully clears it up:

    Note a common mistake is to write comparison expressions like value = 1 | 2 with the intent to match value to either 1 or 2. However this doesn't work as it is actually evaluated as (value = 1) | 2, which always evaluates as true. Similarly value = (1 | 2) won't work as 1 | 2 evaluates to true, so it only tests if value is true. The correct way to test this is using value = 1 | value = 2.

  • The reason ESC cancels editing is because comments have always worked that way. If we changed it, ESC while editing scripts would be inconsistent with editing comments, which seems confusing. I guess we could add a confirmation prompt if pressing ESC with unsaved changes though?