Tried to debug and increase fps but have failed all day . .

Hello,

I would still consider myself at the beginner stages of C2 and most of the projects I have been working on have been very small. Therefore I have not required much use of the debugger and haven't spent much time optimizing.

I recently exported a project and seems to run good on computer and my iphone6, but when I pulled it up on my ipad was not running smoothly. I have spent most of my day today trying to optimize and make it run more efficiently, reading everything I could find on Construct website (Tips for Performance, Optimisation: Don't waste your time, pages on the debugger, Ashley's blog posts, searched forums, etc.). Most everything I read made sense and seemed helpful but I spent time implementing nothing I have done seemed to increase the fps when debugging. Some of the changes seemed to even make it slower.

Anyway, I just seemed a little confused on what to focus on and what to try next. The performance stats don't mean much to me as I don't have much experience to compare them to. I know the goal is 60 fps, mine have spent most of the time between 10-24. I haven't read anything on average CPU utilisation. I have read to try and keep image memory under 100mb and Objects under 1000, so this seems fairly small project compared to those numbers.

I reduced objects from just over 100 to in the 60s by removing unnecessary ones and creating a tilemap for repetitive ones.

I removed all of my collision check events by using compare X or Compare Y events.

This project does use physics but besides the immovable objects (mainly the floor) there are only 8 physics objects. I have tried destroying some in the debugger but does not increase the fps.

7 physics objects are hinged together with joints, I'm sure that takes some cpu, but not sure what can be done to make it reduce it in that aspect. Would it help if I tried to get all of the objects masses close to each other?

The next thing I was going to try is to reduce as many image sizes for sprites that I can (a lot of it is pixel drawn so reduction of quality not a concern). But I didn't know if that would help fps at all, just the download size.

This is a left to right game. The other thought was instead of having everything laid out would be to make events to create everything at certain points. Like I said I am still beginning and that is one of the next things I want to look into - instead of laying everything out in the layout figuring out how more complicated games are built. But as nothing off screen in this game is really moving or active I doubt that would help as they are all 'asleep' and not being rendered.

Sorry for the long post but wanted to give as much information as possible so anyone wanting to help may be able to spot a problem area.

Here are some stats copied from beginning of debugger:

Performance

Frames per second 11 (90.9 ms/frame)

Est. CPU utilisation 47.1%

Est. image memory 16.8 mb

Renderer webgl

Object count 64

Collision checks/sec 0 (~0/tick)

Poly checks/sec 0 (~0/tick)

Moved cell/sec 0 (~0/tick)

Cell count 0

Moved render cell/sec 0 (~0/tick)

Render cell count 0

The stats at the bottom of the project read:

Approx download 3.8mb memory use 21.2mb Events 51

How large are your sprites being drawn? Mobile GPU's -- especially older ones -- tend to have low fillrates, which can be maxed out by drawing even just a handful of large sprites(note that I mean the size at which they're drawn to the screen, not texture dimensions). Also, which version of the iPad are you testing on? It's quite possible that it's simply too old.

How large are your sprites being drawn? Mobile GPU's -- especially older ones -- tend to have low fillrates, which can be maxed out by drawing even just a handful of large sprites(note that I mean the size at which they're drawn to the screen, not texture dimensions). Also, which version of the iPad are you testing on? It's quite possible that it's simply too old.

It is ipad mini, I think the first one that came out about 3-4 years ago. That had crossed my mind that it just isn't advanced enough. My dad tried it out on his old ipad and old Mac and didn't work hardly at all, but those are older than mine.

I do have three large sprites - one the main background and the other two as background switches at the end - around 1000x600. I just read that it might help to divide the large images up into squares - so two 640x640 sprites? Would that really help much? Will it be beneficial to not have the two at the end on the layout and have an event create them? Or will that not help as they aren't being rendered until on screen?

The other sprites are all under 300x300 sized. Does that answer your question?

All mages are decompressed before rendering to the canvas, so the size they are on disk is only of importance in the final project size.

So for instance, the image you say is 1000x600 would use approx 1000x600x4 24MB of memory just for that one image, although if it needed to be power of 2 aligned, which older hardware requires, then it would need approx. 42MB.

