Native Desktop Exporter for Construct 3

0 favourites
From the Asset Store
Casino? money? who knows? but the target is the same!
  • I think the html5 is the right way for the new construct3, because in the future, performance and the technology will be bettere than now...I remember when I start to use this software... and I see the difference...

    A native export would be awesome, but if they have to remake everythings.... doesn't make any sense for me....why?

    because there is UNITY (or others engine), and the most of the game made from construct2 are pretty easy to remake in unity...

    for me, the most important thing is to improve the performance and works around it... when you have the performance, you have the power to do what do you want...when you see the fps go down....you have to stop and think...

  • Here's my version of Somebody 's C2 example done in CC (R2, which is on the sourceforge)

    https://dl.dropboxusercontent.com/u/471 ... arison.cap

    Strangely, the move at angle didn't work so I just set them all to a random position when clicked.

    In this at 1280x720px I get a solid 37FPS and above even if I'm clicking like crazy and 40+ FPS when not clicking.

    Edit: Here's the executable, but it doesn't show FPS in top (smoothness is definitely noticeable though!)

    https://dl.dropboxusercontent.com/u/471 ... ompare.exe

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • [quote:1qzm51v9]IMO they should just scrap support for large projects and focus on small/midscale projects, and rapid prototyping.

    Yeah get rid of large scale support )

    People are trying to make this happen, but it won't happen. It's a non-issue. Scirra will focus on the editor for C3, which will make large scale projects more viable. Meanwhile, mobile will continue to advance, and by the time c3 comes out, performance will be excellent (in my opinion, it already is). We can have our cake and eat it too, without sacrificing any significant percentage of the userbase.

    People are all defensive when talking about native exporters, when most benchmarks prove they bring no benefits. Modern (non-potato) mobile devices can already support thousands of objects at once, what difference is there between 10000 and 11000 objects? Is a 10% boost (and by the time c3 comes out, it might be a 5% difference due to JIT and GC improvements) worth years without new features? Is it worth the possibility that feature parity might never come AT ALL (look at MMF and GM)?

    The bugs with third party exporters are dwindling every month, I get that you're unhappy, but Scirra is doing everything they can to mitigate similar issues in the future (as mentioned repeatedly by Ashley), including support for different NW.js versions (that should probably be extended for all other exporters as well, IMHO).

    Also, people are not even considering the potential changes in the landscape. MMF wasted a ton of man-hours developing exporters for XNA (now extinct) and Ouya (which has a laughable marketshare). The java2me exporter (once the only viable option for mobile gaming) is defunct as well. There is a barebones flash exporter, but flash seems to be going the way of the dodo as well. The waste of development time has gotten so bad that MMF, with all their mobile exporters, doesn't even show up here.

    The main competitor to Construct 2 right now is Unity2d, and the reason lies almost solely due to unity's superior workflow. If C3 delivers, this hurdle will be cleared, which makes the editor an obvious strategic choice for improvement.

  • Here's my version of Somebody 's C2 example done in CC (R2, which is on the sourceforge)

    https://dl.dropboxusercontent.com/u/471 ... arison.cap

    Strangely, the move at angle didn't work so I just set them all to a random position when clicked.

    In this at 1280x720px I get a solid 37FPS and above even if I'm clicking like crazy and 40+ FPS when not clicking.

    Cool, I cannot check it out, but just a thought - if the move at an angle lacks the angle computation element perhaps just make the random positions based on angle? So we have the same amount of computations. Still, sounds like it does show the difference.

    Edit: Tried the exe... so smooth.

  • Thanks for trying it, if you have a moment could you try this: https://dl.dropboxusercontent.com/u/132 ... index.html (Press/hold right) - another simple thing I get steady 45 fps on.

    I get fps between 59-61, (mostly 60, less frequently 59 and rarely 61), on both Chrome and Firefox. IE11 however doesn't work, I get a black screen!

  • Okay uploaded new Cap and EXE Somebody

    Uses these events:

    Also Fimbul, the performance difference for me between CC and C2 based on the simple (and most recent) example that Ashely is using gave me performance that was 67% slower with C2, that's not negligible, and my hardware is about average for Steam's results from the hardware survey (and probably people with way better/the best machines are the only ones who aren't embarrassed to send that data <img src="{SMILIES_PATH}/icon_razz.gif" alt=":P" title="Razz"> ). Look further back in this thread for that post of mine, I linked it 2 times as well as someone else has linked it too I think.

    Edit:

    Cap file -

    https://dl.dropboxusercontent.com/u/471 ... arison.cap

    EXE file (NO FPS IN CAPTION) -

    https://dl.dropboxusercontent.com/u/471 ... ompare.exe

    Running from the cap file I get a solid 45/46 FPS even with clicking like crazy, so setting them to random positions was even slower than a more-accurate one to Somebody's C2 example <img src="{SMILIES_PATH}/icon_razz.gif" alt=":P" title="Razz">

    Compare that to the example in C2 that Somebody made:

    https://dl.dropboxusercontent.com/u/132 ... index.html

    With events:

  • Jayjay Still tangibly smoother - just like I remember. You could probably crank it up to twice or so and still get decent fps while a browser would probably crawl.

    Thanks for making the test.

  • Fimbul

    Agree, most of issues are performance, but this will happen when project was done with bug free. How to make whole project complete is the next topic in C3, to make it more easier.

  • Somebody , definitely! and I think so too, maybe even more depending on the CPU of the person testing. For fun I applied a blur-horizontal FX to each individual sprite and that made it choke (3FPS), but I tried again instead applied to the whole layer (I added blur horizontal and blur vertical to that) and still got 45+ FPS the whole time.

    No problem

  • Jayjay

    Even clicking like crazy, the .cap still stays at around 147FPS for me. Damn

  • Somebody - thanks for the .capx. Since you provided a real project I was able to profile it and optimise it. The next build should be somewhat faster (not sure how much though).

    It would be difficult to optimise further, but I would point out spawning 9000 objects on-screen and running events on all of them seems to me to be something of a special case. It stresses the event engine pretty hard.

    Is this an argument for writing native exporters? IMO, no - I'd much rather rewrite the core engine in asm.js, which should bring it up to native-like speeds, but still running in a browser, and still with full compatibility and portability.

    For the record if anyone ever has .capx examples like Somebody shared I'm always curious to take a look and do any optimisation work possible. I got it running faster based off that .capx, but I very rarely get sent such examples - it's page 12 of this thread and that's the only one I've seen so far.

  • Is this an argument for writing native exporters? IMO, no - I'd much rather rewrite the core engine in asm.js, which should bring it up to native-like speeds, but still running in a browser, and still with full compatibility and portability.

    I agree with that, and would really love the core in asm.js

  • [quote:36tinaoa] I get that you're unhappy, but Scirra is doing everything they can to mitigate similar issues in the future (as mentioned repeatedly by Ashley), including support for different NW.js versions (that should probably be extended for all other exporters as well, IMHO).

    Trivial sprite test have proved nothing more than inconsistency from what I have observed... It's all over the board.

    Not really unhappy, I love C2, and that is why I am expressing concern... Rather, I'm frustrated at the lack of concern for desktop publishing, and this idea that everything is fine as long as you don't take on a large scale project. How many exporters have come and gone? It's a pattern and it's not sustainable IMO. I can guarantee there are many like me just sitting idle on their projects due to exporting concerns. Not everyone here is making flappy bird clones. And the website doesn't state that either...

    With that said, I totally agree that it will in fact get better as HTML5 advances. (In 3 years of being here I've witnessed it) I don't want to take away from the fact that C2 and Scirra team is and are awesome. Just expressing ( what I feel ) are valid concerns.

  • Somebody - thanks for the .capx. Since you provided a real project I was able to profile it and optimise it. The next build should be somewhat faster (not sure how much though).

    Mega-awesome! Thanks! Would that be faster for extreme cases like this or in general?

    It would be difficult to optimise further, but I would point out spawning 9000 objects on-screen and running events on all of them seems to me to be something of a special case. It stresses the event engine pretty hard.

    Both yes and no - like I mentioned Geometry wars would be a good example of this sort of thing. I'll be sure to test the next build even further with input events and such.

    I'm not sure how much this has to do with optimization, but another special occasion is rapidly spawning fast moving objects, such as bullets in shmups. It's probably more of a question of approach, but it would be interesting to, for example, adjust a sprite's position if it's spawned in a "Every (very low value) seconds" and detects that a tick has skipped, for example and thus sort-of "speeds up" for that single tick to compensate.

  • > Is this an argument for writing native exporters? IMO, no - I'd much rather rewrite the core engine in asm.js, which should bring it up to native-like speeds, but still running in a browser, and still with full compatibility and portability.

    >

    I agree with that, and would really love the core in asm.js

    +1

    Are their issues with Node and asm.js on exporting?

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