Data Management - Printable Version
+- iDevGames Forums (http://www.idevgames.com/forums)
+-- Forum: Development Zone (/forum-3.html)
+--- Forum: iPhone, iPad & iPod Game Development (/forum-11.html)
+--- Thread: Data Management (/thread-9956.html)
Data Management - ajrs84 - Mar 30, 2012 11:40 AM
I'd like to be able to save data (consisting of either a large C struct or an array of C structs) to my computer's desktop from my cocoa editor program and then drag that file over to my iOS app's resource bundle. I find that with certain types of data this works but for other types it doesn't - I tried using both fread()/fwrite() as well as NSData and the results remained the same. Is this the result of some difference between architectures?
RE: Data Management - OneSadCookie - Mar 30, 2012 02:35 PM
That's not very safe, but since ARM and x86 are both little-endian, it can be made to work with some care. I'd suggest adding assertions that sizeof(yourStruct) == whatYouExpect and offsetof(yourStruct, eachField) == whatYouExpect. Sticking to the [u]int[n]_t types from <stdint.h> + float/double and sorting the fields of your structs by size, largest first, will help too.
For maximum safety, serialize each primitive explicitly yourself.
RE: Data Management - ajrs84 - Mar 30, 2012 04:23 PM
Thanks for the reply. So here's just one data struct from my game (which is by the way an open world style rpg so lots of data)....
...From what your telling me this was poor planning on my part
and trying to do what you describe to all of my data seems unrealistic especially considering that I'm not a great programmer and have little experience with really low-level C stuff.
Is there any way out of or around this without having to parse every single struct?
This is a shot in the dark, but might it be possible to reorder all of the structs' fields using bit fields in order to eliminate paddings?
RE: Data Management - OneSadCookie - Mar 30, 2012 08:09 PM
bitfields will reduce portability even further.
There's nothing ridiculously bad about this struct. Replace "int" with "int32_t" (or smaller if you like); replace BOOL with uint8_t; ensure time_interval_t is a typedef off an explicitly sized type, and sort the fields big to small and it should start working... (and of course do the same to the nested struct types).
I really do suggest adding at least the sizeof() assertion though. Better to crash at startup when the assertion fails than corrupt memory or data later.
Doing this the right way is easy too, but verbose:
and similarly for deserialize. Then you just have to implement serialize_float, serialize_int, etc. portably.
RE: Data Management - ajrs84 - Mar 31, 2012 10:30 AM
Thanks OneSadCookie for all of your help.
So for simplicity's sake let's just say that I'm only saving game data from the OS app into the iOS app's docs directory. Should I be concerned about the future portability of this data (i.e. if apple changes the arm architecture in some way that somehow affects the memory mapping or whatever)? ...Or are there other concerns I'm missing? Also, how likely a scenario (the architectual change) do you personally think this is? I'm not adverse to gambling if I feel fairly certain (say 80%+) of its unlikelihood.
RE: Data Management - OneSadCookie - Mar 31, 2012 08:32 PM
You will always be able to write code to read whatever format you decide on now. Just be aware that taking the shortcut now does not necessarily mean you will get away without writing the hard code forever.
Also, always write a few sanity bytes and a version number at the start of each of your custom file formats. Makes it easy to change the format in the future, and to read multiple versions of the format.