PERFORMANCE FOR [R-161]!

0 favourites
  • 9 posts
From the Asset Store
Firebase: Analytics, Dynamic Links, Remote Config, Performance, Crashlytics on Android, iOS & Web Browser
  • CLICK THE LINK DIRECTLY BELOW THIS LINE TO DOWNLOAD CONSTRUCT 2 PERFORMANCE TEST FOR R-161:

    drive.google.com/file/d/0B_4xfuagH96ramUxdUlSY3ZaYWM/edit

    Steps to reproduce:

    1. Run .Capx in debug mode. (little bug button next to preview button)

    2. Point the little arrow guy to the right by using the mouse cursor and shoot for 30 seconds.

    3. Simply hold down the mouse button and keep a close watch on the Frames Per Second

    Observed result:

    Incredibly low Frames Per Second on my computer...is yours different than mine???

    Expected result:

    60 Frames Per Second----

    Browsers affected:

    Chrome: Yes.

    Firefox: Yes.

    Internet Explorer: Not Confirmed

    Operating system & service pack:

    Windows 7 64-bit (Professional Edition)

    Construct 2 version:

    R-161

  • It's not a bug, it's bad coding. Add the condition If bullet is not on screen > destroy bullet

  • Burvey

    Great suggestion!! And I would've done that, except for the fact that I need the bullet to continue to hit objects no matter where they are on the layout.

    It's intentional, quite necessary, and it's producing very slow framerate.

    Good to know it was slowing down on your machine too though, thanks for the feedback.

  • In that case my suggestions would be to make the layout smaller or use less bullets. Less enemy objects may help as well. Also another type of trigger for your every tick events may help. Probably all things you don't want to do but it's still not a bug. :)

  • I'll come up with a better .Capx then, a simpler one, according to your suggestions.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Another suggestion, since you want the bullets to destroy anything they hit on that large of a layout would be to check collisions only with objects that are in line of sight of the bullets. I haven't tested that though so I'm not sure if/how much it may help.

    Edit: Also, did this issue only pop up after installing r161? If you run the capx in r160 it runs at 60fps or no?

  • One problem here is that you posted a capx from r161. So...how are we supposed to try it in another version? At least upload a caproj, so it can be modded to boot in an older version.

    Edit: or, better yet, an identical capx from an earlier version.

  • I have:

    1 - Considerably Reduced the Layout Size by 33%. --   

    2 - Greatly reduced the number of Objects Present.---

    3 - Removed ALL 'Every Tick' events; (had to leave update angle & fps).

    • I'd rather not change the firing rate because that is what makes it feel fun, it feels like a Machine Gun and that is what keeps that visceral awesome feeling alive...More Machine Gun, less like a pea-shooter.... :).-

    Here is the simplified .capx...Thanks for your help and feedback...

    drive.google.com/file/d/0B_4xfuagH96rOGZ5M19nTVJNUUU/edit

    (This clearly shows an issue here.)

  • Closing because the problem is you collision test with objects on parallaxed layers. To find out more why this is a bad idea read this blog post: https://www.scirra.com/blog/ashley/6/collision-cell-optimisation-in-r155. In short, this disables the collision cells optimisation, *and* adds extra overhead on each collision check, since it must convert between layer positions taking in to account the parallax before it can even do the fast bounding box check.

    Almost all the CPU is being spent in the last event checking for a collision with 'Enemy2'. There are 70 of these objects on a parallaxed layer. Change the layer parallax to 100,100 and it barely goes above 1% CPU.

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