Creo que es seguro asumir que cada plataforma tiene una implementación de la especificación IEE-754 en la que puede confiar, sin embargo, incluso si implementan la misma especificación, no hay garantía de que cada plataforma tenga exactamente la misma implementación, tiene los mismos indicadores de control de FP establecidos, realiza las mismas optimizaciones o implementa las mismas extensiones no estándar. Esto hace que el determinismo de coma flotante sea muy difícil de controlar y algo poco confiable de usar para este tipo de cosas (donde se comunicarán los valores de PF a través de la red).
Para obtener más información al respecto; leer http://gafferongames.com/networking-for-game-programmers/floating-point-determinism/
Otro problema para resolver es el manejo de clientes que no tienen una unidad de coma flotante; la mayoría de las veces serán CPU, consolas o dispositivos integrados de gama baja. Asegúrese de tener esto en cuenta si desea orientarlos. La emulación de FP se puede hacer, pero tiende a ser muy lenta en estos dispositivos, por lo que tendrá que acostumbrarse a hacer cálculos de punto fijo. Sin embargo, tenga en cuenta que redactar clases elaboradas para resumir los cálculos de puntos flotantes y puntos fijos en el mismo código suena como un plan; pero en la mayoría de los dispositivos no lo es. No le permite exprimir la máxima precisión y rendimiento cuando se trata de valores de puntos fijos.
Otro problema es manejar la endianidad de los valores de coma flotante porque no puede simplemente intercambiar bytes y apilar 'm en un registro de coma flotante otra vez (los bytes pueden tener un significado diferente, vea http://www.dmh2000.com/cpp/dswap.shtml sobre eso).
Mi consejo sería convertir los flotadores a valores intermedios de punto fijo, hacer una corrección endian si es necesario y transmitir eso. Además, no asuma que dos cálculos de coma flotante en diferentes máquinas producirán los mismos resultados; ellos no. Sin embargo, las implementaciones de punto flotante distintas de IEEE-754 son raras. Por ejemplo, las GPU tienden a usar punto fijo, pero es más probable que tengan un subconjunto de IEEE-754 en estos días porque no quieren lidiar con excepciones de división por cero, pero tendrán extensiones para flotantes que encajan en 16 bits
También tenga en cuenta que hay bibliotecas que ya han resuelto este problema (enviando formatos de datos de bajo nivel en un contexto de juego) por usted. Una de esas librerías es RakNet, específicamente su clase BitStream está diseñada para enviar estos tipos de datos de manera confiable a diferentes plataformas mientras se mantienen los gastos generales al mínimo; por ejemplo, RakNet tiene problemas para no desperdiciar ancho de banda al enviar cadenas o vectores.
El vínculo de determinismo que me diste es muy interesante. Había estado pensando en hacer eso con algunos mensajes más grandes para asegurarme de que los clientes estuvieran sincronizados. Siempre que las posiciones estén lo suficientemente cerca (una unidad es un metro), creo que todo estará bien. No tengo la intención de apuntar a las plataformas de consola y a la mayoría de los sistemas integrados; Ni siquiera estoy seguro de si puedo hacer esto como Software Libre. En cuanto a los procesadores de gama baja, eso es más una preocupación. El problema del intercambio de bytes es muy desafortunado ... Describí brevemente el artículo, pero tendré que leerlo más tarde. ¡Muchas gracias por la información! –
Hay algunas consolas (portátiles) menos conocidas que le permiten publicar software de código abierto para ellas, como GP2X y Open Pandora. El problema del determinismo de punto flotante aparece principalmente cuando se decide descentralizar las rutinas de física (por ejemplo, ejecutarlas en los clientes) o ejecutar repeticiones en máquinas diferentes porque tienden a acumular errores bastante rápido. –