You must be very careful with old hardware and image size.

Useful article from Ashley: https://www.scirra.com/blog/112/remember-not-to-waste-your-memory

do u really even need WEBGL? do u use any effects/blending modes? if u dont disable it ... that will save u some FPS and CPU also ... dont do everything on everytick or on blank events... try using the condition to trigger once when needed and not let the engine check for conditions everytick ...move all text objects to when value or text needs to be changed and displayed ... destroy all sorts of objects that needs to be eliminated ... after that ... if u doing graphics in 1080p ... u may want to lower them down... u dont need full 4k images inside a iphone the resolution is not needed to be big... u can have great quality even if ur image is 256x256 or 128x128 the resolution is just resolution ... DPI is something else...

as ur benchmark says Performance

Frames per second 11 (90.9 ms/frame)

Est. CPU utilisation 47.1%

Est. image memory 16.8 mb

image size is huge... lower it down a bit...

image size is huge... lower it down a bit...

Thanks for pointing me towards that as I was able to reduce a lot of the image sizes and I think that helped. If it is still slow because of image size then that is sad because this is not a graphic intense game.

I tested with disabling WEBGL and didn't see much affect.

I have four 'cues' as I call them that check where the character is by comparing x. That checks every tick but I wouldn't think there is much processing to save there. They are all four being checked at the same time so I guess I could have it check for the first one then once past that x marker start checking for the next one. With only four I doubt I would see an impact but let me know if wrong.

Not up to 60 but consistently around 40 - I'll try on ipad again now. Does the debugger take up considerable amount of CPU for everyone? I feel like most things I've tried get choppy in the debugger even if perfectly smooth when previewed.

Performance

Frames per second 38 (26.3 ms/frame)

Est. CPU utilisation 42.6%

Est. image memory 6.8 mb

Renderer webgl

Object count 64

seems about right however all my image memory on a 800 events game has 1.2 mb image memory... tops ... with high quality sprites... something u do there that heavy's the image cache... however on my projects total download memory is around 10 mb... u can see those stats at the bottom of c2 ... cpu utilization u can lower it down by tweaking and optimizing ur events... i did a gain of 5-10 -20 fps by re arranging the entire events-sheet... maybe take a look at what ur events triggers?and when... and yes debug mode uses more cpu about 20% more then what actually the app uses... which is weird... so based on ur performance benchmark ur app should be in the optimal running area... and u should have 45/50+fps ...dont worry if ur app isn't running at 60fps.. it will depend also on the power the devices used have

All mages are decompressed before rendering to the canvas, so the size they are on disk is only of importance in the final project size.

I don't have any mages though - it's not that kind of game . . . jk

So for instance, the image you say is 1000x600 would use approx 1000x600x4 24MB of memory just for that one image, although if it needed to be power of 2 aligned, which older hardware requires, then it would need approx. 42MB.

You must be very careful with old hardware and image size.

Useful article from Ashley:

I read that article before and just reread it. I get what they are saying with the old processors and the power of 2s. But would it be beneficial to break up the large images into power of 2s myself? So I could cut into two 640x640 images. I would still be wasting some space myself but not as much - is it worth the trouble?

There is something else I am confused about:

In Ashley's "How the Construct 2 WebGL renderer works" Blog post I read:

I'm not sure why, but people occasionally wonder if off-screen objects are rendered and if it would help if they were made invisible. Of course off-screen objects are not rendered and making them invisible will do nothing apart from needlessly complicate your events.

But of course it will be loaded into image memory if it is part of the layout. So if I have a large image at the very end (it is the finishing backdrop) how much will it affect the fps at the beginning of the game? It is in image memory but not rendered, which Ashley has mention the rendering accounts for about 90% of the processing.

And there is no point in having it not at the end and spawned before arrives at the end as it will still be in image memory, correct?

Thanks

Don't command writing text objects every tick - I'm guessing, if you're not using sprites. Setting the text in a text object takes up a lot of processing time....

