CEGUI issue tracker now on bitbucket!

Timotei has finished moving the issue tracker from our mantis page to bitbucket. All issues have been migrated with their original IDs, attachments, contents and comments.

The CEGUI issue tracker can be found here:
and the CEED issue tracker here:

Our old mantis page will stay online in read-only mode. Remember that the IDs of mantis tickets are identical to the IDs of the bitbucket if you want to access the new ticket, e.g. : <- migrated from
You need to select the right project on bitbucket first when you do that (i.e. CEGUI or CEED or SILLY)

Here is our twitter tweet:

Feel free to create new issues at our new issue trackers (but please only use it only for bugs/features requests etc and not for support requests and stick with the layout ;) )!

IMPORTANT: Call for bitbucket user names for the CEGUI issues migration from mantis to bitbucket

All current mantis tickets have been migrated to bitbucket issue tracker. Therefore, we call all people who care that their past CEGUI mantis ticket submissions are attributed to their bitbucket accounts, to tell us their CEGUI and bitbucket user names: just write to team (at ) cegui . org . uk - We will then correctly link all comments and reports to the supplied account.

We give users 3 days to notify us. Until then our new issue tracker will not go public. Our old issue tracker will remain online for the next months as READ-ONLY, until we decide to remove it entirely. For now, this means you will not be able to post new issues until the 3 days are over: The new issue tracker goes online on Monday 23rd Feb 2015

So again: Everyone who wants their tickets attributed to their bitbucket account (otherwise it will just say "anonymous" and underneath "original author: XXX") should notify us.

Thank you!

Sorry for the website downtime!

First we had issues with the DNS because of the domain hoster which changed things without notifying us. (great job!). It took us some time to resolve the issue because CrazyEddie's e-mail was not reachable because it was part of this domain and this was the only contact we had of him. I took a while until we found some other e-mail of his, after days of stalking him using search engines.

Btw., in cases like this it is good to check our twitter for updates:

After we had resolved our issues we noticed that our site may still contain backdoors (from the drupal hack-wave in october 2014) and we actually found malicious files there as well as an altered google cache, manipulated php files and finally decided to completely roll back our entire database by months and re-add all news manually. This whole process took us a while. I did the finishing touches today, so everything is up again.

On a completely different note: We are going to remove mantis and move all tickets to the bitbucket issue tracker. In the future users can file tickets there. We believe this will be better for our users.


Happy New Year!

Slight headache after waking up, the limbs feeling stiff after a short night's sleep, small patches of cookie dust sparsely spread around the mouth, the sensation in the mouth that grossly reminds of past sparkly wine consumption, ones hair smelling like short-term exposition to ridiculously high amounts of fine dust pollution: This all is clear evidence to me, that the last year has very recently drawn to its end and I have successfully (and alive) managed to enter a new year, again!

Somewhere along these lines, but actually completely unrelated to them, the entire CEGUI team wishes you all a successful, healthy and overall superior year 2015!

About CEGUI in 2015: The plans for this year for us are mainly revolving around the upcoming 1.0 Release (Q3 or Q4) as well as continuing support and bug-fixes for the 0.8 versions. The 1.0 developmental version already offers a lot of new great features, so that we really wish to release this version as soon as possible, of course we have to finish and test all new and planned features before that. See Martin's and my Todo list on the wiki if you are curious about some of the features we still have to add / rework for the Release or check the forum, the last GSoC topics or chat with us on #cegui.

Also we recently enabled file attachment uploads in our Forum. This will make it easier to show screenshots or describing issues in the future!


CEGUI site has been hacked on 13th November 2014

our site has been hacked on 13th November 2014. I have restored the site and updated to Drupal 7.33. We have no way of knowing what was leaked, so we assume everything was leaked. The passwords in our database are stored in a secure way and are not simply retrievable using rainbow tables or similar. Either way we advise you to change your passwords just to be absolutely safe! We are very sorry for the inconvenience.

As far as I can tell was the exploit used. It's curious that I can see somebody gaining access on 13th November even though the embargo was lifted on 15th November. I will continue to monitor the situation.

GSOC 2014: Model-view project summary


First of all, thanks should go to the CEGUI Team for inviting me as full team member and I humbly accepted it! :)

Now, to the actual article. This summer I worked on a brand new feature for the future CEGUI 1.0 (or, at least, the default branch) called Model View. In short, it's a very nice and good way to decouple the rendering (View) from the actual underlining model (Model), so that they can be replaced as one wishes. For example, we could have a complex (I don't like how it sounds, but for the sake of examples, bear with me) Model that loads some game data from the disk/network/etc. The "Model" is just a term for some class(es) that hold some pieces of data that are necessary for the game. Once you have the model created, you can create multiple views that represent data differently. For example, you can show it via a list view, grid, tree or a custom view you have created. The "View" is represented by a widget/control.

But, in order to provide easier (initial) migration to the new views (yes, we removed the old Listbox/Tree/Itemlistbox - and we'll remove some more, as soon as we have replacements; yes MCL, I'm looking at you!), we have created some convenience widgets that have the view and model in the same package so that they can be used as an in-place replacement from the old ones.

Unfortunately, I don't have any (relevant) screenshots of the new changes, since they are mostly internal, but at least, the TreeView rendering is now much better in respect with the icons.

Another thing that might be of interest, is the performance of the new views. In the following table we can see the improvements, for a benchmark of different usage patterns (total time taken to add ~500 items, clear them, add some more ~1000, edit some, delete some - and with rendering after each step):

Widget -> View Widget test running time (seconds) View test running time (seconds)
ItemListBox -> ListView 3.35 1.40
ListBox -> ListView 1.96 1.40
Tree -> TreeView 1.96 3.85

The tree unfortunately takes a bit more time, but it's relatively the most basic implementation and no attempts to optimize it have been done :) But once we'll finish them you can expect at least the original speeds, unless even speedier.

That's all for now!

PS: Stay tuned for some news related to CEGUI binaries and simpler/nicer integration of CEGUI with your projects! :D


GSOC 2014 is over: CEED project summary

As some of you might know (although I guess most of you might not be aware), Timotei and me participated in GSOC 2014 this year. My project was to create a Look n' Feel editor to CEED for all 0.8.X version of CEGUI (we also support higher versions of course). This is a feature that has been missing in CEGUI until now. Before CEED, CEGUI has had tools for layout and imageset creation and editing, such as the CELayoutEditor. However, Look N' Feel (LNF) editing has never been possible and as far as I know creating an editor hasn't even been attempted. I thought this would be a pity, considering that the ability to creating new widgets is crucial for GUI development in many cases. Skinning of widgets is also easily possible with such an editor, working purely in an XML editor to accomplish this, is otherwise very tideous: there is no preview, no good overview of the possible attributes, no helpful features such as Colour Picking/Image Selection/Font Selection etc. and every change has to be tested by starting the application running CEGUI - an inefficient process.

With a proper tool however, it becomes really easy. This is why I decided this would make for a great addition to CEGUI. I was not acquainted with CEED development and the Python language, but I relatively quickly worked myself into the large CEED code base and learnt to use Python, which was actually relatively smooth. PyCharms were so nice to privde us with a free license for Open Source projects, thanks to PyCharms at this point!

Unfortunately, when I started to get to the "real" development of the editor, I encountered numerous issues in the CEGUI C++ code. Some of the files were created around 10 years ago and they seem to have hardly ever been updated. Also a newly added "inheritation" feature showed numerous occasions of faulty behaviour that could have caused crashes, if it had ever been used (it is badly documented so we doubt anyone used it). Due to this, a lot of the Falagard code had to be reworked, which took a good chunk of my time of the GSoC. At least one thing that is positive about this is that I was able to fix a lot of issues and rework a lot of functions which results in now cleaner code in this section of CEGUI.

Now to the real deal: The editor. In the screenshot below, you see me editing a Vanilla/Button look n' feel in CEED. Generally it would be recommended to either inherit this button (not yet implemented) and work on the inherited LNF, or to copy paste the definition into a new file and work on that file (we will add a shortcut for this in the future). But for the sake of a quick preview I m directly editing the original file. On the top left you can see the WidgetLook (WL) selector (selects a WidgetLook defined in the LNF file being edited), which consists of a dropdown selection to choose from the available WidgetLooks and of an Edit button. On clicking edit, the specific WL is opened. Below is the hierarchy window. It contains the editable attributes from the XML in a ordered and categorised tree. Selecting an attribute show a list of new options in the Falagard Element editor on the right. These options can be edited with a double-click on the value. Depending on the type of attribute, the easiest and most intutitive way to change the value is chosen (for example a ColourPicker for colours). Images (and Fonts) can be selected from a dropdownlist containing all loaded Image (or Font) definitions; bool is represented by a checkbox, etc etc. The changes are directly applied and can be seen in the Preview instantenously. In the shown case the "NormalImage" PropertyDefinition's initial value is overwritten. This means that now there is an image set for the button by default, as can be seen on the screenshot. We already support editing of pretty much every type of attribute.

I also added alternating colours for the lists and trees, which I also applied for the pre-existing layout-editor. This is based on the look of QtDesigner. I hope users will enjoy this change, I personally definitely prefer it over the alternating grey tones we had before (They were too sad!). I also worked a bit on the Code editor of the LNF Editor. By default the LNF code editor now highlights the part of the code that is part of the currently edited WidgetLook. Additionally, it jumps to the beginning of that code when changing to the editor. This should make it much easier to edit code by hand because the user does not need to scroll to the right widget every time and has an easier overview of the code relevant to the widget thanks to the colour highlighting.

The LNF editor is not complete yet, but definitely the main part of the work is done, the overall setup is there and most of the LNF is already displayed and editable, many features are tested and are actually working very well. It can already used for simple skinning such as mere replacement of images in a LNF file. In the future we will add some features that allow way easier creation of new LNFs and new Widgets, add inheritation and allow an even broader set of changes to LNFs. If you consider already using the CEED changes, you have to be aware that the LNF editor is currently unstable (make backups of your CEGUI datafiles and save regularly while working on them!) and some parts are not fully implemented yet, therefore it should be used with great caution until we officially announce it is finished.


Discussion on future removal or rework of CEGUI::ColourRect (NOW WITH POLL!!!)

Not too long ago there has been a great addition to CEGUI: The Animation feature done by Martin. This feature revealed a performance issue for CEGUI windows: Animating a ColourRect property will trigger a reconstruction of the entire GeometryBuffer's vertices. The data of each vertex has to be recalculated to match the new ColourRect. The creation on the CPU and the uploading to the GPU of those vertices creates quite a performance impact. This situation could of course be improved by more complex measurements, such as double-buffering our vertices. This works the way that we mirror the buffers and use one for reading and one for writing for each frame, and swap them whenever we need to update a buffer on the GPU. This would solve at least the data transfer problem and help a lot, but it would effectively double the GPU data used and the CPU load would still be there. Using non-interleaving GPU data would be another way to do it but that is also not a solution free of downsides.

The first thought we had was trying to replace this functionality using shaders (which would of course not work with fixed function pipeline). However, I quickly came to the conclusion that this is not feasible. The data is per-vertex and can't be easily simulated. A global (uniform) value would work, but that cannot reflect per-vertex behaviour unless using complex tricks. When I told Martin this he agreed. However after thinking about it again I thought of a workaround: Each vertex would have to have an attribute added (for example represented by 1 byte) which stands for the corner (e.g. left top = 0). The colours would be provided as a array of 4 vec4's in the OpenGL shader (and analogously as float4's in the Direct3D shaders). Using the ID of the vertex attribute, the right colour can be accessed. This would in total require uploading 16 floats for each window (unless the last 16 were equivalent), equivalent to the size of a matrix. Also it would require adding 1 byte (this might end up taking more space in reality due to padding/alignment) to the vertex data to provide a fixed ID. The geometry would not have to be regenerated again this way.

The other way would be to remove ColourRect entirely and just offer Colour in the future. This is where we would like to invite everyone for discussion to give reasons why ColourRect should be retained.

Reasons I see for removing it:
- For widgets/windows, the ColourRect changes the overall look of the window in a quite "unpredictable" (as compared to what you can do in image editors) way, basically creating a multiplicative gradient of colours over it. In my opinion, instead of relying on this, users should simply be using different imagery for the widget.
- For Font this does the same thing: applying a quite "unpredictable" but simple linear gradient over text. This might sometimes be nice to have, but most likely, just for windows, it won't be useful. If users want fancy Fonts, they have the functionality of Bitmap Fonts in CEGUI, allowing them to create all letters in whatever exact way they want them to look, and save them as imageset.
At this point I want to remind users of Zadirion's CEGUI Font Exporter for Font Studio:
- This would allow us to easily remove it boosting both CPU and GPU performance in CEGUI especially during animation, and simplifying CEGUI further.

Reasons for keeping it:
- It is always bad to remove a feature and better to find a way to keep it
- Someone could be relying this heavily (please inform us then, this is the time!)

Please join our forums and discuss with us:
Edit: Now with 100% more poll!

Multi-process building enabled for Visual Studio

For all future Releases and all current branches (v0, v0-8, default branch) the /MP option for building multiple processes has now been enabled. This means that CEGUI will build faster if multiple cores/hyperthreading threads are available.
According to our research and experience there shouldn't be any issues with VS 2005, 2008, 2010, 2012 and 2013. I personally tested the changes with VS 2008 and 2010 and 2013 was tested by another team member. In all tested versions, the multi-process build setting worked as expected using all available cores/threads, even in the aged Visual Studio 2008 (with SP1).

As always, if anyone sees any issues that could arise due to this change, please inform us about it in the forums or by chatting with us in our IRC channel.

Below i added a screenshot from VS 2010 building CEGUI with the added /MP flag in usage. CPU is a Quad-Core with Hyperthreading, all threads are used which leads to almost 100% CPU Usage. The CEGUI team stands united in the belief that this screenshot will amaze absolutely everyone.


0.8.4 Release broke ABI & API compatibility

In utter shame I have to admit that amidst of hundreds of changes from version 0.8.3, there has been one change which caused an ABI and API break. In case you rely on ABI and API compatibility, you are advised to skip this Release and use the upcoming 0.8.5 Release or downgrade to 0.8.3. In order to prevent this from happening again, we increased goat and leprechaun sacrifices by 78%.

For further information:
The following symbol is the one that was accidentally removed by a person who is from Austria and likes mustard. I will not name him!

CEGUI::S_parentIdentifier [data]
[symbol: _ZN5CEGUI18S_parentIdentifierE]

We will readd it in 0.8.5 to avoid breakage. 0.8.3 -> 0.8.5 will be compatible, this issue will only ever apply to 0.8.4.