Hi beachbum,
You bring up some good points. I have a ton of experience in handline the that you are running into.
It helps to look at this in sort of a different way. Don't look at frames as chunks of time. If your frame frame is 25, don't expect each frame to be 40ms after the previous. Instead, treat frames like snapshots in time. What you render onto the screen would then be *always* be correct, but is dependent on what time it is.
This means that you make animations time based. I'd still recommend using enterFrame. On every enterFrame event do a getTimer() call. Based on either what time it is or how much time passed since the previous render, do stuff.
For instance, a ball rolling horizontally across the screen might have this equation of motion:
Code:
var x = xVel*time + x_initial
x_initial is the x position of the ball at time 0. The position can be precisely determined just by doing a getTimer() to figure out what time it is. Now, you can extend this frame-independent animation to all moving objects.
Where you might see issues:
Collision detection. If it is multiplayer then collision detection should most likely be done by the server anyway. But if you *had* to do collision detection on the client you need to do it in memory, hitTest won't cut it when time-based animations. One client's "snapshot" in time might be 52ms while someone elses is 45ms....hence rendering the ball out correctly, but in a different position. If you do the detection i memory, then it too is frame independent.
I understand that this is a big change in thinking, but I can assure you that is perfect and absolutely needed since you cannot gaurantee synchronization between the server and the client if they both use unreliable time intervals.
Reply With Quote
