A weekly check-in (almost)

And as a complete surprise, I've actually been doing some game-related programming this week :)
It isn't exactly interesting programming, but it's been fun doing it. I've been recreating my event-dispatcher and input manager code around SFML and, due to how easy SFML makes creating thread-safe code, I've even turned it into a threaded system while I was at it.

I've still got a bit left to do with my input-action code (namely, actually re-write it :)) but so far it's been going well. It took me very little time and effort to wrap an SFML event source (i.e. a window) into a class that would translate the event structure into a series of Event-derived classes and dispatch them to registered listeners. Then a little bit more to write listeners that would let you register multiple other listeners (multiple dispatch) to get events around the entire system.

I've almost finished with my input code as well now, with a keyboard and mouse class that can be registered as event listeners and give you input references to check if a button or key has been pressed (request a key input, it gives you back an input object that is bound to the key... a nice amalgam of polling and events I reckon :). The last section that I've just started on is to bind the inputs into named actions, which will allow a config file to load a set of actions and key mappings into the events and check for the actions by name rather than by key. It should be nicely configurable by the time I finish, unless something shiny distracts me sometime in the next week and I abandon it again :)

After that, I'll start working on some graphical stuff, although I am also thinking of some network engine stuff that I want to add to allow for even more ease of use with networking. If I do that next, I'll do a review on the SFML network package.

Other news: Wedding is getting closer and closer, and I have a hamster show to attend this weekend. Lots of fun :P

SFML - Getting back on the wagon (A brief review)

It's been a while since I've updated. That's mainly due to a lack of time to do any personal programming as I've been busy at work and organising a wedding (My own :D).

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 ) or at a class level (#include ) allowing fine control of dependencies and coupling. Using the items couldn't be simpler either. The classes are typically designed along RAII principles and when they aren't (as is the case with mutexes) then an RAII wrapper is provided (in the previous case, the wrapper is the lock class). The interfaces to the classes are clean and simple to use and if you use a code-completing IDE such as Visual Studio then you also have easy access to the comments when browsing for the correct method (at this point it almost goes without saying that the comments are simple, but not too simple ;)).

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.