[Matt]

Greetings,

I have been going through some of the game examples and I noticed a Timer is used like this to evaluate player movement.

Timer {
    id: updateTimer
    interval: 60
    running: true
    repeat: true
    onTriggered: {
      // this must be done every frame, because the linearVelocity gets reduced because of the damping!
      var xAxis = controller.xAxis;
      if(xAxis) {
        collider.body.linearVelocity.x = xAxis*rightValue;
      }
    }
  }

Some of the design ideas I would like to experiment with involve tracking entities on a per frame basis (or close to it) so I set up a single game Timer{} like this in my GameWindow file and then coded some entities to utilize a Connection{} to connect a function to the Timer’s onTriggered() signal.  It all seems to be working well.

 

Now I am looking at the interval you have set in the example (code above) and I am a little confused by the value.  If the interval property is in ms and you have it set to 60 and the game is running at 60fps, to my understanding we would require the conversion of ms per frame.  So in my mind (late at night) I am thinking the interval should be 1000ms/60fps which is approx a 17ms interval per trigger() of which close to 60 of them would be fired per second and more closely match the max frame rate.

• This topic was modified 9 years, 3 months ago by  Xevoius.

[ChristianFelgo Team]

Hi Matt,

you are completely right – if you want to have a check every frame, you would need to set the interval to 16.

 

However, I recommend not doing so, because per-frame checks are really bad for performance, especially if you do calculations there per-entity and per-frame. It really is a compromise between perceived “fluidness” and performance here – try to set the interval as high as possible to still achieve the visual results you would like to have. Because note that especially on mobiles, which have less CPU power, heavy JS calculations per frame are bad for performance.

 

Usually it is best to try to think in terms of event-based logic, e.g. use the Physics system (which is implemented in C++ internally and pretty fast), to detect collisions and work with colliders to get notified of collisions. In case of a collision, you can then execute your JS code. If this is possible though, depends on your exact use case of course.

 

I hope that helped,

Chris

[Matt]

Thanks for the info Chris!  It also looks like I will most likely be handling data on an estimated per frame basis off a max 60fps which means the “per frame” handling routines I hook up to that Timer will be called more often than once per frame since the game will not always be running at 60fps.  I will probably have a few items like this to run past you to make sure my understanding is correct since I am new to the framework.