Edit: I can see that nobody really gets what I'm trying to say. I did some more research on delta gamestates and I found out how/what they do, but heres one simple question: How do you do delta "compression": How does it "compress" information? [edited by - Karl G on August 17, 2003 1:44:03 PM]

Put all ur important data in a first buffer, store that buffer. On the next update compute a second buffer ( make sure same order, and context as the first). Take the difference byte wise between the 2 buffers, the difference is the delta buffer. This delta buffer has various properites, one of which is that if your data doesnt'' change much there will be alot of zeros in it.

Because of this, u can use a simple compression algoithim called Run Length Encoding to reduce the runs of zeros into a more compact form. The resulting buffer is then sent to the client. And all the operations are done in reverse to retrive the original 2nd buffer. This presumes the client has the first buffer already.

if you have access to a more advance compression lib, like zlib u can give it the delta buffer and it can compress it using huffman compression as well as RLE. The resutling compact buffer should be smaller than the RLE buffer alone, ofcourse this is a tradeoff between cpu vs speed.

-ddn

Then what happens when an ACK packet is lost from the client to the server? If I''m understanding correctly, that would throw off the entire system...

The scheme is very brittle if you constantly update the master buffer ( the buffer from which the delta are generated ) but usually the master buffer has a lifetime on the order of seconds and has resync protocols in place if it''s not recived in time.

Its a type of running compression.

-ddn