I think it would have been nice for translation to be at least supported (after all,it was started but never finished), english is never, and will never be universally known.

if your function is "sum", with parameter 0 and 1 being numbers (5 and 6 in my exemple).

just enter Function.Call("sum", 5, 6)

Nesteris normally, if there is a unit like "in pixels per seconds"or "in degrees per seconds", that means that dt is not needed (as one pixel per second is still one pixel per second, regardless of the framerate, due to the clear definition of a second on a fixed timescale)

mostly, all behaviors related to movement should not need dt.

I read it before (not sure if it was edited between the time I read it and the today), and my opinion is still the same and will not change anytime soon if the arguments also don't change:

Javascript sure is slower (and on what I saw, well, it is outdated and so weird that most people do not use directly Javascript but some libraries to help them). And it is an interpreted language which does not belong to a single interpretor, all of that is to take into deep consideration... unless you are not directly using javascript, in which case you should see what is already done to help.

In the case of C2, memory management and garbage collection issues are seriously lowered (due to general kind of recycling and layout by layout loading, as well as a lot of other things that I am not able to describe that may have been done), and the fact remains: Javascript performances are tied to how it is interpreted, on mobile I saw that, well, compatibility seems to be an issue so I would guess that we are far from what could have been done, yet, it is pretty doable.

All of this should be taken into consideration before buying C2 for obvious reasons (and you can test before buying it, C2 is fully html5 + javascript and does not rely on native at all, the event system should not be the only reason you are using C2 for, if html5 is not interesting to the potential user, then he might as well not buy it). If you need native, you won't even consider javascript anyway.

As for an html5 C3, keep in mind it is not before at least 1 or 2 years (and while JS performances does increase, as well as compatibility, which means it will be realisable, and before CC anyone though that a free drag n drop engine was just a toy, before C2 they though that html5 was doomed to failure and that nothing serious could be done with it, they might as well prove that a game creation engine can be done to run inside a browser without plugins) it is imaginable, heck even gdevelop as a web app nowadays (in a beta stage), sure it is not useable for a full fledged game and confusing, but this is because it is just weirdly designed, not because of perfs issues. However for obvious reasons when C3 does arrive, users should do the same they are currently doing: test carefully on a range of browsers so bugs are not left behind, also C2 already is a stable engine so the global design of it may be "easy" to transpose into the C3 editor.

however time will tell.

Ruskul I do agree that it would be nice to not have only javascript (due to how C2 plugins works, after all, there was a time when developping your own exporters was on the todo list if I recall), but well, no obligations, if other engines do better, fine for them.

Elliott the difference being, telling not to worry about performances is not a good idea, whereas here, it is telling to worry about the fact a stable fixed framerate is not something you will find even in the long term and is still a better idea anyway to consider that fact as it helps for now too.

I love that too, refreshing only when a display change is transmitted, rather than refreshing constantly in hopes that something changes on the right times.

Not sure how that changes for browser vendors though thru their implementations.

Refeuh so basically, games should work on a time-relative way rather than a framerate relative way as, if those techs catches up, relying on a stable display framerate would not work, right?

however, you can only add it once in a project, you may have it already inside the project or template you are using.

Aurel I am not agaisnt not knowing something, but the lerp issue was not that people did not know it, it was that they used it even though they did not know it, I am not agaisnt simplification on some transitions effects for C2 (if there was a simple way to make a number X that will increase from a to b in a setted time by itself without needing to change any events,just with a "start increasing value" action, I am sure most of those would be completely solved by most users without any injuries), I am just saying that if you are using something, be sure that it works as expected, as quick does not mean broken, imagine if you did not saw the issues, it could have been far worse.

(actually, the start increasing variable action could be nice somehow, do you agree? it could correct most issues for transitions effects and movements I think).

Aurel define smooth, slow and fast, and I would say it may be something to potentially consider (even though I see more this as an expression meant for that, rather than misusing lerp)

also the beginner error with lerp comes only from one thing: someone used lerp that way, he liked it, and so everyone did use it, whereas it just does not make any sense, and then they assumed adding dt to the detourned formula would work (spoiler: it does not really).which is why even the potentially correct ashley version I would be agaisnt as, it is not a linear interpolation between a and b that is done, it is another calcul that just is similar math wise. Lerping does not mean, and will never mean, going smoothly from a to b, it just does not.

just understand what something does before using it, it is as easy as that.

you want to do a transition? then just do it, make the value increase more or less with time depending on what you want, we can help find which expression is the best for that if you need, you want a linear transition? then a good use of lerp willdo it, something slower first then quicker then slower again? cosp can do that, something fast first then slower that never reach the goal but divide the distance each second by the same number? the bad lerp does that, but an exponential formula will do the job in a way you can control fully and that will work even if dt changes.

"Share — copy and redistribute the material in any medium or format

Adapt — remix, transform, and build upon the material

for any purpose, even commercially."

I could be wrong, but that does not prevent you to sell it, nor add ads, as long as you do the correct attribution and that you do not deliberately prevent people from taking said ressources for their own use following those terms.

I wonder if perhaps a new expression for speed would be a good idea.

Something that would have dt applied, but be simplified to pixels per second, like say speed().

you mean like

a=speed(a, b, speedvalue)?

you should be able to do it with two min or max functions depending on where a is compared to b.

in a every tick logic:

a is inferior to b : set a to min(a+speedvalue*dt, b)

a is superior to b: set a to max(a-speedvalue*dt, b)

speed value being in value per seconds