libdonut  2.3.2
Application framework for cross-platform game development in C++20
API Reference for libdonut

Libdonut is an application framework for cross-platform game development in C++20.

Getting started

The source code for libdonut can be found on GitHub. See the included README.md file for instructions on how to configure and build a new application project.

Examples

Libdonut includes example code in the examples/ directory that can serve as a reference for how various features of the library work and are intended to be used. All examples use the included examples/data/ folder as their main resource directory for any associated assets that need to be loaded at runtime. The main examples are:

Main modules

The main API of libdonut is organized into the following modules, listed along with a summary of their most important components:

  • donut::application - Application framework module
  • donut::audio - Audio engine module
    • Sound - Sound wave loading
    • SoundStage - Sound playback in 3D to the default audio device
  • donut::events - Events module
    • EventPump - On-demand polling of events and user input from the host environment
    • InputManager - Mapping between physical inputs and abstract output numbers
  • donut::graphics - Graphics rendering module
    • Camera - Perspective to render from
    • Font - Font loading for text rendering
    • Framebuffer - Render target on the GPU
    • Image - Image loading/saving
    • Renderer - Rendering onto a framebuffer
    • RenderPass - Graphics drawing queue for batch rendering
    • Model - Loading of 3D models
    • Shader2D - Shader program for instanced 2D textured quads
    • Shader3D - Shader program for instanced 3D models
    • SpriteAtlas - Packing of sprites into an expandable spritesheet
    • Text - Text shaping facility
    • Texture - Texture data stored on the GPU
    • Viewport - Rectangular region of a framebuffer
    • Window - Graphical window that can be rendered to

Utility modules

Libdonut also includes the following utility APIs which encompass all of the main modules:

Includes

For ease of use, libdonut provides the following header files which include collections of headers from each respective module:

Alternatively, all modules can be included as follows:

Aliases

In addition, for applications where the potential naming conflicts are not a problem, the following include can be used to provide short, global aliases for the libdonut API:

These aliases include global declarations for all types that are defined directly in the donut namespace, such as Color for donut::Color, as well as the following namespace aliases:

namespace app = donut::application;
namespace audio = donut::audio;
namespace events = donut::events;
namespace gfx = donut::graphics;
namespace base64 = donut::base64;
namespace json = donut::json;
namespace numbers = donut::numbers;
namespace obj = donut::obj;
namespace rng = donut::random;
namespace unicode = donut::unicode;
namespace xml = donut::xml;
Definition: Application.hpp:9
Definition: Error.hpp:8
Definition: base64.hpp:7
Definition: Error.hpp:7
Definition: Buffer.hpp:7
Definition: json.hpp:36
Definition: math.hpp:18
Definition: utilities.hpp:114
Definition: utilities.hpp:135
Definition: utilities.hpp:142
Definition: utilities.hpp:165
Definition: utilities.hpp:182

Conventions

Except where the documentation specifies otherwise, the API uses the following conventions by default:

  • The documentation uses the word "must" to specify that failure to meet a condition results in undefined behavior.
  • The "detail" namespace is used for private implementation details which should not be used directly.
  • Functions provide the basic exception guarantee, meaning that objects are left in a valid but unspecified state with all invariants preserved and no resources leaked.
  • Any function that is not marked noexcept may be extended to throw any exception type in a future version of the library.
  • Pointers, views and references returned from a member function are tied to the lifetime of the object on which the function was called.
  • Non-nullptr pointers, views and references passed to a function, either directly or as part of an object, must remain valid until the function returns.
  • When multiple pointers, views or references are passed to a function, they may not alias each other, nor reference overlapping memory regions.
  • Operations which mutate the state of an object are not thread-safe unless otherwise noted, and require exclusive access to the object until the operation has finished.
  • Functions defined in the donut::graphics module may only be called inside the main thread of the program.
  • Types defined in the donut::graphics module may only be instantiated, referenced and destroyed inside the main thread of the program.
  • World coordinates and physical quantities are expressed in SI units.
  • Graphics and linear algebra operations follow OpenGL conventions, such as normalized texture and clip space coordinates and a right-handed coordinate system with Y up.