Update loop is dependent on the speed of the graphics loop

[Oipo]

This results in the ant moving notably slower if the FPS is lower. Preferably the solution is to implement the "Constant Game Speed independent of Variable FPS" from http://www.koonsolo.com/news/dewitters-gameloop/

[cgreer]

This shouldn't be that hard except we have to change the moving sprite fxn as well.

So if I understand correctly, the idea referenced in the article works better because the logic will only be updated a set number of times per second, while the drawing will be done as much as possible.

I'm curious though, does the logic really take up a significant time allotment? I always thought the graphics drawing operations took up a much greater proportion of cpu/gpu time...

[Oipo]

In 3D games, the drawing can take up quite a lot of time, yes. But this is a 2D game, which uses the GPU to offload almost everything. So I think that for OpenAnt, the logic will take up most time(considering we'll have many ants with AI and A* stuff)

[cgreer]

I didn't think about all the AI pathfinding and such. Maybe I'll profile it with a hundred ants or so for fun later...

On Thu, Sep 1, 2011 at 9:22 PM, Oipo < reply@reply.github.com>wrote:

In 3D games, the drawing can take up quite a lot of time, yes. But this is a 2D game, which uses the GPU to offload almost everything. So I think that for OpenAnt, the logic will take up most time(considering we'll have many ants with AI and A* stuff)

Reply to this email directly or view it on GitHub: https://github.com/Rinum/OpenAnt/issues/14#issuecomment-1975884

[Cibrong]

I actually started working on this a while ago. I didn't finish the interpolation function and forgot about it.

[cgreer]

Nice, I was just trying to implement this. I'll try to merge this with the master tomorrow and start working on the interpolation. I've never done interpolation before so I have a couple of questions.

From what I've read about interpolation, we need to store two states: the current state, and the previous state (position or whatever). Then when each drawing frame comes up we just "lerp" between the two. Because of this, the user always sees the game as Previous < User sees < current state. Is the what we are trying to do in OpenAnt?

If this is true, then the Ant's move function WILL NOT be called every time the frame is redrawn. Instead, a lerp function for the ant's position will be called during the frame redraw. This makes sense because the lerp fxn should be really fast compared to the move fxn. Correct?

If this is all correct, then I'm starting to wonder how the networking will manage. The logic loop in Cibrong's implementation runs at 25Hz - each game state change will be 40 ms (1000/25) apart. Assuming (for the MMO) that the game will run on a server and only the game state information will be transferred to the clients, will 40ms be enough time for the server to send the game state info and recieve the client input/info? The server has to (1) get the user input, (2) update game state, (3) send game state info to client. I guess the UDP connection can go as fast as possible and the server will update it as needed? I know that starcraft only updates at 5Hz...

On Wed, Sep 7, 2011 at 9:17 PM, Cibrong < reply@reply.github.com>wrote:

I actually started working on this a while ago. I didn't finish the interpolation function and forgot about it.

Reply to this email directly or view it on GitHub: https://github.com/Rinum/OpenAnt/issues/14#issuecomment-2036517

[Cibrong]

You don't need to store two states, the function just tells you an approximation of where the object would be between the last state and the next state. You don't call the move function, you just draw the ant in between the previous states position and the next states position, basically you are trying to predict the future. So its Current < User sees < next state because the Graphics update and the game logic update are separate.

40ms is very fast for a roundtrip. I think times of 100-200ms on average is a better estimate. The way the ant moves now it will only require 1 move validation check by the server every time a new move-to command is called. So every time you click you will get a 100-200ms delay before your ant starts moving. I'm not very experienced with networking but doesn't sound so bad.

[cgreer]

We implemented a extrapolation system and the ant's speed will be constant, we should close this issue.

[Oipo]

Sure thing!