This has worked pretty well for me, esspecially in the land of gameplay programming where things change fast, I attempt to have an assert for every assumption my code makes even if ‘there’s no way that could fail’ because the code will change, and then it will fail and an assert will help you to track it down (I also always assert in switch ‘default’ statemnets, when it’s not a valid option, since enums change and it can also help track down memory errors, if you happen to mangle somthing that passes through a switch statement).

Basically, I love assert, so I read with interest this AltDevBlogADay article on making asserts even more useful. The basic premise is that, through large amounts of macro pre-processor vodoo, you end up with an assert that you can follow up with a comma seperated list of variables, and have the name and value of that variable printed along with the assert. So instead of doing this:

Assert(index > 0 && index < m_Size, "Index: %d is out of bounds size: %u", index, m_Size);


You can do this:

Assert(index > 0 && index < m_Size, "Index is out of bounds")(index, m_Size);


And get this:


Assert in Array.cpp, line 27: "Index is out of bounds".
- Index (int) = 5
- m_Size (u32) = 2


Which saves some typing, but it also does so very much more. The first extra thing this new assert does that I love is that it forces you to put the extra brackets after the assert statement, they can be empty (if they really need to be) but they have to be there, which encourages the use of lobbing every variable that might be some help in there. Secondly, it calls code you wrote to output the value of the variable, meaning it supports custon types (through the use of a bodyless template function that you can specialise to take care of your types). So if I add a Vector3 to that list, it prints out the X, Y and Z components in a nice way without me hafing to type “X: %f Y: %f Z: %f” all the time and then cursing when that Vector3 is now a Vector4 and I could have really done with printing out the W bit.

It took a while to convert all the asserts in my engine code to use this new version (because we all love the errors caused when a marco evaluates to something different than it used to…) but I’m really happy I took the time. I also modified the code in the article to include the functionality that existed already to have different code take-over the reporting of the assert. For example in editor builds an assert will show a dialog box with the information, where as in game code the assert is either output to the debugger/console window or dumped to the log file (if no debugger is attached).

Fixing the issue with dragging and dropping items from the scene graph TreeCtrl turned out to be a one-line fix, I forgot that the tree control items own the data you associate with them, and it was being deleted as part of the drag/drop action, and then causing a crash (well, hitting an assert actually) when that item was then selected (as that data was expected to be there).

So with those tasks sorted, I moved on to the next big job: Making it so that you can select multiple nodes and then transform them with the mouse, this was a bit of a pain and is still not entirely complete (currently the properties PropGrid only shows if you have exactly one node selected, in future it will show all common properties shared between all selected nodes, and allow you to change them for all selected nodes at once), but as a task it wasn’t particularly difficult, just a case of going through the code and sorting out each of the places that assumed there was only ever one selected node (not that many, as it turned out).

Then I added a ‘selection marker’, this is a cross that follows the selected node or nodes (assuming the average position in the case of more that one node being selected) and has a (small) hit-area, you click can click and drag that to translate, rotate and scale the selected node(s), thus allowing the click-and-drag transforms to work on nodes that have a size of 0, which previously didn’t work.

Finally I added some extra buttons to the editor to expose some align functions, these allow the user to select a group of nodes and align them to the left, center, right, top, middle or bottom, which uses the nodes personal bounding boxes (as in, the bounding box that encompasses that node only, excluding it’s children) to align the nodes, for example if you select a bunch of nodes and click ‘align-left’ then the nodes will be arranged so that the minimum extent on the x-axis of their personal bounding boxes will all equal that of the left-most node, quite a useful operation.

So then, next week I want to make sure that loading and saving scenes works as intended, and I might move on to attempting to build-up a more complex, realistic scene… I’ve been putting some thought into the game I might make to test features of the engine as I go along, nothing has really solidified yet but I have some interesting (at-least for me) ideas. I also want to make sure it compiles on Linux but progress on that front may be slightly slower (I have to be in a particular mood to comb through GCC compile errors…)

