Construct 3 - many questions (native exporterts)

  • There is a simple way to solve this debate:

    Just use the Scirra created demos to test with on mobile devices.

    If they work well and run smoothly at 60fps then it is our code that is at fault.

    If not, then it is Scirra's engine/wrappers that are at fault.

    There it is. Simple, SOLVED.

  • I always ask to see CPU-bottlenecked .capx projects. Usually either nobody sends me any, they send such appallingly inefficiently designed games it is obviously just bad design, or they are actually GPU-bottlenecked. Please do send any good examples of CPU-bottlenecked games, so I can investigate if our engine needs optimising. I rarely see such examples though, which is why I have concluded most games are not CPU-bottlenecked.

    Ashley

    Well, most games that use physics, particles and pathfinding are CPU-bottlenecked.

    If it is really necessery I can send you .capx of my physics puzzle game "Tap & Clapp"

    But it's my commercial game that's why I want you not to send it to anyone else.

  • Could you make Bad Piggies to run on 3 year old android devices at a steady 60fps using c2? The answer is no; wrapped html5 is not as fast as many other alternatives.

  • Well, most games that use physics, particles and pathfinding are CPU-bottlenecked.

    If you're using asm.js physics, there's not much more that can be done to make it faster - it should already be about as fast as physics in a native engine. Pathfinding runs in a web worker in parallel to the game so even if it's slow (and generally it's still reasonably fast) it should have no impact on the framerate. Particles are already highly optimised and even very large effects should run well (this demo runs nicely on many of the mobile devices we have in our office, with ~800 particles).

  • That was first demo I tried on Samsung Galaxy and work fine

  • If you're using asm.js physics, there's not much more that can be done to make it faster - it should already be about as fast as physics in a native engine.

    Ashley

    It works well in HTML5 games, but it works bad after export via IntelXDK and Crosswalk 10.

    Particles are already highly optimised and even very large effects should run well (this demo runs nicely on many of the mobile devices we have in our office, with ~800 particles).

    Ashley

    It runs 40 FPS and 60% CPU on my mobile device, but it is HTML5-demo.

    Export this demo to android via IntelXDK and Crosswalk 10 - I guess, you will get about 10 fps or even less.

  • People don't see the importance of optimising their code. It's easy to get things run smoothly on a PC, but every single % of CPU counts on Mobile. I was struggling with the same problem in my early stages of development, but as I learnt many tricks along the way my game now runs super smooth on mid range phones as well, even if my game is isometric multiplayer with Z ordering & collissions and tons of objecs on in the layout.

    Many people just assume that if the game works on your desktop it will work on their phone, and are blaming the wrapper for bad performance. Usually it's bad code and lack of optimisation.

    There are some tutorials and tips on the site on how to get your performance up, but i think the main issue is the lack of general knowledge on how the event system works that people just assume that it will work on phones as well.

    I think we would see a lot of more good C2 made games with good performance on various app stores if people knew what they were doing, instead of blaming wrappers/C2 and ditching their projects.

    Some more general "good practice" tutorials would be nice working with the event system, and understanding of how code actually works. It's easy to make things happen in C2, but it's hard to make them happen efficiently.

    I agree with this. Based on most complaints here the common problem seems to be physics. Almost everyone posting issues is using physics in the game so maybe physic based games are too demanding for low-mid level mobile devices atm.

    I haven't done mobile games in a while. But this is the first game I ever made in C2 and it ran pretty good on most devices then. Exported with the old cocoon cloud with the flashing splash screen <img src="{SMILIES_PATH}/icon_e_wink.gif" alt=";)" title="Wink"> I have no idea on how it runs now so feel free to try it on an older device.

    https://play.google.com/store/apps/deta ... appz.dropz

    I am testing the new cocoon.io and comparing it to the XDK export right now to see how big of a problem the performance is.

  • c2 optimization is hard especially for mobile look at this game i made (i use physics and alot of stuff but no lag ever !)

    (with c2 if you make a game in 1 day you must spend 2 day for optimization !)

    play.google.com/store/apps/details?id=rts.mahdi.heydarzadeh

    but if you want to make a html5 game i say c2 is the best

    if c3 be nativ or be like a asset for unity that can sell so much

    Tried your link but didn't work.

    What regions have you published this in?

  • > c2 optimization is hard especially for mobile look at this game i made (i use physics and alot of stuff but no lag ever !)

    > (with c2 if you make a game in 1 day you must spend 2 day for optimization !)

    > play.google.com/store/apps/details?id=rts.mahdi.heydarzadeh

    > but if you want to make a html5 game i say c2 is the best

    > if c3 be nativ or be like a asset for unity that can sell so much

    >

    Tried your link but didn't work.

    What regions have you published this in?

    it was for iran ! sorry i will publish that for other countries in future

  • "with c2 if you make a game in 1 day you must spend 2 day for optimization !"

    lol - sorry but can't find any other phrase to describe that statement.

  • I agree with this. Based on most complaints here the common problem seems to be physics. Almost everyone posting issues is using physics in the game so maybe physic based games are too demanding for low-mid level mobile devices atm.

    I haven't done mobile games in a while. But this is the first game I ever made in C2 and it ran pretty good on most devices then. Exported with cocoon with the old flashing splash screen <img src="{SMILIES_PATH}/icon_e_wink.gif" alt=";)" title="Wink"> I have no idea on how it runs now so feel free to try it on an older device.

    https://play.google.com/store/apps/deta ... appz.dropz

    I am testing the new cocoon.io and comparing it to the XDK export right now to see how big of a problem the performance is.

    Please keep me posted on your cocoon.io vs XDK results. Very curious which gives better performance.

    Anyway, it's kind of sad to see they can differ that much, or get even lower performance than playing your game in your stock phone browser. It should work way better in my opinion.

  • tunepunk I will.

    And to clarify. The game I posted is compiled with the old cocoon cloud and not the new cocoon.io which seems to be much faster than the old one.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • 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

    .CapX

    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.

  • User Dex from c2community.ru created a very cool benchmark - it will help us to compare HTML5 and APK performance.

    HTML5

  • Benchmark is fine but:

    • it doesn't use bigger textures or sprites (256x256 at least),
    • sprites are solid, they lack alpha channel, gradient opacity etc. (except fade)
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)