lol, what a....lovely drawing. There should be no firing of any gun whilst on a ladder, this is supposed to be a fast paced first person shooter if you're stopping on a ladder to fire your weapon you'll be om nom'd by a skulk guaranteed.
<!--quoteo(post=1799390:date=Sep 21 2010, 09:04 PM:name=6john)--><div class='quotetop'>QUOTE (6john @ Sep 21 2010, 09:04 PM) <a href="index.php?act=findpost&pid=1799390"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->From my experience, compression only increases the size of small dataset ( < ~50kb) but is much much more effective on larger datasets ( can go from 30mb to 300kb)
for compression to do any help in the netcode, every tick would have to currently be sending > 50kb to each client, and on a 30 ticks/sec server with 32 people on it, this would require an outgoing bandwidth of 48mb/s<!--QuoteEnd--></div><!--QuoteEEnd-->
You're very, very wrong here; you're refering to a specific type of compression as is done by something like .winrar, .bzip, .zip etc. This is a type of lossless compression intended for large files, using "dictionaries" generated from the file itself(which is how they are able to be so general).
The most valuable form of compression for games is to send a delta update from the last acknowledged game state recieved by the client. You don't need to send the state of a resting physics object because the client can just assume that it is still resting unless told otherwise. You don't need to inform players that turrets, hydras and other buildings are just continuing their idle animation; you only send an update when they actually do something that the client cannot predict(e.g. this hydra should begin playing the 'alert-animation' or 'attack-animation'). You can even omit the z-coordinate of players if the client knows they are on the floor, you only need to know once they jump or slide down a slope or something. Players do not need to recieve updates on inactive players(not necessarily AFK, may just be standing still for a fraction of a second); they can just assume they continue what they're doing(in the case of an AFK player, that would be to play the idle animation, for an active player that may be to continue playing the reload animation).
If a player isn't visible you don't have to send any information of its precise whereabouts(approximate location is required for playing back sounds), view angles and so on. If a player is outside audible range you don't have to send audible information even if you can see him(this should almost never happen in NS2). If a player is running in an almost straight line client side prediction will work admirably and the server can push out less frequent updates about that player(say every second or third packet) as long as the behaviour persists.
Angles are often represented internally as single precision floating point numbers; sometimes as 4x4 transformation matrices(but usually you'd just reconstruct the new matrix from the updated angle each frame). If you map the angle to 0 to 255(or -127 to +128) and round it to a 1-byte integer you will have an error of at most .7 degrees; for some angles this is close enough. You're not going to notice if an enemy player is rotated .7 degrees too much to the left or aiming his gun .7 degrees too low, or if a physics objects(not debris, they don't affect the world and can be generated solely on the client) is .7 degrees or less off on yaw, pitch or roll.
Knowing the top speed of a player you can send the change in position rather than the actual position; you need much less precision to represent this change in position since the last ACKed package than you need to represent the absolute position of the player. This is actually rather tricky since you have to allow for packet loss/latency so that you rarely need to send a full update on the player position. E.g. if the max change in position is 64 units in the time it takes to send 8 updates from the server to the client then you could package the change in position into a single byte with a maximum error of 0.125 units; note that the error does not accumulate if the server keeps track of the error caused by rounding and takes account of it in the next update.
You can pack bit flags in a suitably sized integer and use bitwise operations to set and read the flag you are interested in with negligible speed penalty. For the sake of speed you will generally use the native sized integer. That means 32-bits in 32-bit windows OSs and 64-bits in 64-bit OSs. The reasons it is in general faster to use the native type is that modern processors generally read aligned 16-byte blocks into memory regardless of wheter the data type is a char or __m128; if your read happens to straddle across a 16-byte boundary(as can happen when you mix 32- and 64-bit data types) the processor will fetch 2 blocks of 16-bytes each into cache, polluting the precious L1 cache with data you are unlikely to use. But when the client or server are all done with the calculations and go to send this over the internet the most precious resource is bandwidth; if there are <8 flags you're only going to send a byte, if there are <16 you're only going to send a short int.
You should be able to get a good factor of two or more on player chat messages; but it's probably not worth doing because chat doesn't represent that much bandwidth. Text messages are usually written in roman letters, often english. Armed with this information you can pre-build a dictionary for huffman encoding(very simplistic coding scheme, but works rather well for text) using the frequency at which letters appear in written english. The dictionary is just a binary tree with 256 leaf-nodes each containing a byte; probably you also want a look-up table of ~512 bytes to speed up decoding of the most common bit-sequences(if 'a' is represented as '101' any '101xxxxx' in the LUT would contain an 'a' and the number of bits represented by it). You never have to send the dictionary because both client and server will have it as part of the game installation. A message written in chinese or some crazy wingdings nonsense will likely be longer than without huffman encoding using this dictionary. A simple algorithm is to try huffman encoding on the client before it sends the message, if it becomes bigger, send the message without huffman encoding.
If you happen to know the statistical distribution of a variable there is often some coding which allows you to approach the optimal.(e.g. Elias gamma coding, Fibbonacci coding, unary coding, rice coding ...).
<!--quoteo(post=1799451:date=Sep 22 2010, 12:22 PM:name=Revi.uk)--><div class='quotetop'>QUOTE (Revi.uk @ Sep 22 2010, 12:22 PM) <a href="index.php?act=findpost&pid=1799451"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->There should be no firing of any gun whilst on a ladder, this is supposed to be a fast paced first person shooter if you're stopping on a ladder to fire your weapon you'll be om nom'd by a skulk guaranteed.<!--QuoteEnd--></div><!--QuoteEEnd-->
In NS1 you can just continue climbing the ladder while firing your gun. I'd like to keep that, but it's probably impossible to make an animation for climbing a ladder whilst firing that doesn't look very silly.
Kouji_SanSr. Hινε UÏкεεÏεг - EUPT DeputyThe NetherlandsJoin Date: 2003-05-13Member: 16271Members, NS2 Playtester, Squad Five Blue
<!--quoteo(post=1799474:date=Sep 22 2010, 06:39 PM:name=Soylent_green)--><div class='quotetop'>QUOTE (Soylent_green @ Sep 22 2010, 06:39 PM) <a href="index.php?act=findpost&pid=1799474"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Ladder assisted levitation.<!--QuoteEnd--></div><!--QuoteEEnd--> We have an explanation on Scorpions that Hovar without flappin'!!!
douchebagatronCustom member titleJoin Date: 2003-12-20Member: 24581Members, Constellation, Reinforced - Shadow
<!--quoteo(post=1799469:date=Sep 22 2010, 01:31 PM:name=Soylent_green)--><div class='quotetop'>QUOTE (Soylent_green @ Sep 22 2010, 01:31 PM) <a href="index.php?act=findpost&pid=1799469"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->You're very, very wrong here; you're refering to a specific type of compression as is done by something like .winrar, .bzip, .zip etc. This is a type of lossless compression intended for large files, using "dictionaries" generated from the file itself(which is how they are able to be so general).
The most valuable form of compression for games is to send a delta update from the last acknowledged game state recieved by the client. You don't need to send the state of a resting physics object because the client can just assume that it is still resting unless told otherwise. You don't need to inform players that turrets, hydras and other buildings are just continuing their idle animation; you only send an update when they actually do something that the client cannot predict(e.g. this hydra should begin playing the 'alert-animation' or 'attack-animation'). You can even omit the z-coordinate of players if the client knows they are on the floor, you only need to know once they jump or slide down a slope or something. Players do not need to recieve updates on inactive players(not necessarily AFK, may just be standing still for a fraction of a second); they can just assume they continue what they're doing(in the case of an AFK player, that would be to play the idle animation, for an active player that may be to continue playing the reload animation).
If a player isn't visible you don't have to send any information of its precise whereabouts(approximate location is required for playing back sounds), view angles and so on. If a player is outside audible range you don't have to send audible information even if you can see him(this should almost never happen in NS2). If a player is running in an almost straight line client side prediction will work admirably and the server can push out less frequent updates about that player(say every second or third packet) as long as the behaviour persists.
Angles are often represented internally as single precision floating point numbers; sometimes as 4x4 transformation matrices(but usually you'd just reconstruct the new matrix from the updated angle each frame). If you map the angle to 0 to 255(or -127 to +128) and round it to a 1-byte integer you will have an error of at most .7 degrees; for some angles this is close enough. You're not going to notice if an enemy player is rotated .7 degrees too much to the left or aiming his gun .7 degrees too low, or if a physics objects(not debris, they don't affect the world and can be generated solely on the client) is .7 degrees or less off on yaw, pitch or roll.
Knowing the top speed of a player you can send the change in position rather than the actual position; you need much less precision to represent this change in position since the last ACKed package than you need to represent the absolute position of the player. This is actually rather tricky since you have to allow for packet loss/latency so that you rarely need to send a full update on the player position. E.g. if the max change in position is 64 units in the time it takes to send 8 updates from the server to the client then you could package the change in position into a single byte with a maximum error of 0.125 units; note that the error does not accumulate if the server keeps track of the error caused by rounding and takes account of it in the next update.
You can pack bit flags in a suitably sized integer and use bitwise operations to set and read the flag you are interested in with negligible speed penalty. For the sake of speed you will generally use the native sized integer. That means 32-bits in 32-bit windows OSs and 64-bits in 64-bit OSs. The reasons it is in general faster to use the native type is that modern processors generally read aligned 16-byte blocks into memory regardless of wheter the data type is a char or __m128; if your read happens to straddle across a 16-byte boundary(as can happen when you mix 32- and 64-bit data types) the processor will fetch 2 blocks of 16-bytes each into cache, polluting the precious L1 cache with data you are unlikely to use. But when the client or server are all done with the calculations and go to send this over the internet the most precious resource is bandwidth; if there are <8 flags you're only going to send a byte, if there are <16 you're only going to send a short int.
You should be able to get a good factor of two or more on player chat messages; but it's probably not worth doing because chat doesn't represent that much bandwidth. Text messages are usually written in roman letters, often english. Armed with this information you can pre-build a dictionary for huffman encoding(very simplistic coding scheme, but works rather well for text) using the frequency at which letters appear in written english. The dictionary is just a binary tree with 256 leaf-nodes each containing a byte; probably you also want a look-up table of ~512 bytes to speed up decoding of the most common bit-sequences(if 'a' is represented as '101' any '101xxxxx' in the LUT would contain an 'a' and the number of bits represented by it). You never have to send the dictionary because both client and server will have it as part of the game installation. A message written in chinese or some crazy wingdings nonsense will likely be longer than without huffman encoding using this dictionary. A simple algorithm is to try huffman encoding on the client before it sends the message, if it becomes bigger, send the message without huffman encoding.
If you happen to know the statistical distribution of a variable there is often some coding which allows you to approach the optimal.(e.g. Elias gamma coding, Fibbonacci coding, unary coding, rice coding ...).<!--QuoteEnd--></div><!--QuoteEEnd-->
The majority of what you speak of here I have never heard referred to as compression, but networking tricks to reduce the necessary bandwidth. Compression is encoding a dataset into a smaller dataset by use of some algorithm. This is generally more applicable in datasets with repetition since it provides more effective compression. What you're speaking of is very useful, and I recall reading about many of these types of tricks used in L4D, but not really compression
It's possible that Max was meaning what you describe, but I take it to mean that he is planning to implement a form of data stream compression, such as <a href="http://en.wikipedia.org/wiki/Gzip" target="_blank">gzip</a>, which is a commonly used data compression algorithm, and is even supported in most, if not all, browsers for compression of data streams sent from websites and is basically a standard of http.
<!--quoteo(post=1799500:date=Sep 22 2010, 06:05 PM:name=6john)--><div class='quotetop'>QUOTE (6john @ Sep 22 2010, 06:05 PM) <a href="index.php?act=findpost&pid=1799500"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->The majority of what you speak of here I have never heard referred to as compression, but networking tricks to reduce the necessary bandwidth.Compression is encoding a dataset into a smaller dataset by use of some algorithm.<!--QuoteEnd--></div><!--QuoteEEnd-->
Which is exactly what all these 'tricks' do. E.g.
Big data set: state of all objects in the entire level -> smaller data set: state of all objects a player is affected by.(lossy compression) Big data set: state of all objects a player is affected by -> small data set: Only the states that have changed since last ACK.(a form of differential compression) Big data set: float -> small data set: byte or word.(lossy compression) Big data set: plain text -> small data set: huffman coded text if and only if it shrinks the size of the message. (huffman compression)
ETA:Yes it's quite possible that Max means 'generic' data compression of the whole packet. And if that's the case they're not going to send a 'dictionary'/'alphabet' to the client in each packet. If a a few suitable dictionaries are pre-generated you can just try each one and use the one which generates the smallest message(which sometimes may be uncompressed).
<!--quoteo(post=1799500:date=Sep 22 2010, 06:05 PM:name=6john)--><div class='quotetop'>QUOTE (6john @ Sep 22 2010, 06:05 PM) <a href="index.php?act=findpost&pid=1799500"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->This is generally more applicable in datasets with repetition since it provides more effective compression.<!--QuoteEnd--></div><!--QuoteEEnd-->
I believe you're still thinking of lossless compression. Lossy compression is a bag of cheap kludges and tricks. See jpeg, mpeg, mp3 and the rest.
<!--quoteo(post=1799451:date=Sep 22 2010, 12:22 PM:name=Revi.uk)--><div class='quotetop'>QUOTE (Revi.uk @ Sep 22 2010, 12:22 PM) <a href="index.php?act=findpost&pid=1799451"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->lol, what a....lovely drawing. There should be no firing of any gun whilst on a ladder, this is supposed to be a fast paced first person shooter if you're stopping on a ladder to fire your weapon you'll be om nom'd by a skulk guaranteed.<!--QuoteEnd--></div><!--QuoteEEnd-->
<!--quoteo(post=1799697:date=Sep 24 2010, 11:35 AM:name=Tig)--><div class='quotetop'>QUOTE (Tig @ Sep 24 2010, 11:35 AM) <a href="index.php?act=findpost&pid=1799697"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->maybe you should offer to help Max with the network bugs and the compression?<!--QuoteEnd--></div><!--QuoteEEnd-->
<!--quoteo(post=1799694:date=Sep 24 2010, 04:19 PM:name=Tig)--><div class='quotetop'>QUOTE (Tig @ Sep 24 2010, 04:19 PM) <a href="index.php?act=findpost&pid=1799694"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->i will om nom you in the next patch.<!--QuoteEnd--></div><!--QuoteEEnd-->
Jon is Jon Finger, the guy who used to help us with all the video blogs, as well as the NS2 Teaser movie. Awhile back he wrote up a lengthy and detailed email describing some thoughts and issues he had, some of them related to player movement feel, that Charlie agreed with.
It was simply added to pivotal tracker as a task to address Jon's movement "feel", mostly so that Charlie could be reminded about some specifics regarding what areas to look into when it came time to work on that aspect of gameplay.
Comments
i really hope that you can slide down ladders like cool people do in the movies :)
:D
for compression to do any help in the netcode, every tick would have to currently be sending > 50kb to each client, and on a 30 ticks/sec server with 32 people on it, this would require an outgoing bandwidth of 48mb/s<!--QuoteEnd--></div><!--QuoteEEnd-->
You're very, very wrong here; you're refering to a specific type of compression as is done by something like .winrar, .bzip, .zip etc. This is a type of lossless compression intended for large files, using "dictionaries" generated from the file itself(which is how they are able to be so general).
The most valuable form of compression for games is to send a delta update from the last acknowledged game state recieved by the client. You don't need to send the state of a resting physics object because the client can just assume that it is still resting unless told otherwise. You don't need to inform players that turrets, hydras and other buildings are just continuing their idle animation; you only send an update when they actually do something that the client cannot predict(e.g. this hydra should begin playing the 'alert-animation' or 'attack-animation'). You can even omit the z-coordinate of players if the client knows they are on the floor, you only need to know once they jump or slide down a slope or something. Players do not need to recieve updates on inactive players(not necessarily AFK, may just be standing still for a fraction of a second); they can just assume they continue what they're doing(in the case of an AFK player, that would be to play the idle animation, for an active player that may be to continue playing the reload animation).
If a player isn't visible you don't have to send any information of its precise whereabouts(approximate location is required for playing back sounds), view angles and so on. If a player is outside audible range you don't have to send audible information even if you can see him(this should almost never happen in NS2). If a player is running in an almost straight line client side prediction will work admirably and the server can push out less frequent updates about that player(say every second or third packet) as long as the behaviour persists.
Angles are often represented internally as single precision floating point numbers; sometimes as 4x4 transformation matrices(but usually you'd just reconstruct the new matrix from the updated angle each frame). If you map the angle to 0 to 255(or -127 to +128) and round it to a 1-byte integer you will have an error of at most .7 degrees; for some angles this is close enough. You're not going to notice if an enemy player is rotated .7 degrees too much to the left or aiming his gun .7 degrees too low, or if a physics objects(not debris, they don't affect the world and can be generated solely on the client) is .7 degrees or less off on yaw, pitch or roll.
Knowing the top speed of a player you can send the change in position rather than the actual position; you need much less precision to represent this change in position since the last ACKed package than you need to represent the absolute position of the player. This is actually rather tricky since you have to allow for packet loss/latency so that you rarely need to send a full update on the player position. E.g. if the max change in position is 64 units in the time it takes to send 8 updates from the server to the client then you could package the change in position into a single byte with a maximum error of 0.125 units; note that the error does not accumulate if the server keeps track of the error caused by rounding and takes account of it in the next update.
You can pack bit flags in a suitably sized integer and use bitwise operations to set and read the flag you are interested in with negligible speed penalty. For the sake of speed you will generally use the native sized integer. That means 32-bits in 32-bit windows OSs and 64-bits in 64-bit OSs. The reasons it is in general faster to use the native type is that modern processors generally read aligned 16-byte blocks into memory regardless of wheter the data type is a char or __m128; if your read happens to straddle across a 16-byte boundary(as can happen when you mix 32- and 64-bit data types) the processor will fetch 2 blocks of 16-bytes each into cache, polluting the precious L1 cache with data you are unlikely to use. But when the client or server are all done with the calculations and go to send this over the internet the most precious resource is bandwidth; if there are <8 flags you're only going to send a byte, if there are <16 you're only going to send a short int.
You should be able to get a good factor of two or more on player chat messages; but it's probably not worth doing because chat doesn't represent that much bandwidth. Text messages are usually written in roman letters, often english. Armed with this information you can pre-build a dictionary for huffman encoding(very simplistic coding scheme, but works rather well for text) using the frequency at which letters appear in written english. The dictionary is just a binary tree with 256 leaf-nodes each containing a byte; probably you also want a look-up table of ~512 bytes to speed up decoding of the most common bit-sequences(if 'a' is represented as '101' any '101xxxxx' in the LUT would contain an 'a' and the number of bits represented by it). You never have to send the dictionary because both client and server will have it as part of the game installation. A message written in chinese or some crazy wingdings nonsense will likely be longer than without huffman encoding using this dictionary. A simple algorithm is to try huffman encoding on the client before it sends the message, if it becomes bigger, send the message without huffman encoding.
If you happen to know the statistical distribution of a variable there is often some coding which allows you to approach the optimal.(e.g. Elias gamma coding, Fibbonacci coding, unary coding, rice coding ...).
In NS1 you can just continue climbing the ladder while firing your gun. I'd like to keep that, but it's probably impossible to make an animation for climbing a ladder whilst firing that doesn't look very silly.
Ladder assisted levitation.
We have an explanation on Scorpions that Hovar without flappin'!!!
The most valuable form of compression for games is to send a delta update from the last acknowledged game state recieved by the client. You don't need to send the state of a resting physics object because the client can just assume that it is still resting unless told otherwise. You don't need to inform players that turrets, hydras and other buildings are just continuing their idle animation; you only send an update when they actually do something that the client cannot predict(e.g. this hydra should begin playing the 'alert-animation' or 'attack-animation'). You can even omit the z-coordinate of players if the client knows they are on the floor, you only need to know once they jump or slide down a slope or something. Players do not need to recieve updates on inactive players(not necessarily AFK, may just be standing still for a fraction of a second); they can just assume they continue what they're doing(in the case of an AFK player, that would be to play the idle animation, for an active player that may be to continue playing the reload animation).
If a player isn't visible you don't have to send any information of its precise whereabouts(approximate location is required for playing back sounds), view angles and so on. If a player is outside audible range you don't have to send audible information even if you can see him(this should almost never happen in NS2). If a player is running in an almost straight line client side prediction will work admirably and the server can push out less frequent updates about that player(say every second or third packet) as long as the behaviour persists.
Angles are often represented internally as single precision floating point numbers; sometimes as 4x4 transformation matrices(but usually you'd just reconstruct the new matrix from the updated angle each frame). If you map the angle to 0 to 255(or -127 to +128) and round it to a 1-byte integer you will have an error of at most .7 degrees; for some angles this is close enough. You're not going to notice if an enemy player is rotated .7 degrees too much to the left or aiming his gun .7 degrees too low, or if a physics objects(not debris, they don't affect the world and can be generated solely on the client) is .7 degrees or less off on yaw, pitch or roll.
Knowing the top speed of a player you can send the change in position rather than the actual position; you need much less precision to represent this change in position since the last ACKed package than you need to represent the absolute position of the player. This is actually rather tricky since you have to allow for packet loss/latency so that you rarely need to send a full update on the player position. E.g. if the max change in position is 64 units in the time it takes to send 8 updates from the server to the client then you could package the change in position into a single byte with a maximum error of 0.125 units; note that the error does not accumulate if the server keeps track of the error caused by rounding and takes account of it in the next update.
You can pack bit flags in a suitably sized integer and use bitwise operations to set and read the flag you are interested in with negligible speed penalty. For the sake of speed you will generally use the native sized integer. That means 32-bits in 32-bit windows OSs and 64-bits in 64-bit OSs. The reasons it is in general faster to use the native type is that modern processors generally read aligned 16-byte blocks into memory regardless of wheter the data type is a char or __m128; if your read happens to straddle across a 16-byte boundary(as can happen when you mix 32- and 64-bit data types) the processor will fetch 2 blocks of 16-bytes each into cache, polluting the precious L1 cache with data you are unlikely to use. But when the client or server are all done with the calculations and go to send this over the internet the most precious resource is bandwidth; if there are <8 flags you're only going to send a byte, if there are <16 you're only going to send a short int.
You should be able to get a good factor of two or more on player chat messages; but it's probably not worth doing because chat doesn't represent that much bandwidth. Text messages are usually written in roman letters, often english. Armed with this information you can pre-build a dictionary for huffman encoding(very simplistic coding scheme, but works rather well for text) using the frequency at which letters appear in written english. The dictionary is just a binary tree with 256 leaf-nodes each containing a byte; probably you also want a look-up table of ~512 bytes to speed up decoding of the most common bit-sequences(if 'a' is represented as '101' any '101xxxxx' in the LUT would contain an 'a' and the number of bits represented by it). You never have to send the dictionary because both client and server will have it as part of the game installation. A message written in chinese or some crazy wingdings nonsense will likely be longer than without huffman encoding using this dictionary. A simple algorithm is to try huffman encoding on the client before it sends the message, if it becomes bigger, send the message without huffman encoding.
If you happen to know the statistical distribution of a variable there is often some coding which allows you to approach the optimal.(e.g. Elias gamma coding, Fibbonacci coding, unary coding, rice coding ...).<!--QuoteEnd--></div><!--QuoteEEnd-->
The majority of what you speak of here I have never heard referred to as compression, but networking tricks to reduce the necessary bandwidth. Compression is encoding a dataset into a smaller dataset by use of some algorithm. This is generally more applicable in datasets with repetition since it provides more effective compression. What you're speaking of is very useful, and I recall reading about many of these types of tricks used in L4D, but not really compression
It's possible that Max was meaning what you describe, but I take it to mean that he is planning to implement a form of data stream compression, such as <a href="http://en.wikipedia.org/wiki/Gzip" target="_blank">gzip</a>, which is a commonly used data compression algorithm, and is even supported in most, if not all, browsers for compression of data streams sent from websites and is basically a standard of http.
Which is exactly what all these 'tricks' do. E.g.
Big data set: state of all objects in the entire level -> smaller data set: state of all objects a player is affected by.(lossy compression)
Big data set: state of all objects a player is affected by -> small data set: Only the states that have changed since last ACK.(a form of differential compression)
Big data set: float -> small data set: byte or word.(lossy compression)
Big data set: plain text -> small data set: huffman coded text if and only if it shrinks the size of the message. (huffman compression)
ETA:Yes it's quite possible that Max means 'generic' data compression of the whole packet. And if that's the case they're not going to send a 'dictionary'/'alphabet' to the client in each packet. If a a few suitable dictionaries are pre-generated you can just try each one and use the one which generates the smallest message(which sometimes may be uncompressed).
<!--quoteo(post=1799500:date=Sep 22 2010, 06:05 PM:name=6john)--><div class='quotetop'>QUOTE (6john @ Sep 22 2010, 06:05 PM) <a href="index.php?act=findpost&pid=1799500"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->This is generally more applicable in datasets with repetition since it provides more effective compression.<!--QuoteEnd--></div><!--QuoteEEnd-->
I believe you're still thinking of lossless compression. Lossy compression is a bag of cheap kludges and tricks. See jpeg, mpeg, mp3 and the rest.
looks like patch is nearly ready *giggles* and runs around
Huh, that was quick. Must have only been the basic code for it.
^ damn ninjas
I'm afraid we can't be stopped.
<img src="http://2.bp.blogspot.com/_enCSP5s7zfg/S8duj75doZI/AAAAAAAAAGk/ejG3QIcFPEY/s1600/cartoon-ninja-11.gif" border="0" class="linked-image" />
I can wait another week but the more stuff you put into the patch, the more i want to play it now.
Mmmmmmmmm, corn.
i will om nom you in the next patch.
maybe you should offer to help Max with the network bugs and the compression?
I don't think he needs or wants my help.
I look forward to it.
Whasa? o.O
Whasa? o.O<!--QuoteEnd--></div><!--QuoteEEnd-->
lol, wth?
Jons Movement Feel, is the governing law which makes movement in all virtual worlds believable and fun? :)
I lol'd.
It was simply added to pivotal tracker as a task to address Jon's movement "feel", mostly so that Charlie could be reminded about some specifics regarding what areas to look into when it came time to work on that aspect of gameplay.
--Cory