It’s gotten to the stage where the editor could do with drawing some stuff, stuff like markers to show the position/size of the currently selected node, and this raises an interesting problem. It would also be good for game-nodes to be able to draw debug graphics, from anywhere in their update loop (or functions called from that).

So, I have need of a way to store rendering commands for later use, my idea was to have some form of buffer that is cleared every frame, and methods to add common shapes to that buffer (rectangles, circles, etc.). Due to the way that scenes work in Tyr (there can be more than one scene active at the same time) I need a buffer per-scene, and a global buffer, for things like the editor who will want to draw out-side of a nodes update loop.

Now, the simplest method of drawing shapes with OpenGL is with the glBegin and glEnd methods, basically, you call glBegin, passing it a mode (To draw lines, quads, triangles, etc.) and then repeatedly call glVertex, glTexCoord, glColour, describing the geometry you’d like to draw. So I decided to create a class that holds to std::vectors, the fist one is a list of commands (to be passed to glBegin) and an index into the second buffer, the second buffer will hold only floats, used to express the colour and vertex positions of the items I wish to draw. I made the decision that any primitive drawn by this debug-drawing code will have all vertecies drawn in the same colour, to save on the amount of information I’m saving (and to stress that this is for debug-only drawing, since it will be rather slow).

Primitives are added to this buffer by calling one of several methods (DrawRect, DrawCircle, etc.) all of which take a RGBA colour, and the relevant per-primitive information, this calls internal methods to add commands to the command list and float to the float list, this is all done so that the drawing code can be as simple as possible.

void Renderer::Render( DebugBuffer* pBuffer )
{
	glDisable(GL_TEXTURE_2D);
	glDisable(GL_DEPTH_TEST);
	glBindTexture(GL_TEXTURE_2D, 0);
	g_ShaderManager.Bind(INVALID_SHADER);

	size_t commandIndex = 0;
	size_t floatIndex = 0;

	while(floatIndex < pBuffer->m_FloatList.size())
	{
		GLuint startIndex = pBuffer->m_CommandList[commandIndex++];
		TYR_ASSERT_MSG(floatIndex == startIndex, "Start index does not match current float index");
		GLuint command = pBuffer->m_CommandList[commandIndex++];

		// Grab the colours
		GLfloat red	= pBuffer->m_FloatList[floatIndex++];
		GLfloat green	= pBuffer->m_FloatList[floatIndex++];
		GLfloat blue	= pBuffer->m_FloatList[floatIndex++];
		GLfloat alpha	= pBuffer->m_FloatList[floatIndex++];

		// We should end before the next set
		GLuint nextStartIndex = commandIndex < pBuffer->m_CommandList.size() ?
								pBuffer->m_CommandList[commandIndex] :
								pBuffer->m_FloatList.size();

		// Draw it
		glBegin(command);
		for(;floatIndex < nextStartIndex;)
		{
			float x = pBuffer->m_FloatList[floatIndex++];
			float y = pBuffer->m_FloatList[floatIndex++];
			float z = pBuffer->m_FloatList[floatIndex++];

			glColor4f(red, green, blue, alpha);
			glVertex3f(x, y, z);
		}
		glEnd();
	}
}

This is the code that renders a DebugBuffer, it simply loops through the commands, grabbing the needed floats from the float buffer that are then used to render the primitive. Each command knows the index of the first float that it needs to access (the red value for the colour) and by looking ahead to the next command, we can get the total number of floats that command uses.

