-
Notifications
You must be signed in to change notification settings - Fork 20
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
Comments
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... |
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) |
I didn't think about all the AI pathfinding and such. Maybe I'll profile it On Thu, Sep 1, 2011 at 9:22 PM, Oipo <
|
I actually started working on this a while ago. I didn't finish the interpolation function and forgot about it. |
Nice, I was just trying to implement this. I'll try to merge this with the From what I've read about interpolation, we need to store two states: the If this is true, then the Ant's move function WILL NOT be called every time If this is all correct, then I'm starting to wonder how the networking will On Wed, Sep 7, 2011 at 9:17 PM, 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. |
We implemented a extrapolation system and the ant's speed will be constant, we should close this issue. |
Sure thing! |
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/
The text was updated successfully, but these errors were encountered: