You could also use the system action "Create object".

Normally creating and destroying object without reusing them is not that great for HTML5, but C2 behind the scene recycles the objects, however I still think it is better to have the window created once and to reuse it, but that is not a big deal at the end for that.

EDIT: Also opacity = 0 isn't slowing down the device more than opacity = 100 I think, but setting it to invisible tells C2 to skip entirely the drawing on screen, which is better

At the end C2 isn't that limited, the only limitations really seems to be the HTML5 ones, and all in all it is still easier in C2 since it helps a lot and is already well optimised for a lot of things (like the recycling of objects to compensate the lack of direct memory management of javascript, or the bounding box collision checks to prevent doing too many precise collisions checks if not needed)

The letterbox Integer scale, as his name implies, only scale at integer/integer Values (like x1/4, x1/3, x1/2, x1, x2, x3) and will hide everything else.

The letterbox Scale mode will scale the game correctly, however their will still be black bars on sides to compensate the difference of aspect ratio (if there is a difference), but could be enough for you maybe.

The Scale Inner and Scale Outer modes are filling the screen entirely, but requires a carreful and dynamic designing.

czar I can see you use 2 frames as 128x64, it would go to 256x256

Don't bother to make sprites as power of two just use smaller images like 100 x 50 then upscale in editor, let C2 export will work for you.

That is because C2 will add one pixel between each frame, I think a section of the manual describes this, but I do not remember which one ATM.

I see now, I guess C2 wasn't optimised towards that point because it will only spritesheet frames from the same sprite, so I think they didn't consider that to be an issue (since the frames would be most likely similar, it maybe wasn't obvious to see it), Also the frames needs to be cropped in C2 too, so it can interpret them correctly at the end still. However I still see the point, and it could be nice in the long run.

Is it in the road map to have Construct 2 optimize spritesheets? Spritesheets created by Construct 2 are incredibly inefficient. Other engines and tools pack spritesheets by trimming empty space around images and internally keeping note of how much got trimmed to properly maintain offsets. They also try 90 degree rotations on images to optimize space in the spritesheet. The effect is spritesheets that are much smaller. That makes the app size smaller and improves performance because the draw fill rate is also reduced.

Another inefficient area is with duplicated frames in animations. Currently if you duplicate a frame it actually adds a copy of that same frame to the spritesheet. The engine should be smart enough to avoid this.

These two optimizations would reduce the file size, download size and improve draw performance significantly. I sure hope Scirra is working on implementing this. This is standard with all 2D engines and severely limits the size of a game's content without it.

Can we see an exemple where it is really wasteful? (aka an actual exported file on one side and how it could pack it better in your opinion )

To be correct, I think in your case, you want Pollution.X-5*dt*60

Basically, adding dt every tick will have add 1 every seconds at a timescale of 1

Hi everyone,

I am doing a pause function that I want to freeze everything in place. In the past Time Scale set to 0.0 did the trick, but this time I'm noticing that several things continue to move (things that are driven by every tick) such as "Pollution.X-5".

Any reason why some objects would keep moving? I am using tweenlite in some cases, but those are not the problem.. its definitely things motivated by "per tick" actions

you can see the pause problem here http://part12studios.com/temp/BeeGood5/

Thanks!

Caleb

Pollution.X-5*dt will work, and will also keep it at the same speed at lower framerates

I am getting obsessed with programming my games as much "mobile friendly" as possible. (Severe trauma from the last 2 weeks when I'm failing miserably in porting a simple game to mobile, and worried about my other games that are filled with potential memory consuming events)

I know that besides the "Every Tick", there are others that constantly checks every tick if the related objects reaches or not their trigger conditions. For example checking collisions

Is there any list available of these conditions? it would be nice to have one, together with the best practices tutorials and articles sprinkled over Scirra's website/forum.

Basically, every condition other than true triggers (like on created, on function, on start of layout), is checked every tick, the goal is to reduce the calculations needed by the device, collision is a pretty heavy condition compared to check if a variable is equal to something, or if a grouo is active, or something else, and even more if the number of collision to check is big, deactivating collisions and behaviors on objects that aren t on screen (or that don t need them active at a given situation) can help, not abusing of loop also is mandatory (you can still use them in cases they are really needed of course), lowering the number of points in the object hitbox can help too (pixel perfect like collision is rarely needed), some object can have on collision active only one tick out of two without breaking the game, at the end, a synthesis is:

If you are using a behavior, do you really need all it s functionnalities, and if not, can you reproduce what is needed in events only? If so try it

Keep calm, make a scenario in your head, then read the event sheet yourself, from top to bottom, reading the includes too, with that particular scenario, if somethings seems redundant, or looks line it could be avoided, maybe it is indeed.

Functions are great, and can make the code look cleaner, and so is easier to edit and optimise.

Groups help organize events, and they can be deactivated and activated by events, learn what is always needed, and what is only conditionnal, for exemple, the ennemi AI is only active if the ennemy exist, and in some cases, if it is on screen, you could play around with that.

Maths can be pretty heavy when done a lot of times, so try to simplify the calculations if possible.

For a clean work, do not use global variables only, instances variables for instance, local variables for what is only needed in a group for exemple.

Includes can be dragged inside sub events, which can help deactivating an entire event sheet when for exemple, the game is paused.

Workarounds are a bad pratice and so, if needed, should always be isolated inside functions and such, since they can broke pretty much from one version to another.

It is only a concise and non exhautive list of how I do in C2 that works.

I guess using a 9 patch object to do the window, and put a text inside it.

I could be wrong but on load, age_minute, at the moment of the loading itself, could be the same as age_minutes_atsave, since the save function will save all global variables too.

Maybe checking the value of these two variables in the debugger, to see if the problems comes from that.

Thanks for your awnser, that makes more sense now ^^

lucid : I was wondering something, Since the Spriter plugin imports every part as a different sprite, rather than the same, it does not take benefit of C2's spritesheeting (and since if one of them is present, the others are too, it seems kind of weird to me).

Was there a reason behind that, or is it just the way it is?