James Wynn

Spurred by an article a while back in Game Developer Magazine, I decided to write a little cross platform library for detecting changes in files. The library works in both Windows and Linux (tested in ubuntu 8.10, but should work in anything with inotify) with support soon coming to OSX. The library is great for automatically updating game resources during development. Most real game engines have this these days, and now everyone else can too!

The library comes with two samples. OgreDemo.cpp shows a simple example of reloading textures on the fly using the Ogre3D engine. SimpleDemo.cpp just watches a directory and outputs the file names when a file changes.

Some example code:

// Create the object
FW::FileWatcher* fileWatcher = new FW::FileWatcher();
 
// add a directory watch
FW::WatchID watchid = fileWatcher->addWatch("..\\media", new UpdateListener());
 
...
 
// somewhere in your update loop call update
fileWatcher->update();
 
// where UpdateListener is defined as such
class UpdateListener : public FW::FileWatchListener
{
public:
    UpdateListener() {}
    void handleFileAction(FW::WatchID watchid, const String& dir,
                                    const String& filename,
                                    FW::FileWatcher::Action action)
    {
        std::cout << "File (" << dir + \\ + filename << ") has event "
                        << action << std::endl;
    }
};

Download version 2009.02.17

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.

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.