Before we start throwing terms and code your way, it's only fair we talk a little bit about the choice library for this book. As its title clearly states, SFML is a library, which speeds up and eases the process of developing applications that rely on extensive use of media content, such as video, text, still images, audio, and animation for interactivity, and we will be focusing on a specific category of those applications, that is, video games. It provides an easy to use application programming interface (API), compiles and runs out of the box on Windows, Linux, and Mac OS X, and is supported by multiple languages, such as C, .NET, C++, Java, Ruby, Python, and Go, just to name a few. Unofficial ports for certain mobile devices do exist out there, however official releases for mobile platforms are still in the works. It's also open source, so one can always go and look at the source code if one is so inclined. In this book, we will be focusing solely on development for the Windows platform using C++11.

For convenience, SFML is split into five modules, which are independent of one another and can be included on a need-to-use basis:

Each one of these modules is compiled in a separate library (.lib) with specific postfixes that signify whether the library is being linked statically or dynamically, as well as if it's being built in debug or release mode. Linking a library statically simply means that it gets included in the executable, as opposed to dynamic linking, where .dll files are required to be present in order for the application to run. The latter situation reduces the overall size of the application by relying on the library being present on the machine that runs it. It also means that the library can be upgraded without the need to alter the application, which can be useful when fixing bugs. Static linking, on the other hand, allows your code to be executed in environments that are more limited.

It's also important to make sure that your application is being built in a mode that's suitable for the situation. Debug mode applications are bloated with additional information that is useful when you're hunting down flaws in your programs. This makes the application run considerably slower and shouldn't be used for any other purposes than testing. When building your project in release mode, tons of different optimizations are also turned on, which not only provides a smaller executable footprint, but also a much faster running speed. This should be the mode an application is compiled in, if it is to be released for any kind of use other than debugging.

Each module is named according to the format sfml-module[-s][-d].lib. For example, the file name of a graphics library that is being linked statically and compiled in debug mode would look like this: sfml-graphics-s-d.lib. When linking dynamically or compiling in release mode, the postfixes need to be omitted. SFML also requires the SFML_STATIC macro to be defined when linking statically, which we will cover shortly when setting up our first project.

An important thing to keep in mind about the separate libraries is that they still have dependencies. Window, graphics, audio, and network libraries are dependent on the system library, which has to be linked to for any SFML application to compile and run. The graphics library is also dependent on the window library, so all three have to be linked to if an application does any drawing. The audio and networking libraries only depend on the system library.

Each one of these five modules has a corresponding header that must be included to utilize its functionality. For example, including the graphics header would look like this:

#include <SFML/Graphics.hpp>

It is also possible to avoid including the entire module header by specifying the actual header that is desired within a module:

#include <SFML/Graphics/Color.hpp>

This gives you a chance to include only the parts that are absolutely necessary.