Identical tiles within the same rectangle are only drawn in one call (as long as the tilemap is setted for that, which is by default), I am not sure about collisions, but I would think than less collision points and less tilemap with collision enabled would be better (enough to make a big difference that justify doing it? Not sure.).

I personnaly remember doing once in a bubble bobble type of clone (never really gone too far yet into it) having different tilemaps (one graphical only with collisions off and one that used collisions but set to invisible), that would let you have a collision different than the graphics if you want it that way.

I remember a time when I could not run some virtual servers with skype, I had to reconfigure skype so it does not use the same port, not sure if this is related though.

If your global variable name is Timing (in seconds)

Use floor(Timing/60)&":"&zeropad(Timing%60, 2) to display it in a minute:seconds format

I did not test it out but it should work

Thanks, will try to see if there are other unconsistency between the manual and C2 itself

loved the first one, pretty sure I'll love this one too ^-^

The page of the system expressions ( https://www.scirra.com/manual/126/system-expressions ) state currently that CanvasToLayer and LayerToCanvas functions take (layer) as a parameter, in fact they take 3 parameters:

CanvasToLayerX(layer, x, y)

CanvasToLayerY(layer, x, y)

, same parameters for Layer to canvas.

Not a big issue, but since it is correctly stated in C2 itself, I might as well indicate it inside the manual.

Also an exemple for the lerp would be appreciable, since I see a lot of people using it in a non intended way (just an exemple saying if x = 0, returns a, if x=1, returns b, if x = 0.5, returns (a+b)/2 ), but it is only a suggestion (the way people are using it is to set x to a constant, and set a to lerp(a, b, x), which results in a movement towards b, slowing when approching b, never reaching b, and that leaded the community into saying sentences like "the sprite is lerping to this position", "lerp is meant to be use to do an ease in movement", which just does not make any sense, and also tends to make people think x should be multiplied by dt to be framerate independant, which won't work since x is not a time of any kind).

this page of the manual, in the Math paragraph, is quite useful in some cases (since it shows the predefined math functions you can use in C2 directly): https://www.scirra.com/manual/126/system-expressions

I would say 3 things:

1/lerp is not meant, and should not be used the way I think you are using it (set Y to lerp(Self.Y, finalYposition, speed) I presume?), and it will also result in an anormal curve.

2/a quadratic formula to increase the player speed to the bottom should be used in this kind of movement

3/ The platform behavior actually does the 2/ by itself, so I think it would be wise to consider using it.

In C2 angles are in degrees, basically,an angle + or - 180° is the opposite angle due to the cyclic nature of angles(adding 360°, aka a full rotation, is the same as adding 0, (360+0)/2=180 so you have half a complete turn, thus the opposite direction)

And angle(x1, y1, x2, y2) return the angle between the two points

This post was originally going to be on another thread, but I went off track so I decided to post a topic in the open topics for it, so ladies and gentlemen, shall we begin?

I think the chrome audio issue was a sort of honest mistake from scirra (using a beta feature of chrome in a good chunck of versions), but even then I still think relying on chromium devellopers not breaking things is an issue.

With node webkit, you have even more things to consider than in a browser, and same goes for all wrappers out there.

The problem IMHO is that while those wrappers sort of work, they are still just an ease of distribution: Most of them don't have a big advantage compared to the browser themselves except from their "appearence" (not sure how to call that). Crosswalk suffer the same problem compared to chrome for android, and cocoonJS is ... cocoonJS, not really much to say, and awesomium was just not up to the competition.

Node webkit is a part of C2, as it is distributed with it, but it is like free advertising for node webkit that is hurting scirra more than it helps it, at first it could be done without the need to be implemented with C2, you can still do it yourself, only the node webkit plugin justify its presence, and even then, it could have been just a third party or optionnal plugin.

At first glance from my side, if I am correct, C2 was shipping with some third party wrapper for mobile only, because due to html5 performances on mobile at the time, it wasn t possible to say "mobile compatible", heck even on desktop it was not clear since webGL was not implemented in all main browsers (chrome only?).

Today I fell like those wrappers are not needed, I know, they are needed in a way, since there is no good platform to sell html5 games, but it is funny how people at first were (and still are) saying that html5 and browsers is not good enough for "real games" while it is currently the "better" version in C2 performances wise (unless there are weird forced limitations).

In fact, it is not that they are not needed, it is that they shouldn't had been shipped with the software itself in the first place (again, my 2 cents), since you should be able to convert them on your side, I think there are html5 wrappers outside of C2 compatible with what C2 produces, sure they may not work, but I feel like a non working wrapper not included is still better than a non working wrapper included (I remember someone trying to do a wrapper based on firefox, not sure how that went, I think it was working, but I do not remember of the licensing), some will say that everything is based on a third party (windows, the hardware itself, etc..), which is true, but we are adding yet another third party over that, no, it is even worse, we add multiple third parties that are concurential and even worse, not really working as they should (node webkit on other OSes needs some tweaking, cocoonJS is..dammit it is cocoonJS, it has been broken long enough for the name to speak by itself, crosswalk is trying, but nothing prevents that to fail us someday, phonegap actually call directly a browser inside the device so devices will advance, the phonegap export should become better...if it does not break, but I am more confident on browser compatibility than on third party compatibility, since that is for browsers that C2 was intended to work, ejecta I do not know, and html5 itself is working quite well as long as browser's betas feature are not used in stable versions for too long).

As for a solution, I do not know, scirra cannot just make a wrapper from scratch, they could base it on something I guess, since it is too late to retract now, a native exporter could be nice but really hard to maintain correctly, I would say the wrapper not third party based of an existing wrapper would be fine enough, since scirra would have control over it, but again all of this is just my opinion.

If you have an opinion on the subject, you can reply ^^

What I meant was fixing the size to 800xX in the project proprities beforehand, with a scaling mode (like letterbox scale, scale inner, or scale outer), so the objects will adapt to the screen size if it is different compared to the specified screen size, and using the node webkit action set width and set height at the beginning of the game, you could ensure having a different size that the one you have chosen for the web version.

The fact being that the assets themselves don't have to be changed from one version to another, just make them big enough for the exe version.

I hope I am clear enough

You can set the window size to not be over 800 px wide, while keeping your assets at the size you want, the exe version if I am correct, can be increased in size with the set width and set height actions, which could result in what you want.

PS:that works because C2 by default will scale up and down the graphics before rendering, so the assets quality will define the graphic quality, not the window size setting.