Compressed floats?

BlitzMax Forums/BlitzMax Programming/Compressed floats?

JoshK(Posted 2010) [#1]
Does anyone have code to convert a 32-float to a 16-bit float and back? I would like to try this to lower my physics networking bandwidth.


_Skully(Posted 2010) [#2]
Are you sure you want to do that... the loss of accuracy would be huge.

It would almost be better to multiply the float by your intended accuracy and convert to an INT

val:float=1234.23432
Send:INT=INT(val * 100000.0)
Recv:Float=Float(Send)/100000.0



ImaginaryHuman(Posted 2010) [#3]
Such code used to be in the GNet code by Mark, but I think he took it out to revert back to 32-bit. Maybe if you look at an older version of blitzmax sourcecode?


_Skully(Posted 2010) [#4]
I wonder just how much information is being sent that the difference between 32 and 16 bit floats is going to make that much difference...and there will be a cost of processing that conversion as well


xlsior(Posted 2010) [#5]
Skully: Except an INT is 4 bytes, so you wouldn't actually lower the # of bytes that need to be transmitted...


Czar Flavius(Posted 2010) [#6]
Maybe you could use some kind of maths or bitwise mumbo jumbo to store two 16-bit floats in one 32-bit float variable?


JoshK(Posted 2010) [#7]
I wonder just how much information is being sent that the difference between 32 and 16 bit floats is going to make that much difference...and there will be a cost of processing that conversion as well

If it works it will let me transmit twice as much physics data in the same amount of bandwidth.

I found Mark's code, thanks!



It is a bit sketchy at low velocities, but I can probably send 16-bit floats when the velocity is above a certain threshold.


_Skully(Posted 2010) [#8]
Networked physics with 16 bit floats... good luck man! latency is a KILLER with networked physics, add to that a loss of accuracy... yikes!

You should keep in mind that most successful networked games actually send user input rather than specific game data... Making the game point-in-time predictable is necessary for that of course... but that's what I have extrapolated from all the reading I've done on the topic (of networking games).

It makes a lot of sense.. Lets say your game frame rate is 60hz... if you send a packet that contains user input detected during each frame that would be 1 packet sent every 16.666 ms containing very little data... very efficient! that versus trying to send a bucket load of data every so often and still have the problem of needing to know the point in time that the data is relevant to.


JoshK(Posted 2010) [#9]
It's a lot easier than you might think. I can run dozens of physics bodies at 30 updates per seconds between California and Europe, even though the ping is 200-300. Our results so far are way better than I expected. The way I have the interpolation set up, the movement is always smooth. It's pretty much impossible for any jerky motion to result, and the solution was stupidly simple. Maybe I'll write an article about it when I finish up.


beanage(Posted 2010) [#10]
So you would run the rigid body physics on a server, rely on some stable bandwidth, and save the client some cpu cycles.. sounds keen.. has this been done before?


_Skully(Posted 2010) [#11]
I'd definately be interested in reading it.


JoshK(Posted 2010) [#12]
Actually, the whole physics simulation is performed on the server. It's not so important to save CPU cycles on the client machine, but it does two things.

-The results are consistent. The server dictates to the clients where everything is, and there are no discrepancies.

-Because there aren't multiple interpretations of where things should be, the resulting motion is very smooth.

The only problem we have come across is latency with player movement. Of course, I'm also testing with a 300 msecond latency, so there's no way for it not to be laggy. At least we don't have objects jumping around and teleporting, like most networked games. If we can get a good response time with pings around 50-90, then I will be satisfied.


Retimer(Posted 2010) [#13]
You should keep in mind that most successful networked games actually send user input rather than specific game data


Doesn't the half-life 2 engine do something like this?


_Skully(Posted 2010) [#14]
I'd use a predictive algorithm for movement whereby you can set where in time it would be vs where it is... if its going at a velocity, it had a tick start time and a vector of movement. anyway, use a tight seek between the point its at and the point it needs to be at... this will help smooth the player movement and prevent jittering... of course, you've got all that physics overhead too


xlsior(Posted 2010) [#15]
I'd use a predictive algorithm for movement whereby you can set where in time it would be vs where it is...


That has some advantages, but also disadvantages -- e.g. the 'teleporting' mentioned above when the predicted locations and actual locations aren't the same and catch up with eachother.


_Skully(Posted 2010) [#16]
but that is buffered by the seek point and the actual point effective tween...stops the jumping in the users eyes