So I've just listened to the Talk Python Podcast for digging into visual studio code and been really thinking about how useful this could be to me from day to day. I already use vs code for all my python and robot framework development I do at work and home so it's already part of my workflow. 

So the workflow for development at work is this:

1. Develop on code locally using Eclipse
2. Push changes to the build server.
3. build on the build server.
4. pull down any compiled files to local machine if required.
5. package up the code on the build server.
6. push the package to a piece of hardware for testing.

This whole process could be much simplified with points 2) and 4) if I could simply develop on the build server using the vs code remote development tools. Not only 2) and 4) would be much improved but since you can actually use the terminal built into vscode to operate on the filesystem of the remote machine then I could also run the make commands for doing the whole build and packaging process as well.

This seems ridiculously powerful!

On my home machine I have a separate installation of Linux Mint for doing all my python development on, this is for a couple of reasons:

1. I prefer developing python on Unix based systems as I have full access to the bash shell and installing python and working with packages is much simpler there.
2. Not many video games have installs for Linux so it keeps me productive :)

Well this won't help with number 2 but It will certainly help with number 1.

So Windows Subsystem for Linux seemed really good apart from you can't use any Editors with the WSL files... until now!

I would no longer have to work in vi/vim if I wanted to do any python development in WSL, instead I can use the remote development tools of vscode to have the same workflow as I would on a unix based machine. This would make using WSL on windows a possibility for me and save me some much needed space on my SSD as I will only need one OS :)

So the past few days I've been working with CMake to try and get my some of the JBEngine Libraries running for Linux. The first thing I did was use vcxproj2cmake tool to generate the CMakeLists.txt from my already created Visual Studio Project Files. To start with I concentrated on the Maths and Sound Libraries as they were the easiest to do. Maths Libraries only requires some third party includes of glm and the Sound Library only has one library dependency on FMOD. 

To get the tool working I ended up having to copy all it's files into the same directory as the project file. It just didn't seem to work with a path. Secondly I then had to manually change all the paths that I had entered (or Visual Studio had generated) for the include and library directories in the Visual Studio Projects. Microsoft tends to default to using "\" for directories where as Unix system use "/". Once I had done this It finally generated a CMakeLists.txt for me, but this was only the beginning!

Being the naive developer that I was a few years ago I had scattered through my source code the use of the "\" for directories instead of "/". This was one of the first things I had to address. It was mostly the includes in the files so it wasn't too hard to track down. This wasn't too time consuming for the Maths and Sound libraries as there are no more that 5 files in each. Doing this for the whole JBEngine Source may be a little more tedious.

The next problem I encountered was resolved by this Stack Overflow post: Why does MSVC Let me do this. I was essentially passing an anonymous object to a function. It was a little confusing to track down as it wasn't a simple example:
​

void Union(Bounds& bound);
void Union(vec3& v);

void Bounds::Union( Bounds& bound )
{
    Union(bound.GetMin());
    Union(bound.GetMax());
}

What you don't see here is that Bounds.GetMin() and Bounds.GetMax() do not return a reference. This means that the returned vec3 object from the functions are newly created and therefore anonymous objects. MSVC automagically resolves this in some way but g++/gcc does not do this for you. This took me a little time to figure out as I had never even had to think about this sort of thing before.

They were the only real code issues that I faced, the rest was all about learning CMake.

So I started off with an already "complete" CMakeLists.txt which would work for Windows. Unfortunately this was never going to work out the box for Linux. Well at least it didn't for the Sound Library. First of all I had to get the Linux version of the FMOD Libs.

I had quite a bit of trouble getting used to how CMake works, specifically with include and library paths and also using the if(UNIX) branches for OS specific target_link_libraries. I finally managed to get CMake working and now I only had to deal with the make compilation issues.

What I hadn't realised is that fmod had changed significantly since I got the library for Windows so then I had to adapt the code to use the new library. 

Once I had managed this I then created a Test application to play a sound. So it was all quite easy I just had problems with:

1. vcproj2cmake
2. code issues
3. cmake issues
4. library compatibility issues.
5. and then more code issues due to the new library.

It really was a breeze.

On a serious note it wasn't half as bad as I thought, and I've learnt much more about CMake. The next things I will need to look at are:

• Adding CMake Dependencies i.e. JBEngine Library requires all the other smaller Libraries such as Sound, Maths, Renderer etc.
• Ensuring I haven't broken anything in Visual Studio whilst messing around with the project files.
• Looking into Visual Studio Project/Solution Generation from CMake.

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. 

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.

