Aphrodite's Forum Posts

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

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • "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

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