The bug has been discussed on the mailing list: The speed of the ball decreases instead of increasing at some point in the game. The reason is that the QML-timer has a minimum resolution of 16ms (i.e. 60 fps). Now, instead of firing the timer at a higher interval, the evaluation (Move balls -> detect Collisions) is split into several substeps. The number of substeps is doubled instead of cutting the timer interval in half.
Details
Diff Detail
- Repository
- R393 KBreakout
- Lint
Lint Skipped - Unit
Unit Tests Skipped
OK, tested it and it works as in the ball does not slow down anymore.
I cannot really argue about the implementation because I did not understand why this switching is needed in the first place. :D
Thanks for catching the typo. About the comment: You are of course perfectly right :D.
Do you mean switching the interval/substeps/speed? Or switching from a change in timer interval to the substeps?
I'll try to explain:
- Why change the interval? The basic loop is: Move ball -> Check for collisions -> Change direction, perform actions, according to collisions, etc. -> Move ball -> ... The speed determines how far the ball is moved during the "Move ball". If the ball is moved too far, the collision detection might be inaccurate (E.g. the extreme case is the ball moving through a brick with no detected collision). To avoid such bugs, we move the ball only half the distance, but twice as often.
- Why use substeps now? In the original code, this was done by cutting the gameTimer interval in half. However, this broke during the port to QML, because QML timer have a minimum interval of 16ms. Cutting it in half to 8ms does not have any effect. The alternative approach is to keep the gameTimer interval, but perform the basic loop twice.
I hope this made it a little bit more clear. I am still wondering if the new approach has performance issues (moving the balls sequentially, instead of in parallel), but I don't think it matters as the collision detection, which is much more costly, is done sequentially as well.
Thanks for the explanation. That made it more clear. :)
I hope this made it a little bit more clear. I am still wondering if the new approach has performance issues (moving the balls sequentially, instead of in parallel), but I don't think it matters as the collision detection, which is much more costly, is done sequentially as well.
I played on a five years old laptop and when the "cut" came, the ball felt more smooth. In general it is better than before the change here.
Looks sensible, only minor comment is that you should be using === instead of == in JavaScript code since it's marginally faster, but not that it matters much.
To me you can commit it but i won't give you the "Accept" yet in case someone else wants to commit, if no one beats me to it i'll add it in a week.