SFJ is two things: The black_label support library and the cave_demo application. The latter showcases the former.

black_label — Portable C++14/1z support libraries. Named after a whisky as with all of my support libraries.

• rendering — Low-level: OpenGL wrappers. High-level: Multi-threaded asset manager and a data-driven rendering pipeline.
• file_system_watcher — Subscribe to file system events (file/directory creation/modification/deletion).
• utility — Mainly for convenience. scoped_stream_suppression for those annoying libraries that clutter std::out/std::err. A checksum function when you just need a quick CRC32 checksum and nothing else.
• ...And lots more!

cave_demo — A demo application to showcase the black_label libraries. Initially featured a cave setting (hence the name) but evolved from there.

• Renders dynamic 3D scenes in real-time with physics.
• The entire rendering pipeline is data-driven. I.e., a rendering_pipeline.json file describes each rendering pass and the resource handling between passes.
• Fast iteration times. The asset manager and file_system_watcher libraries are combined to deliver file system-level synchronization of assets. E.g., edit a texture in Photoshop, save it, and the changes are reflected instantaneously in the real-time rendering. Likewise, edit a shader program, save it, and the new effect immediately appears. Same goes for the rendering_pipeline.json file.
• All aspects of the rendering are physically-based.
  • Area lights and the accompanying soft shadows.
  • Torrance-Sparrow and Oren-Nayar BRDFs.
  • Ambient occlusion (local approximation).
  • Global illumination based on photon differentials (work in progress).
  • ...Gamma correct, HDRI, LUT-based post processing, and everything you would expect from a state-of-the-art renderering pipeline.

There are also many deprecated libraries which I keep around for historical reasons. They are still good inspiration but have been superseeded by another (3rd party) library.

A good example is the thread_pool which I wrote before I embraced Intel's Threading Building Blocks. It was a good exercise on multi-threaded programming. I'm still really fond of the interface. See the unit tests for an example. Basically, a | b means call a and b in parallel and a >> b means call a and then call b. Both a and b are callables. I.e., anything that can be invoked like a().

Some libraries like the lsystem library I deprecated simply because I lost interest.

There are also some containers like the darray and the svector. Both are very simply and use contiguous memory for storage. They have an STL-like interface complete with iterators (though no allocators). Without going into too much detail they make stricter usage assumptions than, say, std::vector which allows them to skip certain bound checks. I liked and used both the darray and the svector all over the place. They have been deprecated simply because it was too much of a hassle to maintain a fully conformant STL-like interface.

Both black_label and cave_demo use the CMake build system.

Your compiler must support subset of C++14/1z. The following compilers are known to work:

• Visual Studio 14 CTP3.
• Any recent release of Clang or GCC.

Don't re-invent the wheel. E.g., don't implement a thread_pool. Therefore, black_label relies on a lot of 3rd party libraries:

• Common dependencies
  • Boost
  • GLM
  • TBB
• Rendering dependencies
  • GLEW
  • OpenGL
  • SFML (graphics module)
    • Winmm (on Windows)
    • JPEG
    • Freetype
  • ASSIMP
    • ZLIB
  • FBX (optional)
  • OpenColorIO
    • TinyXML
    • YAMLCPP
  • GLI
  • Squish

Furthermore, the cave_demo depends on (besides black_label):

• Boost
  • program_options
  • log
  • log_setup
• SFML
  • system
  • window
  • CoreFoundation, Cocoa, IOKit, and Carbon (on OS X)
  • VTune (optional)