Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update loop is dependent on the speed of the graphics loop #14

Closed
Oipo opened this issue Sep 1, 2011 · 8 comments
Closed

Update loop is dependent on the speed of the graphics loop #14

Oipo opened this issue Sep 1, 2011 · 8 comments

Comments

@Oipo
Copy link
Collaborator

Oipo commented Sep 1, 2011

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
Copy link
Contributor

cgreer commented Sep 2, 2011

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
Copy link
Collaborator Author

Oipo commented Sep 2, 2011

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
Copy link
Contributor

cgreer commented Sep 2, 2011

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:
#14 (comment)

@Cibrong
Copy link
Contributor

Cibrong commented Sep 8, 2011

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

@cgreer
Copy link
Contributor

cgreer commented Sep 8, 2011

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:
#14 (comment)

@Cibrong
Copy link
Contributor

Cibrong commented Sep 8, 2011

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
Copy link
Contributor

cgreer commented Sep 14, 2011

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

@Oipo
Copy link
Collaborator Author

Oipo commented Sep 14, 2011

Sure thing!

@Oipo Oipo closed this as completed Sep 14, 2011
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants