[tsc-devel] Re: Binary versus XML for the levels...

datahead | Mon, 02 Nov 2015 12:35:28 UTC

Post via forum by datahead <…9@x…>:
This was grimshaw's response:
[quote]
Yeah, reading C++ objects in the binary form will never be 100% efficient, but it can approach that pretty close. But it will depend on how you design it too.
Even with some imperfections it will beat the hell out of XML, as it needs a lot of lexical parsing and making sense of all that data into runtime structures, which then need to be iterated and the data extracted for the final in memory structs.

If you are able to design your scene objects around POD structs, then you can optimize this to a really fast system. You'd have to commit to POD data fields only, but then you could achieve an almost zero overhead level format.

For example, I inspected your level format, and there is a lot of <sprite> objects. In C++ it could look like struct SpriteInstance { char texture[256]; float x; float y; }. This is just an example that doesn't try to cover the real scenario.
There, you abdicate a std::string utility for a flat data layout. When you do this, you can indeed guarantee a 2 step loading of ALL the sprites in your scene:

{
std::vector<SpriteInstance> sprites(numSpritesInTheFile);
fread(&sprites[0], sizeof(SpriteInstance), numSpritesInTheFile, filePointer);
}

You can't go much faster than this for data file loading. In theory sure, you could compress or quantize or whatever to try to squeeze some more seconds out of it, but its probably not worth.
[/quote]

He estimated binary as being 150% faster than the xml implementation, though he emphasized that estimate is very rough based on intuition and experience only.

I'd be interested in performing a benchmark test to compare the two methods, though it will probably be some time before I find time to do this, given the need for SFML port work and story reviewing for TSC.

[quote]Apart from that I find binary file formats a nightmare for debugging purposes.[/quote]

We would be using XML for most debugging, and we would make this the most visible format to end users who create levels.  As for the binary used for the campaign release or that is cached for user levels, we would keep it as simple as possible using the POD approach that Grimshaw suggested.

We might end up doing things slightly differently if it suits us, but I did get something somewhat similar to this with POD objects to work in order to "auto serialize" objects in .NET for a space shooter game once.




-- 
Sent by Chessboard.