Jump to content
  • Advertisement
Sign in to follow this  
skillfreak

delta compression

This topic is 4884 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Quote from The Quake3 Networking Model (www.bookofhook.com) " For exmaple, let's say the client last ACKed sequence 14. The server is sending out new game states with incrementing sequences. It may be up to seq 20 when it gets an ack from the client that it has received seq 17. The server has to have t eh state that was sent as part of seq 17 in order to rebase the delta compression"(1) Playing the village idiot: In order of incrementing questioning: Does the server only receive ACKs when the client has something useful to say as well? What is to say the reply from the client isn't delayed by the fact it had not quite received all the servers updates, causing an incorrect rebasing upon server send, when really the client has received that information? What is stored as part of state information? and from this, what is 'rebased'? //edit To reduce network bandwidth, the server only transmits changes to entities within a visible range using delta compression. For each server frame update, the server would first determine what entities the client can see, followed by transmitting changes to the visible entities based on the previous frame the client received (delta compression (2) ). -- basicaly the definition of delta compression. Are these changes truly absolutes? Such as position. Or would it be relative off the last client ack? There are conflicting statements (in my mind anyway) between these two posted paragraphs. Rebasing sounds relative. ~~>> yadda yadda still crunching .. if it is relative, then does the server reply with what frame these values are based from.. ( considering part of my second question being the delay and incorrect views due to latency between send/recieve?) If it is delayed, we lose resolution of client data? //~edit ref links: 1: http://www.bookofhook.com/Article/GameDevelopment/TheQuake3NetworkingModel.html 2:http://www.csse.monash.edu.au/~timf/bottim/q2net/q2network-0.03-4.html Still rolling all these things around in my mind, but would def love some expertise. +) Much thanks, ^sf. [Edited by - skillfreak on June 6, 2005 4:39:15 PM]

Share this post


Link to post
Share on other sites
Advertisement
Delta Compression can mean several things. It can mean that you send a bitmask of what parts of data you actually include (position/velocity/orientation/etc, maybe even individual components of those values), and then only send those pieces of data. It can mean that you use the previous value as a baseline, and use a variable-length encoding of data you send, to take advantage of small changes being small to transmit. It can mean other things as well.

Each time the client receives a packet, it saves away the decoded (uncompressed) state for that packet, and sends an ack. When receiving an update packet, the client removes all saved packets older than the packet which the update packet references. The server, when receiving an ack for a specific packet, knows that the next packet being sent can be encoded based on that packet. The actual packet used as base for data is part of the next update.

Typically, you'll truncate packet sequence numbers to some small number of bits, enough to cover only some number of seconds or minutes of uptime, to avoid sending redundant bits -- at some point, if you had lots of dropped packets in a row, you'd drop the client anyway.

Share this post


Link to post
Share on other sites
Ok. This greatly clarifies the blips coming up all over the documents i've been reading.
However, what can you tell me about the following statement:

'Dropped packets are handled implicitly, and specific commands are never acknowledged independently -- last known state acks are piggy backed on regular incoming/outgoing traffic.'

Found in the bottom of the 3rd paragraph of this article
http://www.bookofhook.com/Article/GameDevelopment/TheQuake3NetworkingModel.html

Where you say ACKs are sent in response to every received frame, this claims otherwise, and seems more refined and simplified.

Your input is greatly received.

Share this post


Link to post
Share on other sites
What I mean, and what that sentence means, is that each side, when sending a packet to the other side, adds an indication of what the last known acked message was. That way, both sides know what a late-ish, useable baseline would be. Even with packet loss, it doesn't matter, because the client will never drop old baseline data until data based on a newer baseline is received, and the server won't start baselining on newer data until it has positive confirmation the client actually got it.

At its core, here's what gets sent, assuming only server->client uses delta compression:


server packet to client:
cur packet id
base packet id
data, delta-encoded based on the base packet

client packet to server:
last received cur packet id
client messages to server (controller input, say)



These can be sent independently of each other, and don't even need to be sent at the same rate.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!