Keeping track of wall-clock time (which is subject to adjustment, DST, timezones, etc) in addition to internal high-res timer provides no benefit. Here is how the old code worked:
"secondsPassed" variable is the key to figuring out how many ticks passed. That value is determined by the frame-to-frame delta of JRE's high-res timer (System.nanoTime()). So far so good. But then it gets adjusted by "timer.adjustment" variable. That value starts at 1.0 and is affected any time wall-clock time delta exceeds 1 second between frames. If wall-clock time delta is over 1s, the following value is added to "timer.adjustment": (wall_clock_delta / HR_clock_delta - timer.adjustment)*0.2
Some scenarios for frame-to-frame wall-clock delta being over 1s: 1) really laggy frame (e.g. first frame after map load), 2) NTP clock adjustment, 3) DST transition, 4) timezone transition, 5) computer waking up from sleep. In all of these scenarios, adjustment would simply result in odd tick rates, and would provide no benefit.
After much research, I found no examples of this adjustment technique being used in any game loops (outside Notch's original code). So I have removed it. I've tested the game with this commit, and it performs just fine at all framerates.
Keeping track of wall-clock time (which is subject to adjustment, DST, timezones, etc) in addition to internal high-res timer provides no benefit. Here is how the old code worked:
"secondsPassed" variable is the key to figuring out how many ticks passed. That value is determined by the frame-to-frame delta of JRE's high-res timer (System.nanoTime()). So far so good. But then it gets adjusted by "timer.adjustment" variable. That value starts at 1.0 and is affected any time wall-clock time delta exceeds 1 second between frames. If wall-clock time delta is over 1s, the following value is added to "timer.adjustment": (wall_clock_delta / HR_clock_delta - timer.adjustment)*0.2
Some scenarios for frame-to-frame wall-clock delta being over 1s: 1) really laggy frame (e.g. first frame after map load), 2) NTP clock adjustment, 3) DST transition, 4) timezone transition, 5) computer waking up from sleep. In all of these scenarios, adjustment would simply result in odd tick rates, and would provide no benefit.
After much research, I found no examples of this adjustment technique being used in any game loops (outside Notch's original code). So I have removed it. I've tested the game with this commit, and it performs just fine at all framerates.