Construct 3 - many questions (native exporterts)

From the Asset Store
Casino? money? who knows? but the target is the same!
  • Ashley

    My small test proves that native export is required even if you make a simple game with no behaviours and only one simple event.

    My test contains 5 moving 64x64 squares. The only behaviour they have is "wrap".

    APK - it runs 40-45 fps and 8-13% cpu on my mobile device (Apk is made via last version of intel XDK and crosswalk 11)

    HTML it runs 58-60 fps and 9-11% cpu on the same mobile device


    This test proves that Intel XDK kills about 15 fps in a very-very-very simple game.

    And now imagine what will happen with complex games.

    P.S. Later I can show you the same test built via native apk-export - you will see the difference. It is great.

    So should an APK have inherently better performance than HTML5 in stock browser?

    APK is dependent on the state of wrappers and they're sorely lacking at the moment.

    Can you do a test with Crosswalk 14 and/or Cocoon IO?

    Also, writing the same game in Eclipse using Java + android sdk will ALWAYS give better performance, is this being disputed?

  • paradine - it sounds like most of your criticism is centered exclusively on Crosswalk. It had a bug recently which could reduce performance, but it should be improved in Crosswalk 14. There's no reason Crosswalk can't be as fast as the browser (it is a browser), so it should be able to produce identical results to your HTML export which appears to have excellent performance, so if it can be that fast, what do we need a native exporter for? We're not going to work on a 12-18month project just to work around a passing bug in Crosswalk.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • intel XDK and crosswalk 11 - it runs 40-45 fps on my mobile device.

    The newest Intel XDK and the newest Crosswalk - it runs 45-46 fps on my mobile device.

    Native APK - it runs 60 fps on my mobile device.

  • paradine - I agree.

    I have to agree with you here..

    There is a lot of competition emerging in the 'game-maker engine' space

    Scirra will have to adapt to the market's demand or its customer's will undoubtedly move on.

    The way I see it Construct 2 has one really, really big flaw and it needs to be fixed..

    Just scroll down to look at biggest "CONS" with Construct 2 to see what people are talking about: ... onstruct-2

    I like the engine, but it needs an overhaul... C3 maybe????

  • :facepalm:

    first of all - if you export to PC - i guess you want to give your game over through STEAM or something like that (origin).

    if you go through these - they install C++ automatically, you just have to set them up.

    also - most of today games install some kind of C++ redist package because IT IS NEEDED. - you just don't see it installing every time because once installed no need to install again.

    and trust me i've not seen a game that can't be run fluidly on any PC that can run GTA V in 60 fps. (p.s. maybe he plays GTA V on lowest with 60fps and actually has a lot weaker pc then you think).


    • for earning extra money - would not pay
    • for good performance - already we have
    • for comfortable "one click" export - that thing does not exist
    • for independence from third-party plugins - ahahahaha.. you're a funny guy. there is no such thing as independence.
  • paradine

    • for earning extra money
    • for good performance
    • for comfortable "one click" export
    • for independence from third-party plugins

    I Agree.

    These are all excellent points....

  • paradine

    Personal License - 129.99$ (and I guess that most users use this one) - one time

    Education License - 49.99$ monthly or 359.99$ yearly

    so... from business point of view it's perfectly logical that Scirra does not care about native exporters. Why bother if bigger money (monthly/yearly) is from education subscriptions? Also making native exporter means more programmers = higher monthly costs = less profit = high risk.

    And Ashley is right that at some point HTML5 browsers/wrappers will be good enough. So people can wait months/years

  • There is a very accurate comment from

    [quote:2c0nhbbm]Unless you are creating a game strictly for browser/HTML5 usage, exporting to desktop or mobile is risky, as Scirra have no control over your final export quality. Since desktop uses NodeWebkit and mobile is Crosswalk, Phonegap or CocoonJS there is no guarantee that your final export performance and quality will be up to scratch for pro level 2d games. These 3rd party "browser wrappers" are very prone to breaking and introducing lag and bugs that can't be controlled from Scirra's side.

  • I know how to fix it - installing Visual C++ redistributable solves the problem

    I've not heard of this before, and it's a bug if it's the case. Have you filed a bug report? Ideally the NW.js exporter can work at best performance without having to install anything extra (other than the DirectX web setup thing, which is a pain, but we had to have that for Construct Classic as well, which used... a native exporter).

    I don't think we'd make more money with a native exporter: it is an enormously expensive project, requiring more staff, more development and testing time, and other far-reaching implications (like third party plugins essentially become unportable unless the developer feels like doing 5x as much work for free). We'd probably have to put up the price of C2, or charge per-exporter like some other companies do, running up a high cost for the customer if they want all the export options. Given that it has all export options built in, C2 is one of the cheapest tools on the market.

    Independence from third parties never goes away unless we write our own operating system and device drivers. We could for example choose XNA, Haxe, Flash, or something else, and equally be hosed by problems in those frameworks.

    It's true we don't have control over the performance of browsers. It already works great on most browsers though. The performance of modern browsers is improving at an impressive rate. I haven't heard any complaints about the performance on desktop for as long as I can remember now, and I think that's enough to prove HTML5 is not fundamentally slow. The only reason mobile is sometimes slow is due to a Crosswalk bug that hung around for a while (and should be fixed in due course so it performs identically to Chrome - it uses the same codebase), and possibly the fact Cordova still doesn't use JIT on iOS by default (which should be fixed in iOS 9, and despite this I have very rarely heard of performance issues on iOS, so it seems to be OK already!) As I've said before... anything which has a fix on the horizon isn't much of a reason to give up on the technology entirely.

  • I've not heard of this before, and it's a bug if it's the case. Have you filed a bug report? Ideally the NW.js exporter can work at best performance without having to install anything extra.


    I have not filed a bug report because NW.js is not a part of C2 and also such bug report will not appeal bug report's requirements.

    If you are interested in NW.js bugs, I also found how to solve the problem with random freezez - you have to add "--disable-force-compositing-mode" to "...\Construct 2\exporters\html5\nwjs\package-win.json"

  • To clarify a bit further....

    The biggest bottleneck of C2 is most assuredly non-native exporters. It is the biggest worry, the biggest pain, the biggest provider of uncertainty, and the hardest hurdle to overcome of C2. It's not just me, everyone has been saying this for a long time.

    I think it is worth every effort to bring native exporters to this engine; I would rather have that than all of the new features that could be dreamed up combined!!!

    It is not our "code". It is not our misuse of the events system. It is the reliance on 3rd party exporters that destroys more projects than anything else by far.

    I speak not from personal experience alone, but from the many experiences of countless other C2 users all throughout these forums.

    Native exporters would make C2 a world class game engine, otherwise it will sadly never be a consistent/reliable professional tool.

  • Do not count me into "EVERYONE".

    Every feature has cost. Ashley had told again and again that it will be a huge risk for native exporters.

    Using other game engines which has native exporters like unity3d would be a better solution, imo.

  • rexrainbow

    I hear you loud and clear, but the cost of not putting native export into this engine is already greater than the cost or risk of putting it in, imo.

  • rexrainbow

    the cost of not putting native export into this engine is already greater than the cost or risk of putting it in.

    It is better to proof this statement more clearly to Ashley.

    But I did not think this statement is true.

  • I would wager the single biggest reason people are leaving/have left C2 is for this reason alone; Poor exportation which causes poor performance....

    If I am trying to ensure the success of C2, I would rectify this problem posthaste

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)