7

I have an app written in QT that uses QTimer. It's basically a game and all the actions are controlled by the timer. Game includes the ability to increase\decrease the game speed. The code for increasing the speed is

    timerValue -= speedUpValue;
    if (timerValue < maxSpeed) {
        timerValue = maxSpeed;
    }
    timer -> setInterval(timerValue);

speedUpValueand maxSpeed are constants. Almost the same code is used for decreasing the speed. The problem is that setInterval resets the internal timer and therefore if you keep rapidly increasing or decreasing the speed game eventually never proceeds because remainingTime is constantly being reset. Is there a way to set remainingTime manually or change the interval without resetting it?

DannyPhantom
  • 1,042
  • 10
  • 21
  • 1
    No, there is no way to change the interval without the timer restarting automatically. However, you can likely achieve a similar effect by only updating the interval when the timer times out. – RA. Oct 03 '15 at 02:19

1 Answers1

4

You can omit the timer object altogether, and instead use the static method QTimer::singleShot(...), and set a new single shot on every timer event with the timerValue. So no matter how frequently timerValue is modified, each timer cycle will be completed with the old value and scheduled with the current value.

As RA mentioned, you can effectively achieve the same thing keeping the timer object, but moving the setInterval() to the timer event, basically the same thing as above, but keeping the timer object, if you need it for some reason.

As Craig mentioned in the comments, the first approach will also ensure timer events don't get accumulated, in case your game logic takes longer. Also, if you go for an asynchronous design, it is possible that the next game cycle will begin execution before the old one is completed if you go for a continuously running timer.

It this regard, it is best to not use a continuously running timer, but schedule each next game cycle manually, and only if you need to. For example, you may not need to schedule another if the game comes to an end. Also, this will allow for finer control over how accurate the game speed goes, after the game cycle execution is completed, you can calculate how much time remains until the next one is needed, and schedule it with that value, or if the execution took too long, you can schedule it immediately.

Marco A.
  • 43,032
  • 26
  • 132
  • 246
dtech
  • 47,916
  • 17
  • 112
  • 190
  • 1
    A further advantage to using a single-shot each time is that then events don't accumulate. If you use QTimer and cannot consume its signals as fast as they are generated, they bank up. Single shots cannot accumulate like this because you only initiate the next one when handling the current one. The main downside is less accuracy/regularity of interval. – Craig Scott Oct 03 '15 at 12:03
  • @CraigScott: I know this is all old news, but it's the best information I can find at the moment. [This answer](https://stackoverflow.com/a/17077411/3491308) seems to suggest that periodic QTimer events don't accumulate anyway. More like a check at the end of the event loop to see if the prescribed time has elapsed yet. If it has, even grossly, it fires one event and resets the timer. Which is right? – AaronD Dec 01 '17 at 10:42
  • @AaronD It's been a long time since I made the above comment but I think it was based on actual behaviour I had seen rather than being hypothetical. Too long ago for me to remember the details, so you'd have to do your own tests to verify the behaviour with latest Qt. – Craig Scott Dec 01 '17 at 23:57
  • Also consider that the slot connected to the timer signal might be a queued connection, so the accumulation might not be with the timer itself but rather in the queue of deferred slot invocations. – Craig Scott Dec 02 '17 at 00:03