Skip navigation

Category Archives: ogre3d

Okay, enough about the hurricane– let’s talk shop.

Last week, I was having some problems with keyboard input and random freezes during certain interactions. A little tracing found that a global timer was being instantiated and would greedily respawn itself during a single cycle of the browser’s message loop.

Me, in my brilliance (or rather, my unwillingness to spawn a separate thread), decided to kill the global timer every time we cycled through the message loop. This solved all of the hangs but it still didn’t fix keyboard input and caused some secondary problems (like utter failure of all Javascript timers).

It was then I realized that I couldn’t implement this thing correctly without dipping my toes into the deep, dark depths of multi-threaded programming. I needed to encapsulate the core and components of Awesomium within a separate thread, run a dedicated message loop within said thread, and handle inter-thread communication and synchronization.

It took me five days of banzai, headache-inducing coding to implement but I’m proud to declare that Awesomium is multi-threaded (and stable!). It was one of the most complex tasks I’ve ever achieved as a programmer but it’s so cool seeing both of my laptop’s cores work at the same time.

Despite the multi-threading, I still wasn’t able to get keyboard input working. I finally went code diving (about 2 hours of tracing) and realized that the problem was linked with some assertions about the unicode text encoding: as I had suspected earlier, ICU wasn’t being initialized correctly. Upon inspection of the ICU initialization source, it had seemed to be attempting to load a DLL that it had assumed would be in the working directory. I located the ICU DLL, copied it to my working directory and voila– keyboard input worked and the runtime text encoding assertions disappeared. Unfortunately, this means that my previous statement about the total dependency size was incorrect: the ICU DLL is about 8 MB and the Awesomium DLL (release) is about 7 MB, so together, that’s a total dependency size of about 15 MB. It’s not too bad I suppose– people who need the absolute tiniest dependency size can always gzip the DLL’s and load them at runtime.

But hooray! Almost everything critical now works and is pretty stable. Popup-widgets (such as drop-down combo-boxes) are now supported by compositing them with the main web-view texture. Event listeners are also implemented– you can currently receive notifications for the beginnings of navigations, title receptions, and finishing of loads. Dirty-rectangle optimization and querying for ‘dirty’ render state is implemented. The only other ‘big’ point left on my to-do list is support for Javascript evaluation/callbacks. Getting that working seems to be a little more tricky than I thought and so I may put it off for later.

Oh and yes, in true ninja style, I’ve written this latest post using Awesomium.

I pulled another late-night coding session and am happy to report that a majority of the functionality is finished:

  • Mouse input injection
  • Rendering to an arbitrary BGRA buffer
  • Callbacks for load events
  • Invalidation detection
  • Ability to load from URLs, local files, or HTML strings

After spending the past 10 hours testing Awesomium out within an Ogre3D context, I’m now even more confident that WebKit certainly trounces Mozilla Gecko in such a setting. For comparison:

Gecko:

  • Total size added to application: ~15 MB
  • Startup time: ~2 seconds

WebKit-Chromium-Awesomium:

  • Total size added to application: ~6.8 MB
  • Startup time: non-discernible, practically instant

Furthermore, the API is absolutely excellent (there’s so much great stuff, I don’t know what to expose!), it seems easier to port to other platforms, builds in much less time (by about an order of magnitude), and it just feels faster. I have yet to do any true performance benchmarks but I think I can predict the winner.

Anyways, I’ve still got some other things left that I want to finish up before the initial alpha release:

  • Keyboard input injection
  • Efficient rendering of invalidated areas (dirty-rectangling)
  • Javascript evaluation/binding

I’m shooting to get some code up in an SVN within the next two days, so stay tuned!

W00t, first post!

This blog is a place for me to rant, carry on, and generally talk about various things that amuse me.

Speakin’ of cool stuff, I’ve been hacking away at one of my older projects these past two days. It’s called “Player” (hah, I fail at creativity) and it’s basically an attempt to make a 3D online “world” demo. Nothing too ambitious, just the client/server basics– essentially a 3D chat room.

Anyways, I’m pretty much done with the major implementation: a user can login with a unique username, run around the terrain, and speak with other players. I neglected to implement 3d navigation (server-side, the world is just a 2D grid), pathfinding, fighting, leveling up, and all the other accoutrements for the sake of this being a demo but I’m still pretty happy with the result.

Technology used:

  • 3D Engine: Ogre3D
  • GUI: Hikari (my own Flash embedding layer)
  • Text Overlays: Canvas (my own super-efficient 2D rendering layer)
  • Networking: RakNet
  • Input: OIS

I recently replaced BetaGUI with Hikari because it seemed like a fun idea. It worked out pretty well methinks– I learned a new technology (Flash), squashed some bugs, and gave the demo a little style. It’s nothing compared to what Eeenmachine has put together for ZeroGear, but it’s something nonetheless.

Also, I felt like using Canvas– my super-fast 2D rendering layer for Ogre3D– for something and decided to use it to render the player titles/messages. I devised a little system that automatically updates the screen-space position of a title based on the position of its Ogre::MovableObject (in this case, the ninja-actors). The titles are totally anti-aliased/hinted/shadowed and scale through multiple font-sizes based on the distance the object is from the camera. As for performance, it’s excellent: the glyphs are pre-rendered at runtime, packed into a texture atlas, and the geometry (each glyph quad) is pooled.

I know there’s a bunch of users who are eager to start a MMO but have no idea where to start and so ultimately, I’m gonna clean up the code and release “Player” as an example project for the Ogre3D community. I’m also considering writing a series of tutorials on getting started with Ogre3D from scratch (without the Example framework or any other crutch). Hopefully my efforts will give someone a poke in the right direction.