Blogs - Bonser

So after a long while fighting with templates I have finally got a decent implementation of the ECS. I now have Systems, Components and Component Pools.

There is a Component Pool for each component and that holds every single component of that type.

Each System keeps track of each of the entities that is registered for it and then on update the system loops through all the entities getting the components that it needs for that entity and performing the actions on it.

This new way of doing things, having systems work on their own will give me the opportunity to add thread pools once that is necessary. This will allow me to use worker threads for sections of entities registered for the system.

So that is the general usage of the Systems and Components. The next part I will talk about is messaging, this has been a very tricky part of the Entity System.

I have again used CRTP to accomplish this, and I believe allowing a system to register for messages is easier than ever now.

The Messaging system is technically something completely seperate from the Entity System/Component architecture and because of this it is not just Systems that can listen for messages.

Okay so how does it work?

So the Message class is where the CRTP occurs, each derived message type will supply itself as the template parameter for the base class:

class DerivedMessage : public Message<DerivedMessage>
{
public: 
   DerivedMessage(); 
   virtual ~DerivedMessage(){};
};

This allows for much easier dispatch of the messages now to show how to make a class receive messages:

first of all you have to derive the class that will listen to the messages from the MessageListener class supplying the message you will be using:

template < class MessageType > 
class MessageListener 
{
public:
   virtual void HandleMessage(MessageType* message) = 0;
};

class MovementSystem : public System<MovementSystem>, 
                       public MessageListener<MovementMessage>, 
                       public MessageListener<RotationMessage> 
{
public:
   MovementSystem(MessageManager* msgManager);
   virtual void Update(); 
   virtual ~MovementSystem(void);
   void HandleMessage(MovementMessage*message); 
   void HandleMessage(RotationMessage* message); 
   virtual void RegisterMessages(); 
};

The next step is merely to register to receive the messages of a certain type in the RegisterMessages function. This is called just after creation of any System.

void MovementSystem::RegisterMessages() 
{
   mMessageManager->RegisterListener<MovementMessage>(this);
   mMessageManager->RegisterListener<RotationMessage>(this);
}

and then of course all that is left is to handle the messages with each of the HandleMessage functions.

Finally this is a little demo program that shows the use of the ECS and messaging:

int _tmain(int argc, _TCHAR* argv[]) 
{
   MessageManager messManager; 
   EntityManager manager(&messManager);
   Entity* newEnt = manager.CreateEntity( string( "MyFirstEntity" ) );
   newEnt->AddComponent<PositionComponent>( newEnt ); 
   newEnt->AddComponent<VelocityComponent>( newEnt ); 
   newEnt->AddSystem<MovementSystem>(); 
   messManager.SendMessage<MovementMessage>( 40.0f, 0.2f, 0.0f );
   messManager.SendMessage<RotationdMessage>( 20.0f, 0.0f, 0.0f ); 
   return 0;
}

I have used variadic templates throughout to make creating Messages and Components really simple.

So I believe this is a fairly flexible approach, there are probably a few more things that I could do to make this better but for now I am going to leave it as it is and try and re-implement all the functionality that is in my previous version of the ECS. Once this is all integrated back into my Engine then I will run some tests and see if there is need for any more changes.

All is going well after a lot of frustrating times with templates. There are still some things that need tidying up to ensure the system is a little more robust but I am very happy with the progress.

Thanks

Exporting...

On Thursday I managed to get the Export of the Levels to work. This involves exporting the Assets ( Meshes, Textures, Sounds ) and the Entities( Components, Data Components ). After doing this the only thing I had left to do is allow editing of the rotation of the entities, which posed a problem. Up until now I had been directly editing the Matrix of the Mesh Instance I had selected. This was fine except to do rotation I would need to store the Euler Angles that could be edited from the User Interface.
This got me thinking, I should be using the Entity Component System(ECS) for all of this data realistically, and I will also be wanting to edit values of the Data Components from within the Level Editor as this will make entity creation much better. In my current system for ECS there isn't any way of getting a Data Component for an Entity without doing a dynamic cast based on some sort of ID which could potentially go wrong. So I started looking at different solutions for ECS since my first initial implementation. I came across this post: ECS, Component, Entities and Systems, which suggests the use of the Curiously Recurring Template Pattern(CRTP) for the ECS.

First Attempt
Most of Thursday night was spent refactoring my current ECS from a virtual inheritance style hierarchy to this CRTP version. Needless to say after a lot of Linking Errors and all sorts of crazy going on I decided to scrap it and revert my changes.

auto posComponent = entity->GetComponent();

entity->AddComponent( x, y, z );

Work is progressing massively each day at the moment. I have just implemented the Entity creation code and added the extra functionality to the GUI.

The rate at which I am creating the GUI is increasing rapidly as I'm getting better with JQuery and also I have now implemented a reload feature so I can just tweak the JavaScript and then reload the GUI without having to stop and start the program.

Anyway enough chit chat here is a demo of the entity creation in action:

So I have managed to get a couple of things off my check list from the last post off already which is great I now just need to add

The rotation and scale support and then hook in the export code again and I will have a fully usable Level Editor.

On target to get this nailed by the end of this week and it's about time :)

I have just been implementing the two different GUI's for the Level Editor and the game project. Currently they aren't that impressive, although the Level Editor GUI does let you alter Entities positions in the scene which is great.
The Game's GUI is just a simple box that lets you choose whether you want to start a Client or Server Game so it does pretty much exactly what the old GUI did ( Except it looks a lot more shiny :) ).

Anyway enough talking here is a quick video of the two GUI's in use:

Things are really starting to come along and my aim for this week is to have a bare bones Level Editor up and running. This seems like quite a lot from what is already there but the only things I need to implement are:

• Rotation and Scale applied to models ( Will need to store Euler Angles )
• Add GUI functionality for displaying all loaded meshes
• Add GUI functionality for adding one of the meshes to the scene ( Might just spawn at 0,0,0 )
• Make the assets export on one of the File Menu drop down buttons

I would say the largest chunk of work is going to be the parts with the GUI, particularly as I'm still new at using JavaScript but I should be able to throw something together pretty quickly.

It is all very exciting, as an added note I have decided I am going to go with the .md3 .md4 .md5 model files for import into my engine. There seems to be pretty solid exporters out there for blender and it is the most stable file format that works with my engine, specifically the animations.

I should also mention I have used models from another project as placeholders for now, here is a link to the sourceforge project: Mundo Game

Anyway until next time,
Cheers :)

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

Keep coding.

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. Input Refactoring
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.Awesomium Integration
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.

Awesomium

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

Artwork

Updating the Assimp Library