/cute_headers

Collection of cross-platform one-file C/C++ libraries with no dependencies, primarily used for games

Primary LanguageC

cute_headers

Various single-file cross-platform C/C++ headers implementing self-contained libraries.

library description latest version language(s)
cute_c2 2D collision detection routines on primitives, boolean results and/or manifold generation, shape cast/sweep test, raycasts 1.05 C/C++
cute_coroutine Implementation of Duff's device for cooperative style programming - useful for state machines and "linear" style coding 1.0 C/C++
cute_sound Load/play/loop/pitch/pan WAV + OGG (stb_vorbis wrapper for OGG) in mono/stereo, high performance custom mixer, decent performance custom pitch shifter (does not stretch time) 1.09 C/C++
cute_net * Netcode for multiplayer games, reliable/unreliable packets, send/recieve large chunks reliably, encryption, network simulator, flow control, serialization + data integrity checks, compression 0.0 C/C++
cute_time Quick and dirty "main loop" timer function, along with utilities for integer-based high resolution timing 1.0 C/C++
cute_memfile Utility for calling fscanf-alike functions on files embedded in memory 1.0 C++
cute_files Directory traversal, both recursive and manual 1.0 C/C++
cute_sid Compile time string hashing via preprocessing; turns strings into integers 1.0 C/C++
cute_math Professional level 3D vector math via SSE intrinsics 1.02 C++
cute_png load/save PNG, texture atlas compiler, DEFLATE compliant decompressor 1.03 C/C++
cute_gl OpenGL 3.2 wrapper with carefully designed API to foster fast iteration 1.02 C/C++
cute_utf utf-8 and utf-16 encoder/decoder 1.0 C/C++
cute_huff minimal static huffman encoder/decoder (compression) 1.0 C/C++
cute_spheremesh Generates beautiful vertices (triangles) of a sphere 1.0 C/C++
cute_path c-string utility functions for Shlwapi.h style path manipulation 1.01 C/C++
cute_alloc straight-forward but useful allocator collection 1.01 C/C++
cute_math2d 2d vector math and shape routines 1.0 C++
cute_spritebatch Run-time 2d sprite batcher. Builds atlases on-the-fly in-memory. Useful to implement a sprite batcher for any purpose (like 2D games) for high-performance rendering, without the need to precompile texture atlases on-disk. 1.02 C/C++
cute_tiled Very efficient loader for Tiled maps exported to JSON format 1.03 C/C++
cute_filewatch Directory watcher wrapping assetsys.h, for virtual file paths and zip mounting 1.01 C/C++
cute_ani lower level bits of frame based looping animations 1.0 C/C++
cute_font Load font atlases, and fill vertex buffers for rasterized fonts, word wrapping, CPU-side clipping, kerning 1.01 C/C++
cute_sync Collection of practical syncronization primitives, including read/write lock and threadpool/task system 1.0 C/C++
cute_serialize Binary serialization utility focused around building polymorphic routines. Don't-Repeat-Yourself (DRY) style for to/from disk, or to/from in-memory buffer. 1.03 C/C++

* Not yet hit first release

How to Use

Generally these headers do not have dependencies and are intended to be included directly into your source (check each header for specific documentation at the top of the file). Each header has a LIBNAME_IMPLEMENTATION symbol; add this to a single translation unit in your code and include the header right after in order to define library symbols. Just include the header as normal otherwise.

Examples and Tests

Some headers also have example code or demos. In this repo just look for the corresponding examples or tests folders. The example folders are particularly useful for figuring out how to use a particular header.

Contact

Here's a link to the discord chat for cute_headers. Feel free to pop in and ask questions, make suggestions, or have a discussion. If anyone has used cute_headers it would be great to hear your experience! https://discord.gg/2DFHRmX

Another easy way to get a hold of me is on twitter @randypgaul.

FAQ

  • What's the point of making a single file? Why is there implementation and static functions in the headers?

Including these headers is like including a normal header. However, to define the implementation each header looks something like this:

#define LIBNAME_IMPLEMENTATION
#include "libname.h"

This will turn the file into a header + c file combo, one time. The point of this is: A) handling the header or sending it to people is easy, no zip files or anything just copy and paste a single file; B) build scripts are a pain in the ass, and these single-file libs can be integrated into any project without modifying a single build script.

  • Doesn't writing all the code in a header ruin compile times?

The stigma that header implementations slow compile time come from inline'd code and template spam. In either case every single translation unit must churn through the header and place inline versions of functions, or for templates generate various type-specific functions. It gets worse once the linker kicks in and needs to coalesce translation units together, deleting duplicated symbols. Often linkers are single-threaded tasks and can really bottleneck build times.

A well constructed single-file header will not use any templates and make use of inline sparingly. Additionally well constructed single-file headers use a #define to place implementation (the function definitions and symbols) into a single translation unit. In this way a well crafted single-file header is pretty much the best thing a C compiler can come across, as far as build times go. Especially when the header can optionally #define out unneeded features.

  • Aren't these header only libraries just a new fad?

I personally don't really know if it's a fad or not, but these files aren't really just headers. They are headers with the .C file part (the implementation) attached to the end. It's two different files stuck together with the C preprocessor, but the implementation part never shows up unless the user does #define LIB_IMPLEMENTATION. This define step is the only integration step required to use these headers.

Unfortunately writing a good header library is pretty hard, so just any random header lib out there in the wild is probably not a good one. The STB and RJM are pretty good header libs, and are a good reference to get an idea at what a good header lib looks like. Mattias Gustavsson has my favorite collection of headers. miniz is a little odd in the repository, but the releases are packed into a nice .c and .h combo -- a very useful library for creating wrapper libs!

  • What is the license?

Each lib contains license info at the end of the file. There is a choice between public domain, and zlib.