News


We are constantly improving our website. If you notice bugs feel free to tell us in the forums! Please use the donate button on the left if you want to support our project!


GSOC 2014: Model-view project summary

Hi!

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

Image1: 

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.

Image1: 

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: http://cegui.org.uk/forum/viewtopic.php?f=7&t=6367
- 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: http://cegui.org.uk/forum/viewtopic.php?f=6&t=6863
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.

Image1: 

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!

PropertyLinkDefinition.h, libCEGUIBase-0.so.2.2.2
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.

CEED 0.8.0

The first stable release of CEED has been released. Archives provide testing sample data with CEGUI 0.7 and CEGUI 0.8 datafiles.

There have been 11 tickets resolved compared to the last snapshot11. Most of the tickets are bug fixing and stabilising changes.

Grab the source tarball, Windows standalone binaries or Windows installer. The MacOS X app bundle will come later:
https://sourceforge.net/projects/crayzedsgui/files/CEED/0.8/

We have decided to name the CEED releases according to which CEGUI the release is based on. CEED 0.8.x will work with all CEGUI 0.8.x releases. CEED has a stable branch called v0-8 that serves a similar purpose as CEGUI v0-8.

State: 
Stable
Branch: 
0.8
Changelog: 

- 0001035: [General] CEED should put /usr/lib64/python2.7/cegui-X.Y into PYTHONPATH (Kulik) - resolved.
- 0000930: [General] Explicitly check FBO support and report if it's not there (Kulik) - resolved.
- 0001020: [Layout editing] Feature: Strip all comma values from all absolute position and size values - Add button that prevents this while moving/resizing (Ident) - resolved.
- 0000969: [CLI tools] Whenever anything fails in ceed-mic the tool is stuck forever (Kulik) - resolved.
- 0000943: [Layout editing] Preserve expanded/collapsed when dragndropping/reparenting widgets (Kulik) - resolved.
- 0000951: [Compatibility layers] Error when migrating looknfeel (Kulik) - resolved.
- 0000940: [General] Changing shortcuts of actions with no default shortcut fails (Kulik) - resolved.
- 0000939: [Layout editing] Recursive lock/unlock of widgets in layout editing (Kulik) - resolved.
- 0000897: [Imageset editing] Editing GUI for per-image autoScaled and native{Horz,Vert}Res (Kulik) - resolved.
- 0000569: [General] Dock widget resize handles are super small (OSX) (Kulik) - closed.
- 0000497: [General] Help API + the ability to declare which help sources are relevant to which functionality (Kulik) - closed.

Category: 
CEED

CEGUI 0.8.4

Patch release from v0-8 branch - It contains many minor fixes and changes. You can use the following links:

Source Package Downloads:
Source code packaged a a .zip file
Source code packaged as a .tar.bz2 file

Documentation Downloads:
Documentation packaged as a .zip file
Documentation packaged as a .tar.bz2 file

Dependencies (Windows / Apple OS X Only):
http://prdownloads.sourceforge.net/crayzedsgui/cegui-deps-0.8.x-src.zip?...

Or click here for the online version of the docs

State: 
Stable
Branch: 
0.8
Changelog: 

