Open discussion: What game devs need from Delphi

[pitfiend]

There's only one thing I disagree, we still need some kind of local database component/library. It's easier that way IMHO than using text files. Also want to point that average indie will welcome any cheap dev tools they can find. Access to majoy graphic libraries is a must not only OpenGL, also DirectX & SDL. Having popular game engines headers will not hurt anyone, but will high product price someway (they could be sell as optional packages).

[WILL]

Well there should be DB libraries out there that don't need to be hooked into the whole "components" concept. In fact we don't need anything from that side of the house. Plus now you have the option of finding and using what you like, much like before, but not everyone has to pay the extra price for having them pre-packaged. That just seems way better for everyone than getting hung up on the edition not having it all under the hood.

Instead of text files, I'd highly recommend XML which actually works amazingly as a great cross-platform game data container. To be honest I didn't see the value in the concept until Stoney turned me onto trying it for one of my games. It fixed all my binary data endian problems and made switching between my Windows environment and my Mac environment so much easier. It became almost a thoughtless process even.

I agree that a version of Delphi bundled with all the latest and greatest libraries and translated API headers would be excellent, but I'm wondering if enough people would actually buy into that as a pre-packaged product? Would anyone buy into that if it were another set of tools like Oxygene? (I'd list Lazarus too, but since the tools are all free I doubt someone would pay for something that is all parts free.)

[SilverWarior]

Well there should be DB libraries out there that don't need to be hooked into the whole "components" concept.

You can always make yourself "custom database" using Typed Files. http://delphi.about.com/od/fileio/a/fileof_delphi.htm
The article only shows having single record type per file (signle table per file). So if you want to have multiple record types stored in signle file you have to combine that with the use of mapped files. Article about this on my To-Do list. Time of compleetiomn unknown

The main advantage of making your own "custom database" is that your records can contain fields of almost all Pascal based variable types while most existing databases limitsto their internal field types. The only limitation is that the field variable must have fixed size, no standard strings or dynamical arrays.
Main disadvantage is that such database might not be compatible with non pascal based programs and you have to use mapped file approach if you want to have multiple record types in same file.

[WILL]

Just opened up a new Poll relating to the concept of a Lite Edition of Delphi: http://www.pascalgamedevelopment.com...Delphi-Edition (go vote!)

You can always make yourself "custom database" using Typed Files.

Yes that's always an option. Using binary files across platforms does become a pain though. That could be a weakness in cross-plat games. I would say that including something like a text or parsed format like XML for file storage could help solve that issue.

Overall a DB-based game would only make sense to me in the case where you are moving around or accessing a lot of data at any time. Say an MMO or maybe an always running server-side engine?

[SilverWarior]

Using binary files across platforms does become a pain though.

Why?
I don't have much expirience on other platforms.

[WILL]

Why?
I don't have much expirience on other platforms.

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.

[SilverWarior]

The main problem is the way that Windows and Mac OS X operating systems each handle their file systems.

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.

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