Ashley

maybe a blog post would indeed make people stop doing this (you could maybe also consider reading the other wall of text I did that shows that if x * dt becomes large, due to what operation lerp is in reality, it can become broken at low framerates, I could try to sum it up and even do some maths if that helps stopping that use of lerp once and for all)

TiAm

the thing is "lerping by N*dt (wierd verb I must say so myself)" is just doing a progression a1 = a0+N*dt*(b-a0), if you study it enough you may be able to find out how that works, if N*dt changes, the progression changes too but notjust like it will become the same after some time, the number of frames to go into 95% of a to b will be shorter at lower fps, BUT the allure is changed too, and it can become pretty different at extreme cases (I explained it earlier but did not proved it once and for all).

it woeks on a peer to peer logic, the only server needed is the signaling server to connect the peers, and scirra has one which AFAIK is accessible without needing to pay anything (except a C2 license if you want to export a multiplayer game, but I think with a free version it works in preview)

Aurel yeah, that is the issue, it is considered so basic that it is hard to explain for those who understand it, but when you do not understand it it is hard to get into (kind of like "why 1+1 =2", hard to explain, and if you do not know it, it won't come like that).

try to think "if the game ran twice as fast the event sheet, would the action be affected?", every x seconds will not, since it will run every x seconds (it Ill be checked twice as much, but still will only be true every x seconds), not every x frames. triggers won't also (as the manual states they do not run in the normal loop logic checked every tick).

but changing the position of something every tick by hand to make it move fluently will (the events runs twice as much in the same duration).

behaviors are mostly defined with "by seconds" so it is time dependant and not framerate dependant.

You have to change the timescale depending on target vsync i believe.

dt adapts itself to the fps value and as far as I saw on my own, that applies even when the V-sync changes (if the refresh rate was under 10 hz, you would have to, but that is not the case).

which is normal, as there is no way in C2 to check the refresh rate and the a multiplatform engine should at least support different refresh rate by itself.

Kyatric not sure it is related, but if a new post on a topic you posted in has been deleted, the "View your posts" will show there is a new message, even though this is not the case since it was deleted.

Colludium my calculs shows that when z becomes larger, the error becomes more important, and with values really high, it can become quite big, which value of z did you tried? (as I am curious to see, on my side, there is a value limit where the result becomes completely unstable, and can go far in variations with time), like if z is equal to fps, you have the direct value of b, stable as it is lerp (a,b,1), but ifyou have z being twice the value of fps, you have the recurring unstability, where you over around b but never come near to it (the difference a-b is always the same absolute value), and over that, well...

(I cannot use C2 until the next week so I could be wrong)

Ashley I did not said lerp(a,b, 1-x^dt) was a bad idea (I did not calculate it), but that lerp(a, b, x times dt) was, as the product x*dt can go potentially over 1 with the fps variations (for x being 60 you can have issues as soon as the fps goes under 60) and even without that issue, the evolution is prone to errors with that calcul as with an higher x, the errors are higher too for the same time value, and I still have trouble with why this is even used at all too.

Actually, the way it goes reminds me of my studies, basically:

SP being b, PV being a, temps being the time, the blue one is when x*dt is between 1 and 2, the red one when x*dt is under 1 (which should tick something in your head, what if the framerate drastically go down for one frame or two due to something that may happen)

PS: this graph is not related to lerp, just the allure is the exact same (the maths behind a P regulation being similar to a a=lerp(a, b, x*dt) )

in short, due to how C2 works, you will be safe as long as x is under 10 for a timescale of 1.

EDIT: well actually... why I am even talking about this, I am going far off topic, we will see what were the issues of the people that have trouble.

Ashley

"I think A = lerp(A, B, x*dt) is correct, even with A changing every frame. I vaguely remember an alternative from the Construct Classic days of A = lerp(A, B, 1 - x ^ dt), but I can't remember the maths behind it, and some quick experimenting shows that both ways appear to compensate correctly for changes in the framerate although they provide slightly different interpolation curves."

they don't give the same results on the same occuring times, that is enough to say that it is not framerate independant (being "fair enough at the end" is not something I would say correct due to the fact how it is evolving is important in that case, but again using lerp that way is asking for those issues as it is a really weird to do, I am wondering how to do an exponential interpolation to go to 95% of the road from a to be which would be framerate independant completely, will get back if I have the time to do it), did not tried with lerp(A, B, 1- x^dt) so I cannot tell.

EDIT:

Lets imagine

experp(a, b, x), if x =0, returns a, if x =1, returns 0.95b+0.05a, evolution exponential between a and b when x increase linearly from 0 to 1, so you can make x increase of 20*dt for exemple and lock it at x=1, that may work similarly without breaking the framerate independancy.

the function being roughly

a+(1-exp(-3x))*(b-a)

exp(c) being the contant e at the power c (e^c)

if someone can try it on C2 to verify

"That would be great if that dt conversion was automatic...but it's probably utopic!"

well, it would be hard to know what needs dt and what needs NOT dt (if you move once an object of 200 pixels, dt is not something you might want).

just have an event, compare situation A, and Situation B (the difference being a time between the two), for the same time, you should arrive at the same situation B in both cases in you calculs regardless of the framerate.

btw, just for the "I said it" aspect of that (I know I am boring with that, but now that I can prove it once and for all, I won't let that chance go):

A=lerp(A,B, 120*dt), for 1/30 seconds (2 frames at 60 fps, 4 frames at 120 fps)

at 60 fps, A is first equal to 0, in one frame: A=lerp (0,B, 2)=2B, in two frames A=(2B, B, 2) =0 (if we continued, we would go 2B to 0 to 2B to 0, etc..)

at 120 fps, A is first equal to 0, in one frame: A=lerp(0, B, 1)=B, in two frames, A=lerp(B, B, 1)= B+1*(B-B)=B

in 3 frames, A=lerp(B, B, 1)= B, in 4 frames, A=lerp(B, B, 1)=B (if we continued, it would still be B).

not the same result, so framerate independancy is not there, in short, never use dt in lerp like that, never use lerp like that for that matter, as it is not intended to be used like that!

Aurel

KaMiZoTo

KaMiZoTo

dt is the duration between two ticks, it is there because events don't occur on a fixed time like every 1/60 seconds.

when you want something to move at a speed of 20 pixels per seconds, you will have to increase its position of 20 pixels each seconds at the end, so at 20*dt pixel each tick to achieve that.

summing up dt every tick into a variable will make said variable increase by 1 each second (unless you have a timescale other than 1 or if the fps goes under 10, those are the two limitations).

the solution?just do the calculation on a simple case with a fixed time and you will know:

at 60 fps, I should be at the same position in one tick than at 120 fps in two ticks (as twice as more ticks will occur).

in your case, you start up at position A, you increase it by 20*dt every tick, lets try on 1/60 of seconds of interval

in one tick (1/60 of seconds) at 60 fps, the next tick it will be A+1/30

at 120 fps (1/60 of seconds, correspond to two ticks), the next tick it will be A+1/60, the tick after that it will be A+1/60+1/60=A+2/60=A+1/30

it is the same result, so you are good.

heck, even more simple: imagine with 10 fps compared to 100 fps (ten times more ticks per seconds), for 1/10 of seconds passed

in one tick at 10 fps, A+20/10=A+2

at 100 fps, in ten ticks: A+20/100+20/100+20/100+20/100+20/100+20/100+20/100+20/100+20/100+20/100 = A+200/100 =A+2

sqiddster "'every X seconds' should never be used with dt. It uses it internally."

it is easier to understand as "you are acting on a fixed time, so no compensation is needed, every 1 seconds will be true every seconds, regardless of the framerate" (sure it can become false in extreme cases, but those cases are not something you should be designing for).

+1 for me too, it is simply disturbing to rely just on the relative scroll speed but not having any offset control.

.....I wonder, what if, after the game first loaded, you close it, cut the internet connection and restart it, does it works? (the offline.appcache may make it work offline).

The situation of Android would be even worse than I thought, not that I even saw it as a real opportunity anyway (since adverts is the way to go, a market when you don't expect people to pay for what you give them)but still interesting, I wonder what could be done to help with that, I would say antipiracy measures (while they are completely uneffective, people seems to be thinking à paid app cannot sell if it can be illegitimately acquired), but mostly, I would think that it is expected, everyone says à paid app cannot sell on android, so they do not even try and drag down even more the situation, more exploiting à dying market than really "selling" à game IMO.