- Package 'promo' dir, people might want to use logo in their products.
- FIX: Static linking issues. See new CEGUI_BUILD_STATIC_FACTORY_MODULE option.
- FIX: I broke the CMake before by omitting an endif()
- MOD: docu was a bit unclear
- MOD/ADD: if samples browser is compiled in debug mode, the mouse can now leave the window. if it comes back into the render window, its position will be set properly and won't be set to the centre of the window.
- MOD: Fixing ouput message for Ogre if OIS wasnt found - fix by Henri Hyyryläinen
- MOD: SamplesBrowser can now be closed by clicking the 'X' on windows when using OGL(3) renderer
- Added a note about changing default image to getMouseCursor
- Fixed issue #1031
- MOD/FIX: Changing the mentions of "True" and "False" to the xsd:boolean conform
- MOD: Adding if-cases to prevent divisions by zero from occuring and handling it
- FIX: Making looknfeel files xsd::boolean conform by replacing True by true
- MOD: Adding top-level target dependencies for the samplebrowser
- MOD: Removing the "filename:" info from all license headers
- REM: Removing some ultra-vintaged empty files
- MOD: Fixing the docu
- MOD: Extending the hgeol file
- MOD: Fixing the doxygen docu for releases, linking to our website now instead
- Fix compilation on MinGW
- MOD: Removing redundant xml ban that used to cause a warning about HorzExtent
- MOD: Adding <algorithm> as include for all compilers and modifying include order
- Moved readme to ./README.md where bitbucket will pick it up
- DirectFB is not supported, let us say so in the cmake option description
- FIX: Fixed an issue in the Samples that is only popping up when using VS2008
- MOD: Replacing last strings in the XMLHandler to replace them with static getter
- MOD: Changing serialisation order of elements to make it more intuitive to read
- MOD: Adding widgetComponent default and adjusting serialisation
- FIX: Fixed directive in merged pull request
- MOD: Fixed order of serialised output
- MOD: Fixing the default value comparison
- MOD: Added a getter to FormattingSetting, added default values
- ADD/MOD: Broad refactoring and general fixes of Falagard serialisation
- FIX: Fixing comments, calling write attribute function correctly
- MOD: Changing local variable to const
- MOD: Fixing assert issues on MSVC in glm when a 0-sized window is used
- MOD: Fixing qualifiers for GCC and other compilers - this time for real!
- MOD: Fixing qualifier for GCC and other compilers
- MOD: Fixing serialisation output in an ABI-compatible way for v0-8
- MOD: Default value for "help" attribute in Fal
- MOD: Changed the serialisation of attribute "inherits" if not inheriting
- MOD: Added a const default value string for the help value to replace the hard
- MOD: Added helper functions for WidgetLook XML serialisation to be used in CEED
- Fixed up CEGUI.pc - include dir is /usr/include/cegui-0
- FIX: switch to 'if test' syntax from 'if [' for shell commands (cmake issues)
- Fixed Bug when not registering Root Namespace
- Added LuaDoc export to tolua++ bin
- Changes required to expose Falagard related iterators in PyCEGUI
- Hidden "getMouseCursor() const" from GUIContext in PyCEGUI
- Tweak the perform-cppcheck script
- Enhance perform-cppcheck script
- Fixed FSF address in datafiles/fonts/LicenseGPL.txt
- We need to install PyCEGUI into the platform specific python site-packages
- Use utf-8 in doc/README
- MOD: Fixed broken SampleBrowser build for several Renderers
- Fixed a copy-paste error in ScrolledContainer
- Complete initialization of Ogre::LayerBlendModeEx objects.
- FindLua51: Also look for lua.h in the "lua-5.1" directory.
- Fix build with >=freetype-2.5.1 wrt #1007
- REMOVE: StringEncoder license stuff
- MOD: Fixed samplebrowser crash on exit during load-phase and minimal refactoring
- MOD: CMAKE - Added .inl files to the projects, formerly they werent added
- FIX: DirectFB default off in CMAKE
- FIX: Fixing the content area calculation in the case of Center aligned windows
- MOD: Fixing Spinner window text update on value change
- MOD: Default options in CMake changed to the actual default values we agreed on
- MOD: Moving CMake Sample dependency check
- MOD: Added SampleBrowser dependency checks and default Sample on/off checks
- MOD: Adapting code files for CMAKE CEGUI_SAMPLES_USES* changes
- MOD: Preparing CMAKE for CEGUI_SAMPLES_USE_* removal
- MOD: case sensitivity related bug in cmake
- FIX: Adding includes required for deletion of instances and using OGRE_DELETE
- MOD: OgreRenderer modified to support the latest Ogre default branch
- FIX: Ogre getFixedPipelineEnabled() not defined without RTS, removed build issue
- Solved compile error with Python bindings, due to some Ogre classes declaration (v0-8, 4-space-tabs).
- FIX: Undeclared function would be called in case of no RTS built for Ogre
- A) fixed new CMAKE policy CMP0045 issue in CMakeLists.txt. This feature was introduced recently in this commit: https://gitorious.org/cmake/cmake/commit/73e93400e2efab2096618ff58a5ad68... ... Bb) fixed CMAKE problem with cmake/CEGUIMacros.cmake when including the project with ExternalProject_Add() CMAKE feature in a project. I had to escape the '[' and ']' characters because in this way CMAKE was not recognizing those characters. CMAKE version: 2.8.12.
- MOD: Fixed VS2013 compile error - thanks to JKnife
- Backed out 209e31f: MOD: Changing DefaultWindow maximum size
- Fixed Console.wnd, previously it was an invalid layout (a mix between 0.8 layout and 0.7 layout)
- MOD: Changing DefaultWindow maximum size
- ADD: Added visual studio templates that are used for proj settings of samples
- Fix the CMP0022 policy on CMake 2.8.12+
- FIX: Fixed a typo that caused a compile error, good job me! good job.
- MOD: Tiny change to Ogre thread provider effects on cmake and comment to it
- FIX: Fixing ogre cmake for the case that no threading provider is used
- MOD: Fixing messed up warning message, fixing default window size in Ogre D3D
- MOD: Forgot to add declarations for OgreTexture changes
- MOD: Forgot header for OgreBaseRenderer changes
- MOD: Changed blitting behaviour of texture and minor fixes
- MOD: Fixed shader related issues, added OGL3.2+ glsl shaders, made it GL3 ready
- MOD: Added default config options for Ogre Samples and visible mouse in debug
- Fixed a build error in falagard/TextComponent when BIDI support is enabled
- MOD: Fixed a bug that made OgreRenderer link to the Ogre release lib always
- MOD: Added the possibility to find OIS if stored as Ogre dependency
- Fixed minor typo in docs neglecting CEGUI namespace.

