You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
The LoopRunner has a buffer strategy that will "predict" the next 2 seconds TPF based on the last 2 seconds registered.
This causes severe FPS drops when a single frame takes a long time to process as this exception is used to calculate the next TPF to use.
This enforces a 2 seconds lag period even though there is no lag anymore.
Note: If lag appears, the use of "scheduleAtFixedRate" will trigger all "ticks" even if their 0 millis long. In case of severe lag, it will put a lot of pressure on the game loop by causing many more calls, which is counter productive (causing further lag). Here is a brief example: If the scheduleAtFixedRate request 60 calls per seconds, and the first on update takes 1 second, the executor will call 59 ticks in a row just after that since it's 59 ticks late. In most cases, this freezes the game until the main loop is able to process all missed ticks fast enough so it can resync with the executor.
To Reproduce
Steps to reproduce the behavior:
An example will be provided along with a Unit Test.
The test will intentionally perform significant lag (thread.wait) in 1 onUpdate.
Expected behavior
The LoopRunner should always perform as many game Ticks as it can without intentionally slowing down a game. The provided solution will call the onUpdate based on the time between now and the lastFrame. Also, it'll skip "empty calls" from the "scheduleAtFixedRate" loop.
Runtime info(please complete the following information):
Windows 10/11
MacOSX Ventura
The text was updated successfully, but these errors were encountered:
Describe the bug
The LoopRunner has a buffer strategy that will "predict" the next 2 seconds TPF based on the last 2 seconds registered.
This causes severe FPS drops when a single frame takes a long time to process as this exception is used to calculate the next TPF to use.
This enforces a 2 seconds lag period even though there is no lag anymore.
Note: If lag appears, the use of "scheduleAtFixedRate" will trigger all "ticks" even if their 0 millis long. In case of severe lag, it will put a lot of pressure on the game loop by causing many more calls, which is counter productive (causing further lag). Here is a brief example: If the scheduleAtFixedRate request 60 calls per seconds, and the first on update takes 1 second, the executor will call 59 ticks in a row just after that since it's 59 ticks late. In most cases, this freezes the game until the main loop is able to process all missed ticks fast enough so it can resync with the executor.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
The LoopRunner should always perform as many game Ticks as it can without intentionally slowing down a game. The provided solution will call the onUpdate based on the time between now and the lastFrame. Also, it'll skip "empty calls" from the "scheduleAtFixedRate" loop.
Runtime info(please complete the following information):
The text was updated successfully, but these errors were encountered: