A few years ago I did something similar with these libraries and requirements, I'll talk briefly about these things.
So the two main areas of interest are views and SFGUI. I'll start off by picking at the oddities of each.
View
The name is self explanatory, it represents a portion of a larger game world. When drawing you may want to draw as an overlay and then reset draw target to the scroll-able view area for unit drawing. Inheriting sf::View is quite common. However note there's no getPosition() anymore, it's been replaced with getCenter(), which gets the centre most position in view instead of the top left corner.
SFGUI
I used to use this before CEGUI. To get a minimap working, I just used an sf::Image (unless I remember incorrectly), and make it draw the new tiles which come in view as you scroll.
There were a few things which put me off using SFGUI however.
Here's a list on some of the notable good and bad:
- The documentation is very good, clean and consistent.
- It integrates well with SFML and is updated regularly regularly.
- Event handling is simple and effective.
- The lack of aesthetic fulfillment leaves interfaces looking quite primitive and plain.
- Layouts can be a real hassle to get absolutely right. We always had to settle for something less
CEGUI was a little more difficult to compile as minor changes had to be made for it to successfully compile under MinGW, also the documentation for the CEGUI integration for SFML is both outdated for the latest SFML and CEGUI. So this helps:
http://skyr.at/sfml-and-cegui-083.htmlI'd say CEGUI is a lot better for games and can be made to look much better and the layout handling is great in comparison. It works well with dynamic alignment and resizing, SFGUI is a bit of a hassle in alignment. Maybe it's changed, although I don't believe it has.
CEGUI still has some daft qualities to it, some of which has been addressed recently. For instance, event handling related data in the doc has to have a series of if/else statements static casting it into various type of event data until the cast type is accepted. Naming is very inconsistent, there is a close button yet the method name to "close" a window is destroy. Many defaults are a bit strange, like the close button by default won't do anything until an event is added. The cursor/text/windows all stretch and resize on window change, giving blurred edges and strange graphical artifacts. Windows need to be coded to stop them going out of view, a few annoyances here.. I could go on for days, ultimately it's feature complete and much more convenient to theme, making it desirable for game interfaces.
It's just our personal opinion.