How to calculate vehicle movement ?

Archived discussions related to Transport Empire. Read-only access only.

Moderator: Transport Empire Moderators

User avatar
DominionSpy
Tycoon
Tycoon
Posts: 1429
Joined: 03 Oct 2003 23:59
Location: Lancashire, UK
Contact:

Post by DominionSpy »

uzurpator wrote:
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.
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.

All modern games use this mechanism.
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.

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.
uzupator wrote:
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).
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?

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?
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.

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.
Image
You're saying I'm a Dominion spy, and don't even know it! - Dr. Bashir
That's the Joker in my avatar, not me. No wait it is me.
User avatar
uzurpator
Transport Empire Moderator
Transport Empire Moderator
Posts: 2178
Joined: 10 Jan 2003 12:21
Location: Katowice, Poland

Post by uzurpator »

DominionSpy wrote: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.
Why?
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.
I don't recall saying anything about predicting...
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.
Buut - will the client have anything to draw?

Say - a server does constant 30 updates/second. However the client can draw 60 frames/second.

Disregarding client only events (like texture animation etc) this makes every second frame on the client to be a copy of the previous one. Basicly the client will not go above 30 fps due to the fact that it will get 30 updates of data/second.

With movement interpolation (in a form I presented) the client will interpolate the position of a vehicle inbweteen two updates with a price of one frame delay. Such delay is not noticable in a game such as this.
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).
Thus doubling bandwidth needs...

Now a question to you - what to do when a client is slower then server (say 30 updates/sec server and 15 fps client)?
All art and vehicle stats I authored for TT and derivatives are as of now PUBLIC DOMAIN! Use as you see fit
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
fujitsu
Engineer
Engineer
Posts: 32
Joined: 12 Jul 2005 08:14
Location: Melbourne suburbs, Victoria, Australia (GMT+10)

Post by fujitsu »

uzurpator wrote:
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).
Thus doubling bandwidth needs...
Yes, but only from the miniscule amount of bandwidth that would be needed to transmit the data for the small number of tiles that are needed to show something at that zoom level. The point is, if you are close enough to see it jump, you are unlikely to be seeing enough tiles to use much bandwidth, therfore doubling it would be no big deal.
... wrote:Now a question to you - what to do when a client is slower then server (say 30 updates/sec server and 15 fps client)?
Mr. Client simply drops half of the updates, I suppose... But that could be not good...

William.
User avatar
uzurpator
Transport Empire Moderator
Transport Empire Moderator
Posts: 2178
Joined: 10 Jan 2003 12:21
Location: Katowice, Poland

Post by uzurpator »

fujitsu wrote:Yes, but only from the miniscule amount of bandwidth that would be needed to transmit the data for the small number of tiles that are needed to show something at that zoom level. The point is, if you are close enough to see it jump, you are unlikely to be seeing enough tiles to use much bandwidth, therfore doubling it would be no big deal.
Take a look at the screene below - it has a very close zoom level, yet tons of visible space around. It actually has more visible stuff then in higher zoomlevel.
Attachments
RT3_10_26_05__12_38_47.jpg
RT3_10_26_05__12_38_47.jpg (95.85 KiB) Viewed 376 times
All art and vehicle stats I authored for TT and derivatives are as of now PUBLIC DOMAIN! Use as you see fit
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
Locked

Return to “Transport Empire Development Archive”

Who is online

Users browsing this forum: No registered users and 5 guests