Free webinar! How to Make Generative AI Work for You
Get my free ticket+ 1
Mirielle
Евгений
okay, I copied the clock.js and modified it as a local class.
I put the this.#lastTime into the start() method and deleted it from get delta().
also, the elapsed method is basically the same as delta, so I deleted it.
Now clock.delta is a pure read function you can put anywhere.
the clock.start() method have to be included in the animate function to update the #lastTime value, though...
https://code.sololearn.com/WTxzA4bJm23w/?ref=app
+ 2
Mirielle
I'm confused.
The commented out part ( line 22 ) would basically replace the update function.
So maybe if you want to replace one with the other, the part that should be commented out is the update call inside the animate function?
uncomment:
line 22
comment out:
line 29 update(clock.delta * 0.001);
Then the behavior is the same...
+ 2
if you comment out line 14, the update function is basically an empty function.
It is in a requestAnimation loop after all, so the empty update function is being called over and over again.
Not the same if you comment out the function call instead.
Just guessing...
+ 2
Mirielle
I think there's something weird going on with clock.delta.
I was dubious about my empty function theory, so I decided to move things around.
It's not the empty function when you comment out line 14.(I changed it so you only pass the 0.001 and the clock.delta is in update())
It's clock.delta. Which makes it more puzzling. why would reading a value twice(once in animate and once in draw()) slow down the animation?
https://code.sololearn.com/WqRIDs8oHGs4/?ref=app
+ 2
The problem is indeed it the way you use the Clock.delta property which is actually a function call. The way this function is designed supposes that you call it once per frame to give correct overall result.
So when you call it twice per frame, in the unfortunate circumstance the calls are spread uneven in time: there is one very long period an one very short period of time, which differ in _orders_ of magnitude I guess. And the short one is used to calculate the new value for `aDisplacement`. So the code works just fine, there's no lag, it's just the ball moving at very low speed.
Thanks Bob_Li for his observations and making an example, it helped a lot.
My explanation can be confirmed by uncommenting the `clock.delta` in the `draw()` function in the Bob_Li's example and moving it right after the `aDisplacement +=... ` line in the same function.
+ 2
Bob_Li no, doesn't just reads, I also writes the timestamp when it was called, and returns the difference on the next call.
```
export class Clock {
#lastTime;
...
get delta(){
const dt = (this.now - this.#lastTime);
this.#lastTime = this.now;
return dt;
}
...
}
```
+ 2
BTW double `this.now` lose a couple of microseconds, but that's OK for most applications.
+ 2
Bob_Li That's A LOT of 'clock.delta's :)
Your separation of pure functions and functions with side-effects results in much cleaner solution. Kudos!
For some reason the ball moves much faster now, but the coefficients seem to be the same.
Mirielle
Is it OK that you do some kind of initialization on every draw()?
```
MustAddEntity.init()
```
+ 2
Mirielle the modifications are so that you need to explicitly call the start() function to mark the moment in time which is used to calculate deltaTime by using the `delta` property. The consequence is that you need to call the start() every frame and only once per frame, but you can read the `clock.delta` as many times as you want.
+ 2
Or start_timer(), or start_counter().
+ 1
Евгений
great observation. I didn't realize the placement of clock.delta relative to aDisplacement was the key..
I added your observations in the code bit.
But why exactly does it affect the animation speed? it's not changing any parameter, just reading performance.now() values.
But why doesn't it slow down the animation if it's called after aDisplacement?
+ 1
Евгений wow. I didn't realize the effect of
this.#lastTime = this.now;
would be.