Ashley's Forum Posts

  • Update: we've added translation projects for Russian, German and Ukrainian. You can sign up as a contributor for those if you want to help!

  • You're only comparing the Chromium engine - have you tried Edge and Firefox? They have different v-sync engines. Edge was particularly good IIRC.

  • Yes, it's already implemented in Construct 3. The Xbox Live plugin will be back-ported to the next C2 release so it works the same there as well.

  • Note the Construct 3 manual covers this.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • No, because even if you could, there's no way to create an action on an "abstract" object. You have to create an action for a specific kind of object. The best you can do is add all objects to a family, and pick from that family by UID.

  • Ashley Bunnymark was not optimized for each platform.

    I think it was a fair test. I'd be happy for you to provide an alternative test if you want, IIRC someone was hosting the tests openly on GitHub, and the tests were independently created (not something I put together to prove a point). The test is also CPU-bound on draw calls so I think it's a reasonable comparison of each engine's CPU performance. I think it's reasonable to also say that if JS can rival native in this area, then it can in other areas. So if our engine is slow in any respect, it's probably not because of the use of JavaScript. Perhaps we could make improvements in some parts of our engine, but the point is it's probably not slow because of JavaScript. So in this day and age, I think it's naive to say we should change language to improve performance, especially when the costs of doing that are extremely high.

  • I asked before how many work years it would require to have a native exporter

    For 100% compatibility with the C2 runtime, essentially never - not before we went out of business pouring all our efforts in to trying to essentially rebuild a significant proportion of a browser engine, which are made by huge corporations with thousands of engineers working round the clock. So, you say, why not throw away the features which are hard? Because lots of people use them, want them, and buy C2 licenses for them, and then it causes a huge compatibility nightmare with porting projects. These consequences are worse than any of the problems you think this might solve.

    I honestly don't see how it answers my points. An (although beautiful) low-collision count top-down racing game and a few tech demos dont hold up to actual CPU-heavy games/platformers on Steam whose developers are telling you HTML5 is not matching up to expectations set by similar tools (eg: Classic and Fusion and GameMaker)

    There was a bunnymark benchmark recently that showed C2 in Chrome equalled or exceeded those engines. So I am confident in saying JavaScript performance has reached the point where it can equal native.

  • Your article is the case against Construct Classic.

    No, it's a case against making native engines for Construct 2 and sticking to HTML5. It addresses your points.

  • I am really tired of all these arguments. I already wrote our whole case: the case against native engines

    In general the whole argument that "due to <some random issue> you should drop everything and build native engines!" is ridiculous. Why not just fix the issue? Native engines come with their own whole pile of issues, many of which are worse than the issue being raised, so this is just completely off the cards. If we actually did that, I think it could easily be such a big disaster as to risk ruining the company. I guess people are still going to tell us we should do it though.

    BTW someone started another thread about v-sync accuracy worrying that it was locked to 16ms and thinking something was wrong - but actually it was v-syncing so accurately the number didn't change. Hardly sounds like a problem

  • It's on the todo list. We're all incredibly busy still, launching a product is a lot of work even without adding new features!

  • dt is measured with sub-millisecond accuracy. If it is locked on 16ms, it means the v-sync scheduling is so incredibly accurate, it's always exact. This means it's working perfectly! It's not a problem

  • We did make a native engine in Construct Classic, and it still occasionally dropped frames.

    Everyone thinks that making a native engine will magically fix everything. It's not the case.

  • This should be fixed in the next build. Workaround: make sure "Use new Intel XDK project format" is enabled.

  • Can't reproduce here, on a nVidia GeForce GTX 1070. Are your graphics drivers up-to-date? Looks like a weird driver issue.

  • Closing, please provide a .capx as per the bug report requirements.