James Wynn

Hikari is a library for embedding Flash widgets into an Ogre screen overlay using the Internet Explorer Flash browser plugin.  When I had first heard of this library I, like many others, had been using the somewhat antiquated CEGUI and were growing more frustrated by the day.  At the time CEGUI had lost its main developer and the view among the Ogre community was that the project was dying and in need of replacement.  Hikari is not the only, or even the first, to try to fill the void left by the then dying (but now reestablished) default GUI library package, but it is the only choice providing industry supported tools.

That said, I have had some sizeable stumbling blocks with Hikari.  Many of these problems are merely results of fundamental incompatibilities with the Spark Engine.  Hikari's implementation creates an Ogre material and performs buffer blits between the Flash COM buffer and the Ogre material.  This is all well and good, if it is done syncronously with Spark's render thread, which it is not.  So it seems Hikari will have to be altered to work within Spark's rendering paradigm.

Overall I would give Hikari a 3.5/5 with a much higher possibility.  One of its major caveats is that it uses the Internet Explorer browser plugin interface as opposed to something more portable like the NPAPI which would allow it to be cross-platform, though I hear this is something the developer is working on.

Most of my free time as of late has been spent on a little side project I'm tentatively calling the 'Spark Engine.' One of the primary performance caveats of the technology I've written in the past was the limitation of being a single threaded application. While this in and of it's self is not a problem and in many ways simplifies development, it also forces the application to strongly control how much is done each frame to maintain a reasonable framerate. To solve this issue I placed the renderer in it's own thread and further reduced possible points of conention by only communicating through asyncronous command objects. While none of this is anything new to anyone who is up on game development technology, it is still a step forward from the previous technology I've been using.

Prior to this project I had been using tolua++ to bind my scripting language of choice to the API, but I've found that luabind is in many ways far superior. With it, unlike before, objects in scripts can inherit and implement base classes defined in C++, including event listeners, timers, and game object components. After realizing the power of this functionality I have not looked back. Another great benefit is the ability to define bindings in C++ without mangling the header files with unsightly tolua declarations. Although this apriach is not without it's downsides; luabind relies on boost which adds extra dependencies and the vast amount of templates increase compile time. But, these seem like reasonable trade-offs considering the gain.

So after not updating my blog for several months, it was apparently hacked by some spammer and its userbase had become inundated with spam bots. This embarrassment has spurred me to give the site a much needed upgrade to WordPress 2.7. Its amazing to think that I had been running 2.0 for this long.

It seems that due to my infrequency of updates my rankings on google have also fallen to the end of the first page, whereas before I had been the #1 link for my name. Perhaps I should start posting more regularly.

Not that its news, but XNA along with a membership to the XNA Creators Club allows developers to create games in a unified system for both Windows and XBox 360. Although XNA uses C#, which I personally had reservations against, it is actually quite easy to develop on and even fun to use. XNA has now abated these reservations about C# and has persuaded me to try to port my project to the 360.

With sound, networking, a solid widely used gamepad interface, and excellent graphics capabilities the XNA platform seems ideal for small games development. The only reservations still present are against the relative immaturity of the community (as opposed to Ogre's which is superb) and the lack of distribution mechanisms. The distribution problem is slated to be resolved with a rating system within the developer community, but this just comes back to the other problem.

There is, still, a significant amount of community generated content for learning and using XNA, but I worry about the platform if it does not attract a higher concentration of mature developers. We shall see.