About the reference

The API reference gives the exact contract of every public type and function in the engine, generated from its headers at the revision named at the foot of each page. It is organised by module, in the order the modules depend on one another: each one depends only on modules above it in this table. Choose a module to browse its public headers. Each header page links back to its module, and every module has an Overview in the sidebar.

Module	What it is	Headers
math	Vectors, rectangles, shapes, intersection tests and 2D affine transforms. Depends on nothing.	16
core	Game objects, the state stack, handles and the tables that issue them, and the thread pool.	10
collision	Layers and masks, a broad phase, a narrow phase that measures contacts, and analytic resolution.	9
render	The renderer, draw lists, cameras and viewports, sprites, text, colours, and the files content arrives in.	34
scene	One object list, one collision sweep, and one per-view render fan-out.	1
input	Keyboard, mouse and four gamepads, with press edges, deadzones and menu directions.	6
audio	Sound banks and voices, behind the AudioDevice seam.	4
ui	Widgets, focus and directional navigation.	4
assets	The content manifest, the loader that walks it, and checked JSON.	6
app	The application shell: the window, the frame loop, and the services a game is handed.	3

If you are starting out, the pages you will use most are State, Scene, Application, Label, Keyboard and Gamepads. The Concepts and Guides pages explain how they fit together.

Some headers in render are there for whoever writes a renderer rather than for game code: the file readers, the sprite geometry, the vertex layout and the texture formats. They are published because they are public, and because the engine decides where every pixel goes in them, not in the graphics backend. The backends themselves, in render/d3d11/ and the folders beside it, are not API and are not published.

What the text on each page is

Each page is the header’s own comment, word for word, under the declaration it describes. A header comment in Labrador says one of two things: the contract a caller is held to (what is thrown and when, how long a pointer stays valid, which thread may call), or the rationale for the design (the alternative that was weighed and why it lost). Rationale usually cites one of the twelve trade-offs by number, and the number links to it. How the code came to be the way it is belongs in the version history, not in a comment (Conventions), so it is not here.

The prose is the engine author’s, written for someone reading the header in an editor, and it is denser than the guides. Where a sentence uses capitals for its first few words, that is the header’s way of giving a paragraph a heading.

How the pages are made

Each page is built when the site is built, from the header in the same checkout. A short reader, cpp-header.ts, takes the header’s declarations and the comments directly above them. A comment separated from the next declaration by a blank line is shown as a note of its own. Private members and the detail namespace are left out, and a function defined in the header is shown as its signature. Nothing is written by hand, so a page cannot disagree with its header.

The reader is not a C++ parser. It relies on the shape the conventions fix for every engine header: braces on their own lines, and a comment directly above what it describes. When it meets something it does not understand, it stops the site build and names the file and line, rather than publishing a page that might be wrong. Doxygen was considered and does not fit: it reads only comments in its own markers, such as ///, and Labrador’s are plain //. Clang would read the headers exactly, but application.h includes <Windows.h>, which would tie the site’s build to Windows.

Links. A type defined anywhere in the engine’s public headers is linked wherever a page names it, to its section on its page, and a qualified member such as GameObject::draw to the member’s own section. Free functions such as labrador::resolve_walls link to their declaration group; overloads in the same header share a destination. Header paths and trade-off numbers such as T8 also link to their definitions. The rest of the site links here the same way: a name written as code in a guide, a concept page or a design document links to its section, the first time each section of that page names it.

C++ code blocks, including quoted sample source, link the first occurrence of each API target in that block. Underlined names are keyboard-accessible links; syntax highlighting and copied code are unchanged. Comments and string literals are left as written.

Where it is used. Each page ends with the samples and tests that include its header. Only a direct #include is found, and a file can reach a header through another one, so the list is where to start reading rather than every use. The samples are the best examples; Examples says where to start reading them.

Linking boundaries

• A name defined in two headers is not linked at all, rather than risk landing on the wrong one.
• Links identify declarations, not the overload selected by a C++ compiler. Calls through an object and local aliases are not resolved; local shadowing is not inferred.
• An enumerator links to its enumeration: Key::w goes to Key.