SFML is a simple, fast, cross-platform and object-oriented multimedia API. It provides access to windowing, graphics, audio and network. It is written in C++ and has bindings for various languages such as C, .Net, Ruby, Python.
This fork makes the rendering pipeline of the graphics module modular. The pipeline is split from its OpenGL implementation and placed behind a set of internal backend interfaces, and three additional renderers are implemented on top of them: Direct3D 11 on Windows, Metal on macOS, and Vulkan on Windows and Linux. OpenGL remains the default renderer on every platform; another renderer can be selected at runtime with sf::setRenderer before the first graphics resource is created. The Vulkan renderer requires a driver supporting Vulkan 1.2 and is only listed by sf::getAvailableRenderers on systems that have one; it is programmed in the same HLSL dialect as the Direct3D 11 renderer, consumed as SPIR-V bytecode compiled offline with dxc, or as HLSL source text when SFML is built with SFML_VULKAN_RUNTIME_SHADER_COMPILER enabled.
Although the additional renderers are built on this abstraction, supporting user-provided/hot-swappable rendering backends is not the goal. The goal is to make the existing pipeline customizable: for example, a custom render target can now be written without dealing with the rendering implementation directly, where previously sf::RenderTarget was tightly coupled to OpenGL states. This is useful when you have to deal with vertices but in high-level context, such as implementing sprite batching.
The changes to the public API are kept non-intrusive, so existing projects can use this fork without any modification. In turn, the semantics change in some places behind the scenes. For example, the Direct3D 11 and Metal renderers defer and batch draws internally to accommodate the immediate drawing style of the SFML API, since issuing every draw immediately through these APIs would hurt performance. The OpenGL renderer is unchanged in this regard: calling draw there still issues exactly one draw call immediately, as it always has. Where the difference would be observable, the original semantics are maintained instead. For example, clearing with a scissored view only clears the scissor rectangle on every renderer, like it does on OpenGL.
Mixing SFML rendering with raw graphics API calls remains supported on every renderer. Just like the original SFML allows raw OpenGL calls alongside its own drawing, the sf::OpenGL, sf::D3D11, sf::Metal and sf::Vulkan namespaces expose the underlying device and resources of the active renderer, so raw Direct3D 11, Metal and Vulkan code can be mixed into an SFML frame the same way raw OpenGL always could. The opengl, direct3d, metal and vulkan examples demonstrate this. (sf::Vulkan spans two headers: the window module part for writing your own Vulkan renderer on top of sf::Window, and the graphics module part in SFML/Graphics/VulkanInterop.hpp for interoperating with the Vulkan renderer of the graphics module.)
Development of this fork takes place in the graphics/modular branch.
- stb_image and stb_image_write are public domain
- freetype is under the FreeType license or the GPL license
- libogg is under the BSD license
- libvorbis is under the BSD license
- libflac is under the BSD license
- dr_mp3 is public domain or under the MIT No Attribution license
- miniaudio is public domain or under the MIT No Attribution license
- cpp-unicodelib is under the MIT license
- HarfBuzz is under the Old MIT license
- SheenBidi is under the Apache license
- qoi is under the MIT license
- Mbed TLS is under the Apache license or the GPL license
- wepoll is under the BSD license
- libssh2 is under the BSD license