Still, I found myself with some free time yesterday and took the opportunity to try out a new framework mentioned on http://gpwiki.org/forums called SFML (Simple and Fast Multimedia Library). It's an Object Oriented C++ framework designed to speed up development of certain types of applications (games being one of them) and I have to say, first impressions are good.
Coding wise, the library is definitely simple and fast to pick up. It is organised into logical packages (system, graphics, windows, audio, networking, etc.) and can be used with either a package include (#include
Still, it is only a simple library so it must have some things it ignores or doesn't do well surely? Well, it only provides it's interfaces for 2d drawing operations. This doesn't make it useless for 3d though as once you have created a window (a single line of code, can't be much simpler eh? :)) then you have access to OpenGL for all your 3d needs. That's it, you include the headers, link it, open a window and you can use OpenGL. None of this messing around with creating a window with different parameters that is so common with other libraries. That makes it about as simple as possible for 3d development as well as 2d (if you have an engine that uses just OGL and requires a window set up for use, then it should work with SFML with almost no fuss). How about 2d and 3d together? Again, simple as can be, you just create a graphics RenderWindow (used for all SFMLs 2d api drawing) and you can mix and match OGL and SFML.
That last point needs to be taken with a slight pinch of salt though. After a very brief play with the library, I've already noticed that there is a slight speed issue with this. I've yet to track down exactly what is causing it (I'm using boost lexical_cast for an fps meter, so it could be that being called 20 times a second that is the bottleneck) but with a simple rotating cube and aforementioned FPS reading I was only getting 20fps. I wouldn't hold this against the library though. Mixing their 2d API with arbitrary OGL calls would always be a tricky operation. I believe it is made easier by their use of OGL under the hood for 2d API operations (or so I believe) but that introduces a problem of it's own, namely state management. With their 2d drawing, they will need to maintain both their state and your OGL state and switch them at the start and end of each function that relies on it. Even with the best algorithms this is a costly operation. It is recognised by the library creator though and they provide a way to turn off the state management if you use SMFL exclusively (or wish to manage the state yourself, as then you can store and manage state on a more sensible level than 'in my code, I must save your state').
I have yet to explore their sound or networking libraries, but I expect more of the same from them. The sound package is built upon OpenAL, so I would expect a fairly decent wrapper around that judging by the rest of the library. Networking is on the level of class-wrappers for network sockets etc. and so is probably the most low-level API available in the library. I'll comment more on them when I have used them more though.
My first impression is one of good, clean design and a decent implementation. Some possible speed issues that I haven't confirmed yet admittedly but even with that I have no problems recommending that anyone thinking of writing games and multimedia applications in C++ at least look at this library for their initial development period.