The system as it stands seems to work quite well, as I mentioned earlier, each scene has it’s own debug buffer and there is a global one too, the rendering order is scene (and child nodes), the scene’s DebugBuffer and finally the global DebugBuffer, so that the debug information is always available (I may have to alter this when I add support for post-process effects, as those will want to be applied before the debug rendering. I also need to extent this method to allow the rendering of text, but I’m not entirely sure how to go about doing that one yet. This system is rather new (it was implemented mostly on Saturday night) so it may change over time when it is used more extensively.

Now there is a set order, logically that these managers should themselves be created, granted for some of them it doesn’t matter (should the texture manager be created before the shader manager?), whilst for others, it is pretty easy (the Logger, responsible for logging warnings and errors, should probably be first) and if there is an order they should be constructed, they should be destructed in reverse order, otherwise nasty things may occur.

So, I set about trying to come up with a nice way to make such an arrangement happen, this post will document my journey.

First things first, we have some common behaviour, all the managers should have a priority, and throw in Init and Shutdown methods for good measure (these will be called based on the priority) so for that we need a BaseManager (which I was very tempted to call ManagerManager), the base manager doesn’t do much at the moment:

class BaseManager : public NonCopyable
{
public:
	//! Constructor
	BaseManager(
		u8 priority		//!< Priority of the manager (lower is higher)
		);

	//! Destructor
	virtual ~BaseManager();

	//! Initialise (called in order of priority)
	//! \return True on success
	virtual bool Init() = 0;

	//! Shut-down
	//! \return True on success
	virtual bool Shutdown() = 0;

	//! Get the priority of the manager
	//! \return The priority
	u8 GetPriority() const;

private:
	u8 m_Priority;		//!< Priority of this manager, lower higher in list
};

The main point of node is the priority member variable, which is a u8, allowing 255 managers (should be enough for anyone, right?), now the comment for this member talks about a list, and we'll get to that in a moment, but allow be to indulge into a brief tangent on static initialisation in C++.

Lots of people would implement these managers using the Singleton design pattern, indeed it used to be my weapon of choice for such tasks, and it has a lot of merits, especially when you get to the more advanced versions which allow you to control when they are constructed and deleted, however, I grew tired of singletons for a variety of reasons, for one they give you a false feeling of safety (even though it is pretty easy to maliciously, or accidentally create more than one) they can have issues being used in .dlls, and also, typing out Singleton::Instance() (or your equivalent) is a tad verbose and does get tiring after a while.

So now I use global variables straight-up, rather than attempting to hide behind a design pattern to make them go away, global variables are of-course bad, as are macros, and both will be used judiciously here, generally, all the 'bad' things that you 'should never use' end up being useful after a while, you just have to know the risks and decide they're worth it.

So, back to static initialisation (forgive my tangent from my tangent). See all my managers are declared by an extern, something like:

extern TextureManager g_TextureManager;

This is nice and simple but it does mean that the manager object is constructed during static initialisation and thus I have no say in whether this manager is constructed before that manager, which is slightly ok, after-all we made that Init() method so that we could initialise the managers in a different order to the one they were constructed in. The problem, as it turns out, lies with the fact that we have to store references to these managers in a list, and is we want to register managers in their constructor (which we do otherwise we will have to manually update a list of managers and that just sounds horrendous) we need to make sure that the list of managers is constructed before any of the managers themselves.

Lucky for all, all is not undefined in the land of static initialisation, static local variables, declared in a function, will be initialised the first time that function is called. So, to solve our manager-list issue we merely need to define a member function on the BaseManager like so:

ManagerList& BaseManager::GetManagerList()
{
	static ManagerList managerList;
	return managerList;
}

Then, in the constructor of the BaseManager add:

GetManagerList().push_back(this);

This will make sure that our list of managers is constructed before we attempt to add a manager to it (which is nice, I'm sure you'd agree). So, we have our list, we have our managers that register with said list, sorting the list is a trivial issue, as is calling the Init/Shutdown functions in correct orders, so now we turn our attention to how best to define the priority and thus the order of these managers.

Now, you can just manually define them, that would be ok, for a while, but when you have more than a few managers the relationships get pretty complex and going back and changing numbers is very tedious, no, what we need is a list, a list with the names of the managers in a human readable format, and their position in that list to be their priority. What we need, is an enum.

When this idea hit me I immediately liked the cleanness of it, just define an enum, perhaps in one of the higher-up components of the engine (in the Engine.lib, actually) and all is well, you can re-order the entries in the enum, and all the priority values will change and there will be no errors due to forgetting that one manager. There are, however, two main issues in this technique. Firstly, by making the priority of the manager be defined else-where, we are making that library implicitly rely on another library, which I want to attempt to avoid, however, by marking the priorities as 'extern' I am merely stating that something, somewhere has to define a value for that, if they want to use this library, I personally don't think that is too bad. Secondly, if I am defining this list in a high-level library (and I am) there is a very high-chance that I will create a circular dependency (Engile lib defines the priorities, Engine lib relies on RenderLib to do rendering, RenderLib relies on the priorities defined in EngineLib) however, both Visual Studio and GCC can deal with this (you just have to tell GCC to deal with it using --start-group and --end-group) so that isn't too bad either.

Now all that is left is to make the process of defining these managers and the priority list easier and less prone to errors, and for that, I chose to break-out the macros.

In the BaseManager header, I define 3 macros:

#define TYR_GET_MANAGER_PRIORITY_VAR(name)		name##_Priority
#define TYR_DEFINE_MANAGER_PRIORITY_VAR(name)	extern	u8 TYR_GET_MANAGER_PRIORITY_VAR(name);
#define TYR_MANAGER_CTOR(name) \
	TYR_DEFINE_MANAGER_PRIORITY_VAR(name) \
	name::name() \
		: BaseManager(TYR_GET_MANAGER_PRIORITY_VAR(name))

The first one, simply makes it convenient to get the name of the variable correct everywhere it's used, the second one declares an external variable that is used as the priority, and the final one uses the first two to describe the constructor of a new manager class, which will have the priority assigned to the variable _Priority. Only the final macro is used directly, like so:

TYR_MANAGER_CTOR(TextureManager)
{

}

Which expands to:

extern u8 TextureManager_Priority;
TextureManager::TextureManager()
    : BaseManager(TextureManager_Priority)
{

}

Now, in EngineLib, I have a file called ManagerConfig.cpp (it has a corresponding header, but it is empty), which contains the following:

#define TYR_DECLARE_MANAGER_PRIORITY_VAR(name)\
	u8 TYR_GET_MANAGER_PRIORITY_VAR(name) = ManagerPriorityList::name;

namespace ManagerPriorityList
{
	enum
	{
		Logger,
		TextureManager,
		ShaderManager,
		SceneManager,
	};
};

TYR_DECLARE_MANAGER_PRIORITY_VAR(Logger);
TYR_DECLARE_MANAGER_PRIORITY_VAR(SceneManager);
TYR_DECLARE_MANAGER_PRIORITY_VAR(TextureManager);
TYR_DECLARE_MANAGER_PRIORITY_VAR(ShaderManager);

Another macro, this one defines the values in the format expected by the previously declared extern, this macro assigns the value from a named value in the enum below, and at the very bottom, the list of managers defined using the macro. Note that the order of the managers at the bottom doesn't matter, so I only have to change the order of the enum if I want to change the order of the managers.

I am still slightly annoyed that I have to write the manager name twice in this file, I'm tempted to switch the enum out for some form of static variable that is incremented as part of the macro, but I'm not sure if that would work and it's good enough for now. I hope you enjoyed this unexpected mid-week posting, I'll try to have something more to tell by the weekend, as expected taking a break from tool programming to dive back into the engine proper has boosted my enthusiasm for the project, so progress is picking up somewhat.

So, this week I decided to take a bit of a break from the Asset Manager, and take the time to actually implement textures properly, loading the compiled textures and sending the image data off to OpenGL turned out to be rather easy, OpenGL supports rendering DXT compressed textures via the ‘ubiquitous’ GL_COMPRESSED_RGBA_S3TC etc. extentions, these aren’t part of the official spec, but being labelled as ‘ubiquitous’ means that most hardware supports them, so I decided it was safe to use them.

I then moved on to dragging my sprite renderer slightly into the modern era by switching from ye-olde fixed-function rendering to using shaders, I created a simple sprite vertex and fragment shader (it’s about 4 lines long) that basically just replaces what the fixed-function version did (render a texture, multiplied by a colour, at positions specified by the vertices).

I’d never set-up shaders in OpenGL before, and a fair amount of the documentation I found used the ARB extentions to load and compile the shaders, howver, combining a few different websites (mainly this one) I managed to come up with a solution that works.

In the process of attempting to get shaders working, I made much use of my logger class, and have extended it so that, when asserts are enabled, it will trigger a break-point whenever it logs an ‘Error’ or ‘Fatal’ level message.

I’m having fun working on the main engine again, so I’ll likely not work on the Asset Manager this week, instead I want to attempt to make it easier to move, rotate and scale sprites around the small test scene I’m making.

This turned out to be pretty simple, I just made the ‘Source’ (location of the source asset) input the top-most on the add texture dialogue, capture the event when that changed, then attempt to load that source path as an image, to extract the width and the height, and extract the name from the file-path.

Adding support for adding multiple textures at once was slightly more tricky, I decided to swap out the ‘Source’ file-select dialogue for a list-box with ‘Add’ and ‘Delete’ buttons under it, the file-select dialogue now shows when the user clicks the ‘Add’ button and allows them to select multiple files, the code then processes each file-path the user selected, for each file, pre-populating the width, height, name and parent folder, and storing those results in a std::vector of structs. If the file cannot be opened, or is not a valid image, an error dialogue is shown to the user but the adding process continues.

The user is then able to select individual files and make any changes they desire, when the user clicks the ‘Ok’ button, each entry in the std::vector is validated (making sure the width, height, parent folder etc. are valid), if an invalid entry is found, an error dialogue is shown, and that item is selected in the list, allowing the user to quickly amend the error.

Once this was all up and working, it was time to test it with a large amount of data, luckily, I had a folder full of sprites (700+) to test with (the sprites in question are the ‘Last Guardian’ sprites available here under a Creative Commons licence), so I selected all 700-odd sprites and clicked ok to add them to the database, Asset Manager froze for a couple of minuets, just as I was about to start to attempt debugging the presumed infinite loop, it resumed responding.

So, the code worked, although it was woefully slow, I suspected the issue was with the database (as there really wasn’t much of my code being executed), and sure enough, a look at the SQLite FAQ explained the problem (that by default each INSERT query created and then committed a transaction) and the solution (manually start a transaction before INSERTing the records, and COMMIT it when all the records are added), I added a few transaction-related functions to the database wrapper and implemented this solution, when I re-ran the test, re-adding the sprites (after having manually cleared the database, there is still no way to remove items currently…) the operation completed instantly.

Adding the Last Guardian sprites to Asset Manager

In the coming week I need to work on completing the basic functionality for Asset Manager, allowing the removal of textures and folders, and allowing items to be moved by dragging them around the tree-control, once this is done I think I’ll move back over to the engine proper and get textures loading.

Command is the class I use to implement undo/redo functionality, Commands have Execute and Unexecute methods which perform the steps needed to carry out or roll-back the command. Now, it is slightly tedious to write a whole bunch of commands that merely use accessors to set a value on on object, so I decided to spend some time attempting to come up with a better solution (warning: template code ahead).

So, I needed some code that would, when constructed, use a ‘get’ method to get the current value of a property, then on Execute(), set a new value and on Unexecute(), return the value to what it was when the command was constructed, this is what I came up with:

//! Templated class for a command that calls a getter/setter to undo and redo
template < typename Obj, typename Type, Type (Obj::*Getter)() const, void (Obj::*Setter)(Type) >
class GetSetCommand : public Command
{
public:
//! Constructor
GetSetCommand(
    Obj* pObj,          //!< Object to act upon
    const Type&; value  //!< Initial value to set
)
: m_pObject(pObj)
, m_NewVal(value)
, m_OldVal()
{
    m_OldVal = ((*m_pObject).*(Getter))();
}

//! Destructor
~GetSetCommand()
{
}

//! Execute the command
//! \return True if change was successful, false otherwise
bool Execute()
{
    ((*m_pObject).*(Setter))(m_NewVal);
    return true;
}

//! Reverse the command
//! \return True if reversal was successful, false otherwise
bool UnExecute()
{
    ((*m_pObject).*(Setter))(m_OldVal);
    return true;
}

private:
    Obj* m_pObject; //!< Object to act upon
    Type m_NewVal;  //!< Value to set upon execute
    Type m_OldVal;  //!< Value to set upon unexecute
};

This lovely bit of template magic does the trick, it has 4 type augments, the type of the object that owns the property we are changing, the type of the property, and a gettter and setter functions. This allows me to typedef versions of this template, like so:

typedef GetSetCommand < AssetDatabaseItem, std::string, &AssetDatabaseItem::GetName, &AssetDatabaseItem::SetName > NameCommand;

So whenever I need to use that command, I can simply create a new AssetDatabaseItem::NameCommand and all the template black magic is hidden. I actually have two versions of this template, one for intrinsic types, shown above, and one for complex types, where the getter function is defined as taking a const reference parameter, to avoid the copying costs.

Other than that, I’ve implemented adding textures and folders, and updating properties, I’ve also made it easy for the asset manager to determine if the properties of an asset have changed since the last time that asset was compiled (by adding a unix timestamp ‘modified’ column to the database) so I can tell if an asset needs to be compiled again.

This week I plan to add some more polish to the process of adding textures, currently you have to enter all the information manually, however I feel it would be better if, when you selected the source image, if the output width, height and name were all filled in automatically (to values that matched the source asset), I also want to make it easier to add multiple assets at a time, as I think that adding a folder full of textures will be something that happens quite often.

Previously, to get a list of items from the database, you called a method on the AssetDatabase class, which returns a vector of items, both the vector and the items are allocated during this time, and it is the responsibility of the calling code to delete these, this bothered me while writing it, but I couldn’t think of a better solution at the time.
This approach became worse when it occured to me that if the GetItems method were to be called multiple times, there would be seperate objects in seperate lists pointing to the same database item, which makes updating items a nightmare, as the database and all items that pointed to that database item would need to be kept in sync.

This was the final straw for the code as it was, now being decidedly not fit for purpose, I refactored this into a better system. The new system starts with changes to the AssetDatabase class, now when a database is opened all the items are retrieved from the database, and stored in per-table std::maps with the rowid of the item as the map key the AssetDatabaseItem structs have been promoted to classes, containing a pointer to the AssetDatabase they belong to, the public member variables have been replaced with accessors, and all the ‘set’ functions call a method on the AssetDatabase to update the SQLite database with the new value.

Any code that wishes to get a list of database items needs to allocate a list and pass it by reference into a function that will query the SQLite database for the relevant rows, and then use that as a reference to the various std::maps to retrieve the relevant AssetDatabaseItems

This new system means that any number of asset lists can be gloating around and they will contain pointers to the same objects, managed by the AssetDatabase they came from, and any changes to any properties of any of these items will be reflected in the SQLite database.

As well as this rather epic refactoring, I also created a custom wxImageHandler to save and load images in the engine format, added support for all the different types of dxt compression and added properties to the compiled image. Next I need to actually detect and handle the changes in properties, something which is complicated slightly by my wish to be able to undo and redo such actions, meaning that they will have to be turned into a command class, whilst this complicates matters slightly, the advantage of having functioning undo and redo buttons in any application is worth the effort.
After that I will add the ability to add and remove database items (all my work currently is based around a test database created from hard-coded data) and make sure that works, I can then test the system with some more realistic data.

I have had some more ideas for the job queue, but I think I need to read up on some existing implementations before I commit to an approach, I also feel the need to plan this system out properly before starting coding, as it will be an important system and debugging threading issues can be tricky.

I’m in London this weekend so no coding will be done (I’m writing this on my phone on the train) so the next update may be a bit sparse, depending on how much I manage to get done in the evenings this week.

I improved the AssetListPanel wxControl, so it now nicely shows a list of assets (in either a list view or a tree view), polished that a bit more too (making it so that the selected item is mirrored on the other view, and adding a custom wxEvent for an item being selected). I created a BitmapWindow, which is a form of wxScrolledWindow for displaying bitmaps (the background is the grey and white check pattern that will be familiar to anyone who uses Photoshop or other graphics tools) and I created a TextureViewPanel, again a custom wxWidget for displaying a texture.

Here’s what it looks like:

Asset Manager showing a texture in it's original, and compiled versions

The image on the left is the original source image, and the image on the right is the compiled version, I still need to add some stats for the compiled version and add them to the property grid the same as they are for the source image.
I also, (kinda) have compiling textures in, but it needs a lot of work, currently if you select a texture and it can’t find the compiled version, it will compile it, however, currently the compiling only supports DTX1 format and it takes ages blocking the main thread the entire time it does it. So, next on the todo list is to move that on-to another thread and stick a progress bar on there. I’m using LibSquish to encode the image for me, which took a little while to getworking but seems to produce good results and doesn’t involve too much code.

The current todo-list, in no particular order, is:

• Add support for the other DTX formats
• Crete a custom wxImageHandler to handle loading of the complied textures
• Create a simple job system (that the engine will also use) and use that to take care of compiling textures
• Add an ‘update’ button to the TextureViewPanel that will save off any changes to the compiled texture and recompile it
• Add buttons to lock the source and compiled texture view scroll bars
• Add buttons to add folders and textures

I think I’ll get all the basic tasks done before moving on-to the job system, as that will be a bit more involved (and hopefully more fun)

Firstly, and least importantly, I finally replaced the ugly place-holder ’compiling’ animation:

Just picture it animating

You can now pass options to build scripts. When you create a build script it has an ‘options’ dictionary, two types of option are available text (which can have a default value) and lists (default value is the first item), when you add one of these build steps to a repo, the option is displayed below:

Setting the branch we want the HG build step to update to

So here we’re changing the branch that the HG build step should update to, the default is ‘default’ (specified by the options map) which is the name of the default branch in a Mercurial repo.

Next BuildMaster now contains code to attempt to automatically build a repo when a change is detected, currently this only supports parsing an RSS feed (as Mercurial repos produce an RSS feed by default, and RSS is perfect for this). Originally I considered setting this up with hooks, but it seemed like it would be difficult to account for the Cerberus server not having a constant IP and being on a different machine to the repositories, however, since RSS feeds allow for active monitoring of the repo, and make it easy to determine what the last built commit was (each RSS entry has a unique ID) it made for a very nice solution to those issues.

For a repo to be eligible for automatic building, you need to store an Auo build URL

Currently the auto-build system only requires a per-repo URL, this was so that in future, the system can be expanded to handle other source control systems (for example parsing an SVN repository for the revision number of the most recent commit).

Other than that there has been much tidying up, I moved a lot of code to the BuildMaster class and renamed cerberus.py to server.py to more accurately reflect it’s function. BuildMaster now acts as the go-to class for the server to interact with, with server.py merely conditioning data to hand to BuildMaster and formatting data that is returned from it. A general code clean-up was also carried out, and I finally got around to including a ‘Licence.txt’, containing the terms of the licence the source is released under (MIT Licence).

Feel free to grab the source from BitBucket, no guarantees that it will work for you or that the code is good, it works for me and that’s good enough.

Right, onto the next project.