seems about right however all my image memory on a 800 events game has 1.2 mb image memory... tops ... with high quality sprites... something u do there that heavy's the image cache... however on my projects total download memory is around 10 mb... u can see those stats at the bottom of c2 ... cpu utilization u can lower it down by tweaking and optimizing ur events... i did a gain of 5-10 -20 fps by re arranging the entire events-sheet... maybe take a look at what ur events triggers?and when... and yes debug mode uses more cpu about 20% more then what actually the app uses... which is weird... so based on ur performance benchmark ur app should be in the optimal running area... and u should have 45/50+fps ...dont worry if ur app isn't running at 60fps.. it will depend also on the power the devices used have

I am not too worried about getting this game running perfectly but more so figuring out things I am doing wrong before I start on bigger projects. So that worries me that my tiny game is that much larger in image memory than your large projects. What is the best way to figure out what is heavy in the image cache? Is exporting the project and just looking at the image file sizes a valid way of checking that? Those are compressed sizes though, correct, so would have to remember which images I changed compression settings on?

Is opening the image in Construct's image editor and scaling down the image work as well as in an outside program? They both will reduce the number of pixels, right? Or does Construct save the original image somewhere or something.

Thanks again, I would really like to figure this out so when I start my next project I can get things right from the beginning.

you said" Is opening the image in Construct's image editor and scaling down the image work as well as in an outside program? They both will reduce the number of pixels, right? Or does Construct save the original image somewhere or something."

i think what u miss understand is the memory usage of image sizes... lowering the image size or the sprite in the visual editor or when u place it in the layout that u see or prebuilt is not going to change the actually image weight... so what u need to do is ... if u exported as png jpg or whatever use the auto cut space out from image editor c2 has ... it will automatically adjust the image transparent parts which are known to heavy the image memory... 2nd thing re-scale the image upon import in c2 in the animation editor where u place ur frames... not only in the layout part ... cause if u only re-scale in the layout that wont change the actual image weight ... which the engine still has to resize from the high quality frame u use ... hope u understand..... i have a bit of work to do il upload a schematic later if ur interested...

try this... make the sprite frames in the object animation editor.. as small as possible then see if the app runs faster... if it doesn't then its something else u might missing cant really say if i dont see ur capx

I reduced the size in the animation editor, not just in the layout (I mistakenly referred to it as image editor above) and always reduce as much white space as possible

One thing i noticed in my game was that optimising the event sheet gave me a lot of FPS boost. Here are some of the things i did that had most impact.

* If you have a lot of events, place them in groups and enable/disable the groups only when needed. The less events running at the same time the better.

* Using functions and "once when true" can save some CPU, as well as using "every X second" instead of having events run every tick.

* Use Sprite fonts instead of regular text object. Can do a big difference if you have a lot of text.

* Use the condition "Is On Screen" when possible, so the Event's won't pick stuff that is not on screen. Very useful in many cases.

In general. Try narrow down the event object picking with conditions as much as you can, and structure the event sheet so that you can turn off and turn on groups of events when needed.

One thing i noticed in my game was that optimising the event sheet gave me a lot of FPS boost. Here are some of the things i did that had most impact.

* If you have a lot of events, place them in groups and enable/disable the groups only when needed. The less events running at the same time the better.

* Using functions and "once when true" can save some CPU, as well as using "every X second" instead of having events run every tick.

* Use Sprite fonts instead of regular text object. Can do a big difference if you have a lot of text.

* Use the condition "Is On Screen" when possible, so the Event's won't pick stuff that is not on screen. Very useful in many cases.

In general. Try narrow down the event object picking with conditions as much as you can, and structure the event sheet so that you can turn off and turn on groups of events when needed.

Based on Ashley's Optimisation: Don't waste your time where he states only 10% is logic I followed his logic/events tips on there, similar to some you just mentioned, and then focused on image size.

I think a lot of the cpu is because I am using physics but I will still test out things in other areas to see if it helps.

Thanks for the tips! I will try those out and keep in mind for future projects.

.. if it doesn't then its something else u might missing cant really say if i dont see ur capx

I don't mind sharing capx but don't have enough rep to post link or send PM so not sure how...