It asked whether either rectangle enclosed one of the other's four corners -- eight akgl_collide_point_rectangle calls, stopping at the first hit. That is a different question from "do these overlap", and it has the wrong answer for one arrangement: a tall thin rectangle crossing a short wide one overlaps in a plus sign with no corner of either inside the other, and all eight tests said no. A long thin platform crossing a tall thin character is exactly that shape, so this is a shape a 2D game produces, not a curiosity. util.h carried an @note describing it and docs/18-utilities.md had a diagram of it, both under the heading of a limitation rather than a defect, and there was no test for it at all -- nor for full containment, nor for a shared edge. It is four comparisons now, on both axes. `<=` rather than `<` because akgl_collide_point_rectangle is inclusive on all four edges and these two have always agreed that touching counts; a span test written with `<` would have silently changed a contract both the header and the manual state. The test was written first and failed on the cross before the fix went in. Two answers change for a caller upgrading, and both are in the header note and the chapter: - The cross reports `true`, which is the point. - The comparison is in float rather than through akgl_Point's int members, so a sub-pixel overlap is no longer truncated away. A pickup test that was accidentally forgiving by up to a pixel is no longer forgiving. Both tutorials use this for coins and hazards; both still pass. Faster as a side effect rather than a goal, and worth recording because the numbers move a documented budget: 24.9 ns -> 6.1 overlapping, 57.9 -> 6.1 disjoint, and the all-pairs sweep over 64 actors 115 us -> 12.2. The disjoint case gained most because it was the one that ran all eight tests before answering. The three moved rows are re-recorded in PERFORMANCE.md and nothing else is. akgl_rectangle_points is untouched by this change and reads 6.1 in the same run against the 4.0 recorded, so 6 ns is this run's floor and the new figure means "too cheap to measure" rather than "exactly 6.1" -- said in the prose so the next reader does not re-baseline the table around it. Co-Authored-By: Claude Code <noreply@anthropic.com> Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The libakgl manual
libakgl is a C library for building 2D games on SDL3. It is not an engine: there is no
editor, no scripting layer, no inheritance and no runtime malloc. Behaviour attaches to a
struct as function pointers, objects come from fixed pools, and every call reports failure
through an error context you cannot silently ignore.
This manual teaches the library. It deliberately does not re-document its dependencies
— libakerror owns the error-handling protocol, SDL3 owns renderers and events, Tiled owns
the map format, jansson owns the JSON API. Each chapter says what libakgl adds or
constrains, shows what a caller actually writes, and links out for the rest. For
per-function reference, build the Doxygen output with doxygen Doxyfile.
| 1. Introduction | What libakgl is, what it refuses to be, the frame budget, and who owns which documentation |
| 2. Design philosophy | Bounded pools, pluggable backends, bit flags, name-based registries, one world at a time |
| 3. Getting started | Dependencies, add_subdirectory vs akgl.pc, and the smallest program that opens a window |
| 4. Errors and status codes | The status tables, what each code means here, and the traps that fail silently |
| 5. The heap | The five pools, akgl_heap_next_*, akgl_String, and why exhaustion usually means a missing release |
| 6. The registry | The eight registries, configuration properties, and the id-0 silent no-op |
| 7. The game and the frame | Startup order, akgl_game_update, the state lock, iterators, savegames |
| 8. Rendering | The backend vtable, the frame contract, cameras, and embedding a host's own SDL_Renderer |
| 9. Drawing | Points, lines, rectangles, circles, flood fill, and saving a region |
| 10. Spritesheets and sprites | One texture shared by path, the sprite JSON format, frame animation |
| 11. Characters | State-to-sprite mappings, movement constants, the character JSON format |
| 12. Actors | The state bitmask, the six behaviour hooks, parents and children, layers |
| 13. Tilemaps | Tiled TMJ, libakgl's three extensions, and the limits that bind a map |
| 14. Physics | Thrust, environment and velocity; the null and arcade backends; what is not implemented |
| 15. Input | Control maps, push-not-poll dispatch, the keystroke ring, gamepads |
| 16. Text and fonts | Loading, drawing, measuring, and the teardown order that matters |
| 17. Audio | The three-voice synthesizer, and the separate background-music path |
| 18. Utilities | Collision helpers, path resolution, the JSON accessors, static strings |
| 19. Tutorial: a 2D sidescroller | Gravity, a jump, collision you write yourself, coins and hazards |
| 20. Tutorial: a top-down JRPG | A town map, NPCs spawned from map objects, four-way animation, a text box, a follower |
| 21. Appendix | Every limit, every status, every configuration property |
Both tutorials are complete programs under examples/. They build with the
library and run headless in CI, and the chapters quote them rather than restating them — so
a tutorial cannot drift from a program that compiles.
Every example here is checked
The examples in these chapters are compiled, linked, run, and cross-checked against the
source tree by the test suite. A snippet that stops compiling, an excerpt that no longer
matches the header it quotes, or a JSON document the loader would reject turns
ctest -R docs_examples red.
This exists because the documentation it replaces had drifted badly: the previous FAQ's
examples did not compile — two unbalanced PASS() calls, a sprite->frameids = [0, 1, 2, 3];
that is not C in any dialect, and, in the first snippet a reader ever saw, the exact
strncpy call AGENTS.md forbids. The prose had drifted with it, and writing these
chapters turned up twenty-seven header claims that were false against src/.
Where a chapter documents behaviour that is a known defect rather than a design decision,
it says so and points at TODO.md. See MAINTENANCE.md if you are editing an example.
Assets
The tutorial art, tiles and music are CC0, vendored under
tutorials/assets/ with provenance recorded per file in
PROVENANCE.md and geometry documented in
README.md. CC0 specifically, not merely free: a reader who
copies a tutorial into their own game inherits no obligation.