Open discussion: What game devs need from Delphi

[Murmandamus]

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.

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.

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.

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.

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.

[WILL]

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).

I find FPC's included XML libraries to be really quite spiffy.

Since I had to fight with Lazarus for months to keep using binary files to do something that just clicked and worked in a matter of hours with XML. Easy choice!

[Murmandamus]

I find FPC's included XML libraries to be really quite spiffy.

Since I had to fight with Lazarus for months to keep using binary files to do something that just clicked and worked in a matter of hours with XML. Easy choice!

Were you doing the binary file stuff from scratch? O.o

I mean, I don't know your application specifics, but there are various binary serialization/storage libraries out there which are a snap to use, depending on your needs.

[WILL]

Were you doing the binary file stuff from scratch? O.o

I mean, I don't know your application specifics, but there are various binary serialization/storage libraries out there which are a snap to use, depending on your needs.

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.

[Murmandamus]

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.