Over this past week or so I have been getting used to using the Awesomium Library. I hit a performance issue fairly early on but that was soon resolved and the webpages now render very efficiently. I was pretty amazed to see how well it actually works and I definitely think this is the way that the majority of my User Interfaces will be done from now on, including HUD's. The input to the awesomium library is done as input injections, such as MouseMove, MouseButtonDown. This got me thinking a lot about how my input actually worked and I decided to refactor it a little.

As a general rule there are two approaches to handling input: Polling and Callbacks. So far in my engine I have been using polling. Whenever an object needed to check for some input it would read something like: 

if( input->GetButton( JB_ENTER_KEY ) == JB_PRESS )

This approach worked and for a long time it was sufficient, but to provide Awesomium with the information it needed I would have to call this every frame for every possible button and that was not realistic. 

I have now implemented a callback based approach which allows different objects to listen for the key presses and mouse movements it is interested in.

For example at the moment I have an "Input Context" that listens for all the keys and mouse movements and the callbacks report to Awesomium about it. 

Another Input context is used for the Level Editor movement and only listens for the WASD buttons and allows the camera to move about when it's callbacks are called.

This approach makes this much simpler and I'm hoping I won't ever have to touch the inner workings of the input again. One thing that could change is adding some input mapping so that different keys could be used for the input i.e. use Up, Down, Left and Right instead of WASD for movement. 

The integration between the JavaScript and the C++ side is seamless and didn't take too long to get up and running. Currently I have callbacks from the JavaScript into C++ but I haven't fully tested opposite approach quite yet, although it seems fairly simple. 

Anyway here is a quick demo of a User Interface I setup for the Level Editor, it doesn't actually show off any of the callbacks in this video but I will soon be showing a fully integrated version:

Okay so this all seems to work well and I'm thinking there has go to be a catch at some point but let's hope I'm wrong. It's really surprised me how little information there is on other people using Awesomium in native applications. I believe this is much better than using any other User Interface Library, even if the performance isn't quite as good as a C++ Library would be. 

I think the largest advantage is the ability to create User interfaces on any computer, currently the engine doesn't work for Mac OSX but I sat there the other day on my MacBook and bashed out this user interface. This also means that when it comes to releasing a game you already allow the users to mod the user interface in which ever way they want. All they would need to do is call the appropriate methods on the JavaScript Object for the engine. 

That is it from me today, I'm hoping to get much more work done over the next week or so to finally get this level editor user interface polished off, and also refactor the design for this Awesomium work.

This past couple of weeks I've been playing around with 3ds max a little more and working on creating animations. Using these animations I realised that my engine can't handle FBX files very well, and in fact the example Model Viewer I got couldn't either. This meant going back to the drawing board and figuring out why FBX animations weren't working. I soon narrowed it down that the use of FBX and the 
biped objects in 3DS Max were making it really difficult to import into certain pieces of software. Due to this I am not resorting back to using Collada as my main import type as it is the most standardised and it will work for animations as long as I don't use the biped. 

This has caused a lot of frustrating as now I am having to create all my bones and animations by hand, in the long run I think It might be slightly easier as the biped can't really do everything I need it to.

I found a piece of middleware called Coherent UI which allows the use of HTML webpages to display GUI's in games and other native applications. This seemed really powerful and from the look of their website appeared to do everything I wanted it to do. The only issue is that their licenses were a bit limited for what I needed it for. I realised afterwards how useful this middleware would be to me as I would then not need to create all the GUI elements for the engine and would increase productivity rapidly, so I went on the lookout for a similar library which i could use. This is when I stumbled upon Awesomium. It also allows application to take a webpage and render it to a texture, more than this you can interact fully with it using JavaScript for callbacks to C++ functions. 

I have been playing with Awesomium over the past week and have managed to get something up and running, rendering the google homepage and allowing some interaction with it. There is still plenty more to be done and it does seem that there is a large performace issue with it at the moment. I believe this is due to the texture being overwritten almost every frame and then uploaded to the graphic card again, although I am yet to profile it. 

If i can manage to get these performance issues out the way I will proceed further with it and hopefully be able to throw together a new UI for the game and also the level editor. This will give so much flexibility and also the ability for users to mod the game. they can simply create their own UI by overwriting the current webpage with whatever they would like to display. 

Plenty to be looking forward to and I will hopefully have a demo usage of the awesomium up soon. 

Thanks 
:)