« Notes on *Portal* and *Mirror's Edge* | Main | Notes On Sports »

May 25, 2009

Comments

Paul

Careful with XML on embedded platforms. I found that parsers like TinyXML make tons of tiny allocations as it parses and is a recipe for fragmentation. I actually wound up making my own parser that would perform an analysis pass to determine the memory needed to represent the the DOM and didn't copy any strings, just pointed back to the original allocated chunk the file lived in. It used 2 allocations to parse a file.

Vince

I was recently looking into xml parsers for console and found
RapidXML.

Considerably faster than TinyXML and seems to have better allocation behavior, but I haven't tried it out yet.

Bryan McNett

The fundamental problem with XML and data structure serialization is that there is no single obvious way to represent numbers or arrays.

If you hand a C++ struct definition to two strangers, lock them in separate rooms, and ask one to write an XML writer and the other to write an XML reader for the struct, there is a near 0% chance that the programs will be compatible.

This is not true of image files - if you hand an image definition (size, color depth) to the two strangers, and ask them to write a GIF writer and GIF reader, compatibility is guaranteed.

This is true of JSON as well. Generally speaking, there is only one obvious way to transmit a simple data structure via JSON.

Since your application is C#, you are spared the task of writing "glue code" to serialize structures as XML, because it is in the standard library.

In this sense, XML as a data language is platform-specific.

Yes there are many extra technologies on top of XML to support numbers and arrays, but again there is no single obvious choice, and few are implemented well across all platforms as XML is.

gman

Riffing off seeing Excel and XML in the same post, in my last 2 projects we used Excel's XML files (yes, it will save spreadsheets in XML) and then wrote parsers to read the files. If you have an XML library it's literally just a few lines of code to read them or at least the parts you're likely to care about.

On one project I used them for the artists to enter animation information like

animationname, filename, startframe, endframe

On another I used to generate translation tables and images.

In both cases some compile time tool would read and parse the Excel XML file and use the data or create something that eventually turned into binary.

In my last project though, the tech team had made a network filing system so both the PS3 and 360 could see our network. Added to that they both had file change notification. So, for this project we had excel XML file parsing directly in the game and if we noticed the file changed we'd reload on the fly. Much of the AI was stored in Excel, so a designer would change some fields, save and the game would start using his changes immediately as he was testing his AI.

If you want to know how to parse Excel's XML files there's an example here.

http://greggman.com/games/excel-python-xml.htm

Note that you have to save as Excel 2003 XML because as of Office 2007 they've made the default XML format much much harder to parse. Still, once you save once if you re-open that file it will automatically keep saving to the same format.

My personal preference is I'd use XML only during development and save out some binary format for release but in the last project time didn't allow us to take that step and yet the game shipped.

kert

Try LLamaXML. its a pull parser ( not push like SAX or memory-hungry DOM )
I manage to process gigabytes of xml-format server logfiles on a winmobile-running PDA with that.
BTW, TinyXML also has completely adorable C++ interfaces, for instance "ticpp"

Amit Patel

For me the main difference between XML and JSON is that XML has roots in *markup* languages: you have a document with text and you want to annotate that text with things like “this is a header” or “make this bold”. JSON on the other hand came from *data structures*. You can see this when you compare the fundamental structures: XML gives you an element, which has both an unordered set of attributes, and an ordered list of children, and then there are text nodes too; JSON gives you arrays, maps, numbers, strings, booleans.

Yes, XML has more support and that's a good reason to use it, but for data serialization, JSON “fits” better because it matches the data structures used in most programming languages.

BQ

* Leightweight XML parser:
http://rapidxml.sourceforge.net/

* XML alternatives:
http://stackoverflow.com/questions/44207/what-are-good-alternative-data-formats-to-xml

Tom

The coolest XML technology is probably
vtd-xml

http://vtd-xml.sf.net

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Working...
Your comment could not be posted. Error type:
Your comment has been posted. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.

Working...

Post a comment

Your Information

(Name is required. Email address will not be displayed with the comment.)

Jamie's Bragging Rights

  • Spider-Man 2
    The best superhero games of all time Game Informer
    Top five games of all time Yahtzee Croshaw
    Top five superhero games of all time MSNBC
    Top 100 PS2 games of all time Official Playstation 2 Magazine
    1001 Games You Must Play Before You Die Nomination for Excellence in Gameplay Engineering Academy of Interactive Arts & Sciences
  • Schizoid
    Penny Arcade PAX 10 Award
    Nominated for XBLA Best Original Game
    Nominated for XBLA Best Co-Op Game