1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| MAX_TIME_BETWEEN_LOGIC_UPDATE = something;
MAX_TIME_BETWEEN_DISPLAY_UPDATE = somethingElse;
accumLogic = accumLogic + delta;
accumDisplay = accumDisplay + delt;
public void updateMethodThinger( ... ) {
while(accumLogic >= MAX_TIME_BETWEEN_LOGIC_UPDATE) {
accumLogic = accumLogic - MAX_TIME_BETWEEN_LOGIC_UPDATE;
updateLogic();
}
while(accumDisplay >= MAX_TIME_BETWEEN_DISPLAY_UPDATES) {
accumDisplay = accumDisplay -MAX_TIME_BETWEEN_DISPLAY_UPDATE;
updateDiaply();
}
render();
} |
This is butchered, semi-pseudo code based on what Notch did for his Metagun project, one of the LD's. What it does is:
Stores the accumulated time since the
last time your updateLogic/updateDisplay was called. This is delta + remainder from the last time this method was called.
Calls the updateLogic/updateDisplay once for each time the accumLogic/accumDisplay is greater than or equal to the constant listed at the top.
Why this is helpful? Let's say that you don't
care what your FPS is, because it'll differ too greatly between different computers to actually be of use to you when you're writing your logic (Case in point, using the libgGDX library I get a smooth 60-63 on my desktop, 40-63 on my tablet and 30-90 on my android phone.) So, instead, you decide I want to have exactly X logic updates a second. You set the constants to the amount of time there should be between updates to cause this: (1000000000 / 60 for 60 updates a second, but it all depends on whether your delta is returning nanoseconds, etc).
Either way, when you hit that inner loop, it'll check whether the accumulated time is large enough to warrant an update or not. If it is? Good, then call as many updates as needed. If not, continue to accumulate time. Why does this help you? Let's say you have 60 updates a second. All's going good, you've got something like a 200 FPS which you mentioned before, which means that you'll be calling an updateLogic() only once every 3-4 frames. Then, something happens (Another process starts up and hogs your CPU, you get a swarm of enemies on the screen, whatever) and you're updateLogic() is suddenly taking a
lot more time and you're now at 30FPS? Well, instead of just completely lagging up the game world so that you're only getting one update per frame, you'll be calling updateLogic()
twice per frame to keep the number of update ticks close to what you actually want.
Now, how does this help you for your issue of slowing down your movement? You put your
game's logic in the updateLogic() method. That is the stuff that happens when your character is told he needs to move, or process an enemy's UI, etc. And you put the
display's logic in the updateDisplay() method. That is the stuff you do when you need to check whether your animations should advance, your screen should move X pixels, etc.
As for where it goes in what your update loop looks like? Well, it should probably go
before the rendering is done, with the last 'update display' chunk being inside of the updateDisplay() method.
