That's not what I'm talking about - I'm talking about predicting the next position. If the client gets a new position, it should show that new position straight away, not interpolate between that and the previous position.uzurpator wrote:What game logic info the client needs? It knows that vehicle X was at 42,44 and now it is at 42,45 - obviously it now can create infinite steps from 42,44 to 42,45.DominionSpy wrote:This is a bad idea in my opinion. You are talking about dead-reakoning which involves using information about the game logic. We want to separate that from the rendering completely.
All modern games use this mechanism.
With prediciting, you have to use game logic (even if it's working out the new position based on the last direction and speed of the vehicle). This is the job of the server.
That isn't what I said at all, in fact I was trying to say it shouldn't have anything to do with the framerate of the client, but you seem to have missed the point.uzupator wrote:Ok - so If my GE FORCE 10600 GTX PRO TURBO ULTRA can draw the map at 1044 fps in 2048x1536 in full detail in full LOD, x16 AA, x16 aniso - the client should request the data 1044 times/second?In most views millisecond differences in data delivery will not be noticable. If the view zooms in close enough to see a jump then the client should request updates more frequently (especially since at that level, the data being sent should be drastically reduced).
Moreso - the crummy server i play on does just 30 fps. So my geforce will now draw 30 fps, despite the fact that it can do so at 1044 fps?
Firstly what I was saying is that the client should draw to the screen at a consistent rate that it can keep up. If your computer can draw the map 1044 times a second consistently, then let it.
The other part of what I was saying was related to the view, not the framerate. I was suggesting that if an object is close enough to the camera to notice a jump when data is received, then the client could request the data more frequently (and I was thinking in the order of 40 times a second instead of 20, say). This might be calculated at the rendering stage based on the positions of the objects when rendered on screen. It may not be needed and it may be a silly idea, but it is completely unrelated to what I was saying about the framerate.