Game Developer working on my own engine framework.

Report RSS Awesomium Refactor and Input Changes

Posted by on

It's been a while since I actually got stuck in and started doing some work but I've finally managed it. After having a look over my events that I had outstanding in Asana I got a good idea about what were the next few things on the cards. I suppose that is another plus for keeping track of events and bugs, well done me.

So the main things I have been working on is the GUI integration using Awesomium. As a recap Awesomium is a library that lets you create user interfaces using Web based technology such as HTML, Javascript and CSS. The majority of this work had already been done and I had something up and running that could call methods in the Webpage and also the Webpage could callback methods in the C++. There were a lot of design issues with this as it was still in the "Let's just get it working" phase. Now that I had proven that I could get it working and that the library was efficient enough to have as a permanent feature it was time for a little refactoring.

First of all the majority of all the code was dumped in one class, this was the main library object, a web view, the method callbacks and so on. Obviously this all needed changing so I set about refactoring it all into smaller classes and thinking about how I can keep the majority of the Awesomium functionality away from the user.

At the moment I have:

  • JBWebCore
  • JBMethodHandler
  • LevelEditorMethodHandler
  • JBWebView

This is as far as I have gone at the moment as I am trying not to over engineer it too much, there are still quite a bit of the Awesomium code in these classes but for now it will have to do. The LevelEditorMethodHandler is a child class of the JBMethodHandler and allows you to overwrite the BindMethods function so you can add your own callback methods that you can call from the Javascript in a WebView.

Input Changes
After the refactoring of the Awesomium class code I went about figuring out the problem of the mouse clicks being registered for both the GUI layer and the Game Scene. To overcome this I used a GUIActive/Inactive member which was checked to decide whether a click should be passed onto the game scene.

This GUIActive/Inactive member was changed by adding a callback into the C++ from the Javascipt in the Webpage. I used the JQuery mouseover/mouseout methods to trigger these callbacks, this meant whenever the mouse hovered over one of my elements in the webpage then the click's after this would only be sent to the Webpage and not to the Game Scene.

This seems like a fairly decent way for doing this at the moment, although there may come a time when I will want to have a User Input stack. As I currently only have the GUI and the Game scene that needs input I don't feel It would be beneficial to start engineering something more complex.

What's Next?
I did manage to get quite a bit done last night and I am more motivated to get back to it again now. Next on the cards is unfortunately a little bit more refactoring before I can move on. All this Awesomium stuff needs seperating out into it's own library. The only classes that will be exposed to the User will be an interface into the JBWebView class so that the user can keep a reference to it and Bind different method handlers to different webviews, and the JBMethodHandler. The JBMethod Handler will be used merely to allow users to derive their own method handler classes for binding their own method callbacks.

Plenty to do but I know as soon as I have all this Awesomium code seperated into it's own library I will feel loads better, there's nothing better than a good old tidy up Posted Image

Keep coding.

Post a comment

Your comment will be anonymous unless you join the community. Or sign in with your social account: