everything is based on time :) speed = distance/unit time, if your unit time is millisecs (since thats what the blitz system clock runs in), then a force vector is how much an entity travels in one millisecond.
the difference between the timestamp on a net packet, and the current time is how far in the past that the remote player did something (moved, fired, etc), its also how much lag that player is currently getting off the net. (thats what makes this so kewl -- automatically smooths out the lag)
so given the time, force and position in the past, you can predict the entities position some time in the future. the distance vector from the local entity representation to the predicted position divided by the prediction time = the force that must be applied to the local entity to converge the local position with the predicted future position at the correct time.
In the 1st frame, each red dot + line represents the position and vectors sent over the net. In the 2nd frame, the green dots represent the predecited locations a short time in the future, in the 3rd frame, the forces that must be applied to the local entity.
The following code isnt adapted to the network, but shows the basic idea of using time to control motion... ticks is the number of milliseconds since the last RenderWorld. Basically makes motion independent of frame rate. (Tho I never run a game update cycle any faster than the vertical refresh interval of the monitor - people that run 200 fps update cycles are wasting cpu on generating graphics that the player will never "see")
Code also includes my smooth jump routine.. player jumps up, gravity drags them down, and it includes a recovery time before they can next jump. (that part of the code needs to be fixed up for tick handling, its setup for 60fps right now)
the difference between the timestamp on a net packet, and the current time is how far in the past that the remote player did something (moved, fired, etc), its also how much lag that player is currently getting off the net. (thats what makes this so kewl -- automatically smooths out the lag)
so given the time, force and position in the past, you can predict the entities position some time in the future. the distance vector from the local entity representation to the predicted position divided by the prediction time = the force that must be applied to the local entity to converge the local position with the predicted future position at the correct time.
In the 1st frame, each red dot + line represents the position and vectors sent over the net. In the 2nd frame, the green dots represent the predecited locations a short time in the future, in the 3rd frame, the forces that must be applied to the local entity.
The following code isnt adapted to the network, but shows the basic idea of using time to control motion... ticks is the number of milliseconds since the last RenderWorld. Basically makes motion independent of frame rate. (Tho I never run a game update cycle any faster than the vertical refresh interval of the monitor - people that run 200 fps update cycles are wasting cpu on generating graphics that the player will never "see")
Code also includes my smooth jump routine.. player jumps up, gravity drags them down, and it includes a recovery time before they can next jump. (that part of the code needs to be fixed up for tick handling, its setup for 60fps right now)
Global walkspeed# = 0.007 Global turnspeed# = 0.07 Global jumpcnt = 0; Function Update() MoveEntity camera_pivot,0,0.2,0 ; gravity If KBS_Action("walk") MoveEntity camera_pivot,0,0,walkspeed# * ticks If KBS_Action("back") MoveEntity camera_pivot,0,0,-walkspeed# * ticks If KBS_Action("left") TurnEntity camera_pivot,0,turnspeed# * ticks,0 If KBS_Action("right") TurnEntity camera_pivot,0,-turnspeed# * ticks,0 If KBS_Action("jump") And jumpcnt = 0 jumpcnt=40 EndIf If jumpcnt > 0 If (jumpcnt > 35) MoveEntity camera_pivot,0,0.6,0 EndIf jumpcnt = jumpcnt - 1 EndIf MoveEntity camera_pivot,0,-0.3,0 ; gravity End Function