Halfgeek's Forum Posts

  • delgado Yes indeed it is definitely the engine processing your entire layout, thats why its 37% of your CPU, and draw calls (on screen objects) are low at 10%.. behaviours of objects offscreen but on the layout are still functioning, if you got them all active it would definitely explain that.

    Perhaps disable the behaviours first, and make a trigger: If Object is onscreen (or check for X axis/location), Enable Behaviour.

    Another thing is to disable Collisions on all your objects, and have it Enable when its visible/onscreen with a trigger.

    Lots of tweaks and stuff you can do to improve performance. C2 is very easy to use but it takes some practice to optimize it for mobiles. Good luck!

  • If your off-layout objects are affecting performance, it is a serious issue.

    Ashley could help here if you send your CAPX, without it, nobody can figure it out. It feels like its rendering everything on your entire layout all at once, and its just so slow. Here's a shot from a more complex scene, lots of explosions and particles, 15% is about the max I see on CPU.

  • How can your scene have 3682 object? Unless you have each grass blade as a separate object, and with some behaviour as well? 37.3% of CPU cycles eaten by the Engine alone is MASSIVE.

    I have a Core i5-3770K and my game has like 5 to 10% TOTAL CPU on the PC. I have over 3,600 events in C2... let me capture a debug shot for you asap.

  • jayderyu

    If what you say is indeed true, then certainly PIN behaviour is a big bottleneck in performance. I do not see that kind of performance drop using other behaviours, for sure not sine, bullet, fade, spin etc, especially if they are disabled.

    delgado

    I just tested your game, there is definitely something wrong with your code or implementation within C2, because it is too simplistic for it to be running at 12 FPS on my quad core Tegra 3 tablet. When you run it via C2/Chrome, run in debug mode and look at the CPU usage, see where the bottleneck is highest at. There must be an event group in your code that's causing it, maybe a repeat/if/else trigger chain thats firing the entire group every tick by accident.

  • Yup, just a simple textbox really mess up performance in CocoonJS.. lot of stutters whenever it pops up.

    Crosswalk seems fine with it though.

  • Cool game, very smooth controls and I like the gun auto aim, is that turret behaviour?

    Also, there's a small bug, when your game finishes, the sound is played endlessly. You may need a Trigger Once condition in there.

  • Amazing game, I wish you and your team all the best!!

  • Fonts are based on the OS, its not embedded in your exported game. If the device does not have that font, it will default to Arial (im my own example anyway).

    Lots of users use Spritefonts for better performance as well as ensuring it displays properly on all devices.

  • All the issues are solved except: Ads & Audio (only on some devices, requires headphones for proper audio).

    I know they are fixing Audio in the next Crosswalk update. And AdMob is a priority.

  • ByR please take this APK: https://dl.dropboxusercontent.com/u/447 ... signed.apk

    I have just tested this APK on my Tegra 3 tablet, its stuck at the blinking ludei logo.

    I see they have still not fixed this simple bug after over a year. And the App doesn't load btw.

    delgado

    I cannot test your game so I cannot see how complex it is, but my own game, 440MB ram required with CocoonJS, >3,600 events in Construct 2:

    Runs absolutely perfect even on older dual core phones. Intel XDK/Crosswalk is smoother than CocoonJS for my example, because I originally went with CocoonJS for this big game so I can compare both. Crosswalk reduced the ram requirements down to 250MB, as well as taking about 10 seconds to load with a progress bar near the finish instead of 40s with a blinking ludei logo.

  • 1. Do not ever use WebGL shader effects in Construct 2 for mobile games, it will cripple performance, I get the impression it is not hardware accelerated by the compilers.

    2. Use minimal Physics Behaviour.

    3. Don't use the PIN behaviour it cripples performance on mobiles. Also do not use rotate or angle every tick.

    There's a few others, but most functions in C2 are really efficient and fine on mobiles, but a few are to be avoided.

    I am not sure how complex your game is, can you do a youtube video/demo?

  • Lots of news, all of it good thanks IntelRobert. I think enabling monetization,ads etc. for C2+Crosswalk through plugins is going to be a real deal clincher for many, it's a little bit of a problem at the moment...

    Yes indeed, XDK/Crosswalk is already so good with performance as well as memory management, that last leg with AdMob is going to make it clearly the only "close to perfect" option for Android.

  • Not only can it run, it runs it 60 fps on most devices, anything Tegra3 or Samsung S3 onwards perfect smooth like on PC.

    On older devices, example: HTC Incredible S, it runs around 40 fps, perfectly playable.

  • Well the best is to streamline everything in Construct 2, so that it has the essential function people all need when they develop mobile games. Currently lots of plugins here and there, and many don't even function in CocoonJS or Intel XDK.

    But it would require a bigger development team I think.

    Crosswalk is very good now, it needs a few additional features and its A+ for Android. If only we had a great compiler for iOS... CocoonJS still has massive flaws.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Cute. But I thought Google and iOS stop accepting games with Flappy in it due to spam and clones (really!)...