Category: 
CEGUI

Improvements to our documentation infrastructure

  • The "missing text in diagrams in API reference" issue was finally solved. Diagrams now work everywhere, including the 0.7.9 and 0.8.3 docs.
  • We have converted our README files to markdown syntax. Bitbucket now shows helpful overview content on our CEGUI and CEED repos.
  • Our official documentation landing page at http://static.cegui.org.uk/docs was greatly improved. (kudos goes to Timotei for web design)
  • The version switcher in API docs can now handle fragment components in URIs. You should no longer see any "Invalid request" fatal errors when switching versions.

We hope that you appreciate our continuing effort to improve our documentation and the infrastructure surrounding it.

Current developments in CEGUI and CEED

GSoC 2014 has started and timotei and me (Ident) have both been accepted with our projects. Timotei will work on the internals of CEGUI and rework important parts of it to adhere to the Model-View pattern. Read the short description here. I will work on CEED to add an Editor for Look n' Feel files of CEGUI. The editor should make it a lot easier for CEGUI users to skin widgets, which previously had to be done in XML exclusively. Read the short description: here.

Timotei already made good progress and I already added a new feature to the CEGUI Layout editor and started working on the editor for editing WidgetLook properties. Additionally the CEGUI team is always working on bug fixes and the next minor release (0.8.4 based on v0-8 branch) should be coming soon.

In our unstable CEGUI default branch, the OgreRenderer and IrrlichtRenderer are still broken currently after my changes during last summer's Google Summer of Code. However the Direct3D11Renderer has already been completely redone and contains some important improvements compared to the previous versions of the Renderer (see previous news). The OpenGL and OpenGL3 Renderers in default branch are functional. In the little time we have, the CEGUI team is also trying to get the IrrlichtRenderer and OgreRenderer updated to work with the general CEGUI Renderer changes, this might still take a while though. As always, we recommend the v0-8 branch for stable development.

CEGUI C# port: SharpCEGui

We want to announce that there is a "quite new" (1 year old, but we hadn't discovered it until now) C# port of CEGUI called SharpCEGui available on bitbucket: https://bitbucket.org/icehole/sharpcegui.

Upon asking about the functionality, one of its developers replied to me that it  in a good shape and can be used:
"Well the port it's in good state (there are some NotImplementedExceptions) but most of the samples are working.(the animation sample it's not ported) I have ported almost all the codebase of the original library except the new commits that You have made with the svg support and the commits of timotei for the new input handling but I will (lack of time)."

The developers are part of the company Icehole Games (http://iceholegames.com/), if you want to check them out.

We haven't personally tried the port out but it looks very promising. If you have tried it out and want to tell us how it is, then feel free to discuss the port in our CEGUI forums.

Pages