La portabilité est-elle un sujet de préoccupation lorsque vous implémentez la sérialisation binaire de base pour un jeu vidéo? - c ++, linux, windows, sérialisation

J'écris un sérialiseur binaire simple àgénérer des fichiers de sauvegarde pour un jeu vidéo 64 bits ciblant les plates-formes Windows, Mac et Linux 64 bits. Les types de variable sélectionnés pour la sérialisation sont les suivants: char, short, bool, unsigned int, int, float, éventuellement double et éventuellement long int. Je compile sur Visual Studio. La sérialisation est aussi simple que possible, sans contrôles, il suffit d'écrire les données binaires, puis de les désérialiser dans le même ordre. Le jeu enregistre très fréquemment de nouvelles données dans le fichier tout au long du jeu, mais les données ne sont désérialisées qu'une seule fois, juste avant la lecture.

Je ne pensais pas que la portabilité était quelque choseque je devais m'inquiéter avec une simple fonction de sauvegarde; Cependant, j'ai lu beaucoup de choses sur les nombreux problèmes de portabilité associés à la sérialisation binaire (par exemple, représentation en virgule flottante, variations de la largeur de bit des bits, finalité, alignement, etc.) et je ne suis pas assez confiant dans ma compréhension du sujet pour être certain que ces problèmes de portabilité ne surgiront pas avec ce projet. Peut-être que quelqu'un aurait la gentillesse de partager son point de vue sur les hypothèses suivantes:

1. Les variables peuvent être sérialisées en un binaire sur une machine et le binaire peut ensuite être copié et désérialisé en toute sécurité sur un machine différente avec le même système d’exploitation et un processeur x86-64.
2. Si je suppose que toutes les machines exécutant lejeu sont des processeurs de style little-endian x86-64 exécutant des systèmes d'exploitation 64 bits, puis-je supposer que le fichier binaire peut être entièrement portable entre les systèmes d'exploitation aussi?
3. Si je devais développer le développement pour supporter unVersion 32 bits du jeu (en supposant toujours une architecture de processeur x86-64 sur la cible système d'exploitation 32 bits), et un utilisateur final 32 bits décide de passer à un système d'exploitation 64 bits, installe la version 64 bits du jeu et puis charge leur ancien fichier de sauvegarde qui a été sérialisé sur le 32 bits Système d'exploitation exécutant la version 32 bits du jeu - ces types de variables peuvent-ils puis être désérialisé en toute sécurité sur la plate-forme 64 bits dans l'ordre qu'ils ont été sérialisés sans aucun contrôle ou test pour compatibilité?

Est-il possible que l’enregistrement sur une machine et le chargement sur une autre puissent corrompre les données dans l’un de ces scénarios?

Merci d'avance.

Réponses:

Si vous utilisez des types entiers de taille tels que ::std::uint32_t au lieu de types obscurs tels que unsigned long alors vous serez à peu près sauver de l'entierles variations de taille pouvant survenir entre les plates-formes 32 bits / 64 bits et les différents compilateurs. La largeur de bits entière peut techniquement varier, mais uniquement sur des plateformes plutôt exotiques qui ne peuvent certainement pas être considérées comme appropriées pour les jeux. La taille en virgule flottante et la représentation ne devraient pas non plus être une préoccupation.

Pour vous assurer que la taille et l'alignement des structures de données en lecture / écriture restent cohérents sur toutes les plateformes, vous devez utiliser static_assert dans votre code.

Cependant, vérifier l’endianisme est obligatoire si vousvoulez que vos fichiers de sauvegarde soient portables. Généralement, vous souhaiterez peut-être sérialiser les données en utilisant l’endianisme natif et écrire un nombre magique au début du fichier indiquant son endianisme (comme 0x01020304). Ensuite, lorsque vous désérialisez, vérifiez d'abord cette magie et sélectionnez soit le désérialiseur endianness natif (ce qui est plus rapide), soit le désérialiseur endianness inversé (qui est plus lent).