You’d think, after spending weeks on trying to document and explain various CocoonJS parts and problems, I’d have given up completely on trying to get it working on the Ouya. And, well, if you thought that this past weekend, you would have been right. I had stopped trying to work out different things and took a break from all things CocoonJS development related.
However, the siren call was too much for me today and, taking some code I was working on last week, I went back to testing things today. This time, the case of the missing XML support!
It’s made using things like bitmapFonts in Phaser near impossible. Without converting the XML to JSON, and then re-writing the current loader function, it’s not possible to use bitmapFonts. And this is needed because, as I pointed out in another post, text support is slightly broken too.
However, after researching a couple of different approaches, I settled on porting the xmldoc Node.js library to work cleanly in browsers. A task that produced some major frustration — ALWAYS USE SEMICOLONS. THEY ARE NOT OPTIONAL! — and eventually lead to me posting a library designed exclusively to add XML support to CocoonJS.
Basically, it overwrites the normal DOMParser, or creates one if it didn’t exists before, with a constructor that wraps xmldoc and sax.js into one library. Instead of creating element nodes, it makes “XmlElement” objects that have similar functionality to XMLElements in other browsers. It’s just enough, at the moment anyway, to work in some select use cases and notably with Phaser and its own loading of XML to create bitmapFonts.
That’s where the following image came from today. After adding in tree-search recursion functions early this morning, I woke up this afternoon and started up the testing again. It took a couple of tries and some console writing, but I now have a working library to add some basic XML support to CocoonJS.