The main problem is the way that Windows and Mac OS X operating systems each handle their file systems. If you've ever looked into the hardware or lower level of how data is stored, there is one of 2 ways (well I believe there are more, but 2 basic approaches) big endian and little endian. Essentially the bit order goes one way on one platform and the other platform has the bit ordering going the other way. 0 bit is on the left versus 0 bit being on the right.
This is a royal pain to have to convert or even more annoying to have to rig your programs to read data the wrong way on the other platform.
The advantage of using a text file based format (like XML) is that text files are pretty much read and written to the exact same way no matter the bit order on your OS. Using something like an XML library has the added advantage of a node system so its even easier to read your attributes and values instead of having to parse everything. Plus the added flexibility of being able to script your data quazi-HTML style.
You could use something like JSON or even Lua, which people have also recommended for adding a higher level of functionality. I like how simple XML is however.
Doesn't TStream-s have platform based implementation of memory or file handling so you don't have to worry about the Big-Endian and Litle-Endian by yourself.
I do realize that the way how Typed Files work is platform dependant (based on Delphi-s hint it generates whenever I use them).
Also since newest Delphi version do have support for Mac OS X I would suggest that this is being overcome in RTTI itself. So far I haven't tried doing any multiplatform stuff as I don't own Mac OS X based platform device myself.
Last edited by SilverWarior; 01-08-2013 at 08:39 PM.
I really don't think so. I battled with this issue myself while working on Garland's Quest looking for solutions. Trying to force the compiler to think differently just causes problems too. This was the case I found while working with Lazarus with both Win and Mac. Text handling is a universal solution across platforms.
Mac are nice to run in place of a Windows machine these days. But that's a highly debated topic. (Cost considerations pending.) Development is still kind of getting there in my own personal opinion. Doing cross-platform really does require you have the hardware or software of the platform you are trying to support. How else can you tell that it's working as intended, right?
That's not -quite- accurate, but close.
The issue isn't with bit ordering, but with the order in which whole bytes of multi-byte data structures (like 32-bit integers, for example) are stored. With Little-Endian (Intel), the least significant byte (with bit position values 1 to 128 ) is stored first at the lower memory address, then the next, etc. With Big-Endian (SPARC, various RISC processors), the most significant byte (with bit position values 16777216-2147483648 ) is stored first, then the next, etc, down to the least significant byte last at the higher memory address.
Well, it really only matters if you use multi-byte data structures. If you treat the whole thing as an array of byte, then you won't run into problems. The issue becomes a problem because you won't be able to use anything but Char and SmallInt/Byte that way. As soon as you want to use a Word/Integer/LongInt/etc, you have to use the platform byte-swap functions on them before you can use them.This is a royal pain to have to convert or even more annoying to have to rig your programs to read data the wrong way on the other platform.
The advantage of using a text file based format (like XML) is that text files are pretty much read and written to the exact same way no matter the bit order on your OS. Using something like an XML library has the added advantage of a node system so its even easier to read your attributes and values instead of having to parse everything. Plus the added flexibility of being able to script your data quazi-HTML style.
You could use something like JSON or even Lua, which people have also recommended for adding a higher level of functionality. I like how simple XML is however.
Now, you can argue that it is a pain, but is it really that much more a pain than using some kind of text parser? It is easy enough to encapsulate the details of a binary storage class which takes care of any endianness normalization (and plenty of libraries do).
That said, another big advantage to text-based data storage is the ability to go into it manually with an editor for verification/modification.
Yes I was. I don't care for bloat and unnecessary build up of dependencies so XML was another win for me since it was already included with FPC.
The added benefit to using XML was that I now was able to open up any text editor and edit my levels without having to use specific or custom-made tools. Further adding features or storing new information you could potentially break your in-house design tools and corrupt your game forcing you to use something like a hex editor to conform it. Where text is much easier to open and read.
Bringing the thread back on topic though; You can see that databases are nowhere near as usful for storing game data as other methods.
Yeah, for most non-MMO-type games, a RDBMS is totally useless. Game content doesn't need it, but many games do use a library-style custom (often binary) format for game data. A few of them even use zip files and incorporate zlib to access them. <.<
Even still, it all depends on what you're storing and how you need to access it. Each format/methodology has its advantages and disadvantages for different needs.
Bookmarks