Construct 3 - many questions (native exporterts)

  • hardware is not so limit as you think !

    You are still missing my point. If a game is slow because it is drawing more to the screen than the GPU has bandwidth to handle, then it doesn't matter what technology you use. You could write it in carefully optimised C++, or even hand-tuned assembly instructions, and it would not be any faster at all, because the bottleneck is in the GPU hardware. The only way to optimise in that case is to draw fewer objects, which you can already do in C2.

    This thread highlights exactly my resistance to making native exporters. People identify that the game is slow on weak hardware, specifically call out a case where GPU hardware limitations are the bottleneck, and then ask for native exporters as a solution. In the described situation, the suggested solution will not help. Developing native runtimes to try and fix that case is pure folly.

    As I've always said before, WebGL uses the GPU pretty much identically to a native app. Javascript has some performance overhead, but it's generally not the bottleneck except perhaps in a minority of exceptionally complex games. And with modern devices like the iPhone 6S benchmarking close to laptop CPU performance and continuing improvements to Javascript JIT compilers, this overhead is becoming even less significant. Were it a significant problem, something like WebAssembly would solve it in a far more practical and portable manner.

    Anyway few people seem to understand the hardware issues involved here, so I guess we will face continuing calls for native exporters to fix hardware limitations :-\

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Anyway few people seem to understand the hardware issues involved here, so I guess we will face continuing calls for native exporters to fix hardware limitations :->

    You could try and make an example ....

    But then again ... you would throw all your skills into the mix ... which would get you a decent performing game ...undermining the thing you are attempting to achieve

    Seriously though, a good example .... could potentially quench all following questions relating to desires for a native exporter ...

    I think the time spent on making an example would be far less then the time already spent on answering similar questions ... not to mention those not yet asked

  • Is the endless cry for native exporters even because of performance? I thought the issue was 3rd party reliance and the inability to export to consoles and such. Even exporting to Mac and Linux via NW.js seems to be pretty troublesome.

    I have had no problems with desktop performance for retro and HD games alike. I've seem some horribly optimized HD games that still ran very well. There's the v-sync issue of course, but that's not a C2 or HTML5 problem to my knowledge.

    Mobile performance was terrible last I checked, but that was like 3 years ago using CocoonJS or whatever. I'm with Lennaert on this one. Someone just needs to make a good mobile game example.

  • It seems to be a mix of things that keep coming back ; easier exporting processes and deployment pipelines, performance, platform-specific features, etc.

    Most of the proposed "solutions" don't actually fix the problems (cpu/gpu optims when gpu/cpu limited, etc.) or are unrealistic (take ownership of all the device specific exporters, etc.).

    I think jayderyu made an interesting list of ideas to improve the creation and authoring process in a previous post ; that's the kind of things that would make a difference and that I'd rather see in future updates.

  • "I thought the issue was 3rd party reliance"

    Bingo

  • I just give my opinion of non programmer. This was perhaps already been said, but it's never too much to say it again.

    The main reason, which is sufficient in itself for a built-in exporter : do not go through a third-party software and manage everything in Construct. At least for mobile devices. Currently it's a hell to manage and I hate the thought of having to send my project on a server so that it be converted.

    If in addition we take into account the fact that some of these converting sites forces you to use their splash screen (which makes users believe that it is not you who made your own game) there is more to consider : Construct users need a built-in exporter. Once this is in place, we can discuss performances or whatever...

  • norab: You can use Cordova directly through command-line.

    http://cordova.apache.org/docs/en/5.0.0 ... 0Interface

    Of course, at first, it's a little overwhelming because you need to install every dependencies like

    Android SDK to compile for Android, .NET Framework to compile for Windows, etc.

    But I found that once that's done, it's easy to create a batch file that will compile the project easily.

    The cordova command-line interface is very easy to understand (check the link above).

    I never had to use Intel XDK again. <img src="{SMILIES_PATH}/icon_e_wink.gif" alt=";-)" title="Wink">

  • Why do we need native exporters:

    1. CPU bottlenecked games will run much faster.

    P.S. 80% games are CPU bottlenecked and only 20% are GPU bottlenecked.

    P.S.S. I have already showed you many cases of such games and proved my opinion.

    2. We will not depend on third party exporters

    P.S. I understand that we will still depend on other third party tecknoligies, but It is not the same.

    3. Export will be one-click.

    P.S. It is not the main reason, but it will be cool to spend less time for boring things.

  • Why do we need native exporters:

    1. CPU bottlenecked games will run much faster.

    P.S. 80% games are CPU bottlenecked and only 20% are GPU bottlenecked.

    Where do these figures come from?

    Please quote source.

  • > Why do we need native exporters:

    >

    > 1. CPU bottlenecked games will run much faster.

    > P.S. 80% games are CPU bottlenecked and only 20% are GPU bottlenecked.

    >

    >

    Where do these figures come from?

    Please quote source.

    The source is experience of developers from russian community.

    I am speaking from community, not from myself.

    The most professional russian developers decided that I should speak from the whole russian community.

  • i feel like you're a troll.

    first of all - i don't know how "good" those developers are, but obviously not "the most professional" if they can't make a game that runs on mobile. also the most professionals go for C++. and third of all - CPU bottlenecked? WHAT ARE YOU EVEN TALKING ABOUT?

  • Yes but if you have percentage figures then one assumes you have data to back it up.

    Unless it's anecdotal, which is useless.

  • This thread's gone its course, I'm out.

    Let me know if we start talking about secret handshakes though.

  • first of all - i don't know how "good" those developers are, but obviously not "the most professional" if they can't make a game that runs on mobile. also the most professionals go for C++. and third of all - CPU bottlenecked? WHAT ARE YOU EVEN TALKING ABOUT?

    I am talking about creator of http://c2community.ru/ and developers, which created the most popular games.

    Sorry, but I guess you are a troll or just a developer-beginner.

    Otherwise there is no reason to fight against native exporters.

    Your arguments againsts native exporters are as nonsense as arguments that horses are better than cars.

  • Perhaps have those Russian developers here post themselves with their findings, that would support their cause a lot better I suppose.

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