You could side step the floating point issue by
using integer to represent floating point values,
this then eliminates floating point maths and can
speed things up a bit. i.e take you maximum value
and divide it by 2^32 (for a standard int) and this
mean 1 represents some really really small unit for
movement or whatever.
Also strings (char) are immune to little endian/big
endian issues, so you could convert your numbers into
bcd and put them into bytes and send them on there way.
ie int: 203323 becomes three bytes of 20 33 23.
om> ----- Original Message -----
From: MIGUEL ANGEL BLANCH LARDIN [mailto:x5101920@fedro.ugr.es]
Sent: Wednesday, January 24, 2001 4:51 PM
To: sdl at lokigames.com
Subject: Re: [SDL] Floating data types…
Mensaje citado por: Mattias Engdeg?rd :
Are floating(double and long double too) data types the same on
all
platforms? That is do they all have the same mantissa, exponent,
endianess… I noticed SDL_net doesn’t have any conversion methods
for
sending floats to machines of different endianess.
2 issues: byte order and fp format. Most contemporary machines use
IEEE floats so you can safely spec that in a protocol. Use either 32
or 64 bit floats; oddball ones like 80 (intel) or 128 (sun) are out,
so are ancient stuff like ibm 360/VAX/Cray fp formats. You can
probably use the ordinary byte order macros to convert endianness
this is not guaranteed but true in reality
I know that Age of Kings are having a lot of problems due to float
point values, as not all the system ( and speaking on x86 system only
:-> ) compute the number in the same way.
To compute the value and having the same result on both system you are
going to need:
a) Same precision
b) Non buggy FPU
c) Good luck
But for common things there shouldn’t be many problems.
http://www.mongeese.orgOn Wed, 24 Jan 2001, Oisin Mulvihill wrote:
You could side step the floating point issue by
using integer to represent floating point values,
this then eliminates floating point maths and can
speed things up a bit. i.e take you maximum value
and divide it by 2^32 (for a standard int) and this
mean 1 represents some really really small unit for
movement or whatever.
The three ways I’ve thought of so far are
- Converting the binary representation, which doesn’t look very feasible.
- Breaking the number into two ints, before and after the decimal point.
- Converting the number to a string of chars and back.
#3 seems to be the best option in that it will retain 100% accuracy. The
problem is that the conversions are slow and the size of the string that
is going to be sent will be quite large. Letting the user specify the
level of accuracy they wish would probably be a good option.
I was thinking of adding this to SDLnet along with some other stuff…
- Converting the number to a string of chars and back.
#3 seems to be the best option in that it will retain 100% accuracy.
no it won’t, unless you’re using a hex fp format a la C99, and even then
you need special attention to stuff like infinities, NaNs and negative zero.
It can be done, but sending the binary is much easier
If you are using the symmetric model of multi-play (all nodes execute
the same code), then you need perfect accuracy to achieve determinism.
Avoid sending floats in that case (in fact, avoid FP at all unless you
really know what you are doing)
There’s nothing wrong with sending binary IEEE numbers if you do it right,
but most people don’t need them and can get by with fixed-point numbers
(scaled integers) instead
For SDL relevance: SDL_endian.h does not yet contain byte-order
conversion macros for floats, but they could be added