Ladies and Gents,

For those that have made intros to their games - which way do you prefer?

Such as:

Video

Full Screen Sprite w/animations

Long event that starts on load

I think it is always best to put in separate layout and give option to skip intro (especially for repeat users) , but past that it seems all personal preference. I haven't made a video intro but have the other two ways I listed, each with their pros and cons. So for those that have made intros to their game feel free to post your experiences, pros and cons, tips, etc.

Thanks

i did take a look inside... ... have a great day hope it helped u ..

Thank you so much for taking a look at it and all the comments. I really do appreciate it. That's weird such a difference in debug mode - maybe difficult to track and report all the physics and physic joints.

Now I guess I can move on without feeling like I was missing something huge and gave up.

There are two image files that are HUGE after export even though I tried to resize. I may try resizing in GIMP and reloading completely because one is getting pixelated already but file size isn't small - feels glitchy.

>

> > .. 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...

>

Export as a single file .capx and host it on one of the free hosting sites provided by the likes of Google, Microsoft, Dropbox etc.

Place the 'publicly accessible' link here. To bypass posting restrictions, just add an unusual character in the URL, i.e..

> htt*p://*www.mysite.com/mygame.capx
[/code:3tny5ujt]

Didn't want to get in trouble for bypassing their posting restrictions . . . but since I can blame it on someone else now here's the capx:

***https://www****.dropbox.***com/s/ukmxt5t93pj9j8o/Dempsey2SingleFile.capx?dl=0***

Maybe this is as good as it gets for projects containing physics elements - but if so then I will stay away with any physics behaviors when targeting mobiles.

— - if you want to take a look and let me know if you still think images are the problem or you see something else.

Anyone else that wants to take a look feel free.

Like I said before, my goal is to learn from this - so even if you see a problem that is only small please let me know so I don't repeat it on a larger scale in larger projects.

Thanks all!

.. 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...

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.

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

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!