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.

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

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

I wasn't annoyed by the full screen - it was probably just a coincidence but here's what I meant by that: As soon as the page loaded and I saw the full screen button I went to full screen. Then I couldn't tell if it was loading or if it was stuck. So after pressing buttons and clicking around didn't do anything I exited full screen and it went to the next part (the map I think). So I went back to full screen but then I couldn't tell if the map thing was an intro or if it was looped and I was supposed to choose something. I exited full screen again and started clicking around like a mad man and the skip intro prompt popped up and I accidentally clicked it.

I've used some programs, games, etc that seemed to get stuck in full screen mode sometimes so that is why my instinct was to exit full screen - but it could have just been a coincidence on the timing.

I will try it again later and maybe I'll reach the top . . .

Hey, I like it! It was intriguing - nice concept.

I had no clue what was going on at first but I like that - I don't like it that a lot of games nowadays lay out everything for you. I didn't make it to the top - I'm not in a patient mood right now so maybe I'll try again later.

One thing I would mention was the loading or intro - not sure which it was - but I couldn't tell if it was loading or I was supposed to do something. I had to exit full screen and click around. If it was just loading you might want to put a bar or percentage up so people know - I almost left and didn't play. I hit skip intro on accident because I was trying to already clicking around trying to get to the game.

Thanks!

Don't get fooled by the first impression, it gets tricky! Haha, don't have the patience right now to try and beat it, maybe later.

Good job!

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?

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

Question about reducing image size:

If I loaded a larger image than necessary for a sprite, if I just look at the sprite size in the properties bar then open up the image, resize to match the sprite size (then have to change the sprite size back to original as automatically reduces it), will this reduce the filesize? Or will the original higher quality image be retained?

If quickness is your deciding factor this seems to be the way to go, but wanted to verify this first so I don't mislead others.

Also, with the image export options, if choosing to reduce quality (jpeg and lower the quality rating) will that not be seen until export? That seems like a lot of hassle to play with that number and export each time to see if the quality loss is acceptable.

Sorry about asking questions and not giving any definite answers but thought on topic and may be helpful for the discussion.

Thanks

you could simply have a sprite on the main character like a zone of influence and when the enemy overlaps with it, it triggers the action

That sounds easy to setup and would probably work out well. Although I will probably not go that route as I am trying to optimize by reducing unnecessary objects/sprites. I know this is only one more sprite but from what I've read I think the test for overlapping is more to process than test of distance previously mentioned.

I always appreciate different ways to solve problems though so thanks for the comment.

Thank you mudmask and StormHo

no need for foreach. if you put if dist (x1,y1,x2,y2) it will calculate towards each instance of enemy. and jump will trigger when <100 dist. if you want it to trigger once - add trigger once.

From my understanding, and the posts above, this would cause the action to apply to all instances, therefore the ones not within the distance would all jump when one gets close.

Whoops, I can't post URLs . . .

I guess PM me for the URL?