Ashley's Forum Posts

  • Vector X is capped to the max speed.

  • It should not that have that serious an impact on performance. Note the CPU measurement can be inaccurate since it's based on Javascript timers, so it could just be due to the unreliability of the numbers you're looking at. Either way, post a .capx demonstrating this so we can investigate further.

  • Closing, please follow the bug report guidelines.

  • We take backwards compatibility very seriously, and we have made many internal changes over the past 2 years that required extra code to maintain backwards compatibility, and we keep and maintain that extra code indefinitely to ensure projects from as far back as possible can still open and function correctly. However in rare cases (and we try to keep this to as absolutely few cases as possible) we feel an early-on decision was made incorrectly and we then have to trade-off: do we keep it like that forever (and people might make posts like this, but instead complaining "why has this been broken for so long? why don't you just fix it?"), or do we try to fix it as quickly as possible so in the long term it's a better tool, risking introducing some degree of backwards compatibility? Sometimes we choose the former, but whenever we do this we carefully document it in the changelogs and provide advice on how to update your projects accordingly. I think our track record with regular users is good, and in general people who are diligent with updates don't have such serious problems. However going for nearly 2 years without following updates is a different case, especially since you were an early adopter and the software was in a much earlier state of development, and therefore more likely to change. I think we make virtually no breaking changes these days since it's much more mature.

    I'm sorry you've had trouble with an old project (and thanks for being an early adopter!), and the option of trawling through changelogs for breaking changes is probably not great. However I gather it still does open and run, so it's not completely hopeless. Sometimes a single breaking changes can cause far-reaching effects and yet have a reasonably straightforward solution, so it may be that a couple of minor tweaks will fix it. I hope you appreciate that while frustrating, this is a tradeoff that is sometimes necessary to prevent going in to the long term with something even worse: a tool bogged down by gotchas and poor design decisions that were never fixed.

  • FWIW, all games on the Arcade are made with Construct 2. It's not possible to upload games made with other tools to the Arcade.

  • Node.js 0.11 still hasn't gone stable yet, and as discussed previously the Web API requires that you run a separate server.

  • You won't need any plugins from iOS 8 or Android 4.4.3+. Both already have GPU-accelerated canvases which works in PhoneGap. I'd advise against using PhoneGap plugins: they are not officially supported and our experience of these has generally been that they are missing features which results in frustrating compatibility problems. If you need something fast now, use Ejecta for iOS and Crosswalk for Android.

  • Doesn't the demo that comes with Construct 2 work?

  • It's by design that the Multiplayer object only syncs the absolute minimal set of properties that you specifically tell it to, in order to avoid wasting bandwidth. If it synced all the object's expressions that would likely use a huge amount of bandwidth and make it impractical to use, so anything extra you want to sync you have to explicitly add.

    The easiest way to do that is add an instance variable, sync the variable, and use it to store the intended width/height (or just a single scale value if that's all you need and want to save bandwidth).

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 650mb is an extraordinary high memory usage and your game may not even run on some desktop systems. See Remember not to waste your memory

    You should make sure WebGL is enabled in project properties. Then Ejecta will at least support memory management, helping to avoid out-of-memory crashes. CocoonJS does not support this though.

  • Which exporter are you using exactly? There are a couple that support Android. I don't think it will work in CocoonJS, but it should work in Crosswalk.

  • Magistross - if you 'execute javascript' and show the values of window.innerWidth and window.innerHeight, what do they say? Also you should show the Browser.DevicePixelRatio value. That should be enough to work out if there really is room to integer scale it up. If the OS takes up any room then it won't have space to put the size up.

    If you still think there's an issue then best post another report since this one is closed now.

  • After choosing a file, the file chooser plugin gives you a URL to the file (the FileURL expression). You can pass that to the Sprite's 'Load image from URL' action or make an AJAX request to it.

  • What exactly do you mean is happening? Does it slow down over time or is it always slow? Is that the case in real web browsers or just this "e-learning app"?

    Perhaps you could share your .capx because sometimes beginners make mistakes which produce memory leaks and slow down the game over time. Nothing to do with HTML5, just an ordinary coding mistake.

  • It's probably the javascript parse time. Why aren't you minifying the file? It should be able to bring it down to under half the file size making the startup time that much quicker too.