So for my second attempt I decided to create a seperate project for my ECS and get it all set up with the templates before integrating it into the engine. I am part way through this, I've got all the Components and Data Components working I just haven't dealt with the messaging yet. I have really mixed things up, instead of storing Components within the entity I have created pools of all the same types and they just have reference to their entity. This way has a few benefits such as cache coherency, 

the updates will also be Component Priority dependant rather than Entity Creation dependant. This approach will also give me better opportunity to perform multi-threading when the time comes, each pool could use worker threads to update chunks of the Components. 

One thing I am likely to change is the wording I previously used, in most descriptions of an ECS the words System and Component are used where as mine uses Component and Data Component which really confuses things as:

Component = Data Component
System = Component

For the sake of anyone wanting to use the Engine and reading up on Component Systems it seems more appropriate to use the most common terminology.

Okay so finally a demo of what access to the new Components will look like:

auto posComponent = entity->GetComponent<PositionComponent>();

also as I have used Variadic templates so the adding of Components to entities is clean and simple:

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

Okay so there is still a lot of work to be done but I'm hoping to get this all nailed pretty soon so I can really start using the ECS.

Cheers :)

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 
:)

Okay so I really haven't managed to get much done in terms of coding but I have learnt quite a bit that will hopefully be very useful.

Okay so I started off by creating the Export part of the Level Editor which means I now have a full pipeline for level production, I can create assets, place them in the scene and then save them to an XML file. This XML file can then be either imported into the Level Editor again for further work or can be used in the game. 

I have been getting used to using 3DS Max and I have become much more efficient with it, learning to model and texture objects. I have also learnt to use the biped tools to create simple walk and jump animations. 

This is when I ran into some troubles as when I exported my model to collada I couldn't get the animations to export properly. I initially thoguht this was an issue with my engine but as I tested the animation in two other assimp featured model viewers I decided it was an issue with the file format. 

To combat this I decided to try and export the model as an .FBX which worked with the modelling programs. .FBX is only supported in the newer version of the assimp library that I didn't have at the time so it was time to update the library.

Okay so I set off downloading the newest version of the assimp library. The first time I compiled assimp it came with a setup visual studio solution so I simply had to compile the program and it would create all the files for me. 

Since then they have decided to go for a CMake alternative as it is the most cross platform approach and I'm guessing take the least work on their part. 

I had never used CMake before and was a bit worried about using it as it all seemed overly confusing. After reading up a bit on the internet about Make Files and how to use CMake I finally managed to get the assimp library to compile. 

It was actually not as difficult as it first seemed and I will will more than likely use it many times again with other libraries that I need to update. 

As a final note I still haven't got the character to display properly as there is an issue with how the bones are setup in the engine. I know this file format does work as it has worked with the model viewer so I will just need to do a little more debugging to figure out what is going on. 

I really need to get something demoable very shortly as this is making me lose motivation some what. Once I have my character model in and walking round I will feel much better. 

Cheers :)

Okay It's been a while since my last post and I have been slowly working my way through creating some of the initial GUI Elements for my Level Editor, and eventually the game. 

I have just added a checkbox class and an Editbox class that will allow the user to enter data. As a starting point these really are the only two extra elements I need. The editboxes are needed to allow the user to edit things like, Entity Name, position, scale and rotation and obviously the checkboxes are great for turning things on and off. 

Anyway enough of my ramblings, here is a short demo of some of the functionality of the Level Editor:

So the video is pretty minimal at the moment but even now this is going to make life much easier than editing values in an XML file to add objects to the scene. 

Next steps are:

• Allow the user to specify an object to place in the scene
• adjust rotation and scale as well ( fairly low hanging fruit )
• start work on the XML exporter
• Add extra GUI Elements( Dropdown list and Listbox with scroll bar )

I definitely need to get started on the XML exporter, although it shouldn't be too difficult it will be a time consuming thing to get right. I already have a specific format of how the file should look, due to having to write the importer so I want to get that nailed as soon as.

The other bits and pieces are just general improvements to the Level Editor which will be implemented over time. I really want to keep this level editor as minimal as possible so I'm having to assess each of the functionality I want to add and think about whether I really need it.

Happy with Development at the moment,
just need to keep motivation high!

Today I made my first development tool to go alongside the engine. To be honest it was more something to make my life a little easier. As the JBEngine uses an Entity Component System I found that I was having to create a lot of classes for these components which to start off with all have the same signature. This meant I was copying and pasting a component and changing the class names A LOT!

So now I have the JBEngine Component Creator (JBCC). It is just a simple WinForms application to generate a component class with a specified name and a priority value that is assigned to each class.

Okay so it is pretty basic but I thought it was worth noting, seen as it will probably be the first of many development tools that will be created alongside the JBEngine. 

I have also started work on the Entity XML Parsing so I should hopefully have this done shortly.

Happy Coding :)