This post was started about three weeks ago, which may give some indication of how limited time is at the moment. It's a bit of a hodge-podge of news.
Work has begun on the next AGS game conversion - I'm not really in a position to reveal anything other than to say that it's a super-exciting project (as well as a massively complicated challenge).
Due to its size, some frailties within both XAGE Editor and the engine itself have been exposed. I've addressed some of these accordingly: items for scripts are now selected via dropdowns & lists rather than the previous big shiny buttons, the treeview refreshes a bit more efficiently and conversions have been speeded up after ...
Converting small games is reasonably fast, though the process involves a lot of string manipulation and lookups and so takes exponentially longer the larger the game is. This was a problem for two games inparticular, taking anything between 5-10 minutes to convert - not a particularly productive length of time when testing small tweaks and changes.
I've managed to reduce this time by profiling the application. Using a profiler to identify a bottleneck is immensely satisfying. I'd gotten into the bad habit of using ToUpper() a lot when comparing strings, when there's much better performance to be had using String.Compare and ignoring case sensitivity. Other simple changes like using String Builders instead of concatenations have helped speed up the process.
Another useful outcome from profiling is identifying where garbage collection is occurring. One of the benefits of C# is not worrying too much about memory management. The xbox360 Garbage Collector isn't great however, and forces you to be mindful of what you're instatiating within each game loop. As it turns out, some rather innocuous code can be the difference between a game that runs at 2 fps and one that runs smoothly.
There are plenty of further optimisations to be made; XAGE's scripting creates more garbage than I'd like it to. When you have certain scripts with 10+ conditional statements that run 40 times per second, the garbage can quickly add up and cause stuttering. I'm also going to run a few tests using Automatic XNB serialization to improve load times on the 360 (assuming it's possible to do this using MSBuild).
Support for AGS-style custom modules has been tentatively added, albeit in a slightly clunky way (slotted into standalone rooms for now). It's not ideal but it works, and will do until I get around to implementing a more elegant solution.
Other bits and bobs have been added, some of them purely to cater for some legacy AGS design oddities (like having room co-ordinates that operate at different resolutions). I've jotted out a few designs for designs for things like Expressions & Extension Methods so they should be getting rolled out over the coming months.
Apple's T&C's for iPhone/iPod Touch firmware v4 (I do find it quite odious that they charge for firmware updates!) include the following:
Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited.
Sadly, this would appear to rule out developers ever using things like Flash-to-iPhone compilers, MonoXna and MonoTouch. Consequently, it is now looking very unlikely that XAGE will ever support the iPhone. Bah.
On a happier note, Silverlight v4 should be released in a few days so Awakener will shortly be getting an update.