# Cute Framework: a small C and C++ foundation for 2D and 3D games

> Cute Framework is a portable foundational layer for building games in C and C++, aimed at people who want a window, an input layer and a renderer without the dependency weight of a larger engine. The README describes it as baggage free and it is built from source with CMake, with a project template that gets you to a running window in five steps.

**RandyGaul/cute_framework** — The *cutest* framework out there for creating 2D and 3D games in C++!

- Repository: https://github.com/RandyGaul/cute_framework
- Website: https://randygaul.github.io/cute_framework/
- Stars: 853 · Forks: 48
- Language: C
- License: NOASSERTION
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/randygaul-cute-framework

## A foundational layer rather than an engine

Cute Framework describes itself as a portable foundational layer for building games in C and C++, without baggage, gnarly dependencies or cryptic APIs, and the README says it runs almost anywhere: Windows, macOS, iOS, Android, Linux and browsers.

The word foundational is the one to hold on to. This is not an engine with a scene editor, an asset pipeline and a scripting language. It is a layer that gives you the things every game needs and nothing else: a window, an input model, a draw path, and the platform glue to make them work the same way on different systems.

That framing determines who benefits. Someone who wants to understand how a frame is put together, or who wants to avoid an engine's abstractions, gets a codebase small enough to read. Someone who wants a complete production pipeline with an editor and content tools should look elsewhere, because the framework is not trying to be that.

The author also asks for something from users: if you want to add a new feature, open an issue first to discuss the proposal, so that effort is not spent on a pull request before there is feedback. Bug fixes, new sample code and documentation edits are the listed contribution paths, and for bug fixes the request is to match the existing code style and to explain the reasoning.

The documentation site is the place to start reading, with topics and tutorials, an API reference, a samples directory in the repository, and a page of projects made with the framework.

## Reading the API through the window example

The README leads with the smallest useful program, and it is worth reading line by line because it sets the tone of the whole API.

```cpp
#include <cute.h>
using namespace Cute;

int main(int argc, char* argv[])
{
	// Create a window with a resolution of 640 x 480.
	CF_Result result = make_app("Fancy Window Title", 0, 0, 0, 640, 480, CF_APP_OPTIONS_WINDOW_POS_CENTERED_BIT, argv[0]);
	if (is_error(result)) return -1;

	while (app_is_running())
	{
		app_update();
		// All your game logic and updates go here...
		app_draw_onto_screen();
	}

	destroy_app();

	return 0;
}
```

Everything comes through one header, cute.h, and the namespace is brought in with a using declaration. The application is created by make_app, which takes a title, four zero values for the window position and size context, the resolution, a bitfield of options for things like centring the window, and the program path.

The result is a CF_Result that you check with is_error, and the return code on failure is a plain -1. That is the error handling model in its entirety: a result value and a boolean test, with no exception mechanism and no error string parsing.

The loop is the shape every CF program has. app_is_running is the condition, app_update pumps the platform and your callbacks, and app_draw_onto_screen presents the frame. The comment marks where your game logic goes, which is a good sign about the amount of machinery between you and the pixels.

The naming convention is worth noting too, since it explains a lot of the surface: functions are lowercase with underscores, like app_update and app_draw_onto_screen, while types are prefixed in upper case, like CF_Result, and option bits carry a CF_APP_OPTIONS prefix. It is a consistent C style rather than a C++ one, which is why the samples directory contains both .c and .cpp files.

## Building from source with CMake and the template

Cute Framework is designed to be built from source, and you link your project against it as either a static or a shared library. The README is explicit that the documentation site holds the in-depth details.

CMake is the build system, and the README explains the choice plainly: it is one of the only working cross-platform build generators in existence and it works pretty much everywhere. The requirement is CMake 3.14 or higher, along with git, and the README suggests GitHub Desktop to Windows users who are new to git.

The recommended path is the project template, and the steps are short enough to repeat here.

You download and install CMake and git, then copy the CMakeLists.txt from the template into the top level of your project directory. You find and replace mygame with your game name, and the README is specific that no underscores, spaces or special characters are allowed in the name. You create a src folder in the top level and put your initial main.cpp in it. Then you run CMake on the project folder.

Compiler recommendations are given by platform. For Windows the README suggests Visual Studio Community Edition, or gcc and g++ through MinGW, with tdm-gcc named as the recommended choice, and w64devkit as an option for older systems such as Windows 8. On macOS it recommends Xcode with the command line tools, and on Linux g++.

The repository itself is set up for the same system, with a top level CMakeLists.txt, a cmake directory of helpers, a src directory, an include directory, a libraries directory, tools, tests and documentation built with mkdocs, plus samples.

## Linux packages, Vulkan and the WSL2 footnote

The Linux path is where the README gets specific, and the list is a useful inventory of what the framework actually needs from the operating system.

```cpp
sudo apt-get update -qq
sudo apt-get install build-essential gcc-multilib cmake
sudo apt-get install libasound2-dev libpulse-dev
sudo apt-get install -y --no-install-recommends libvulkan-dev libx11-dev libxcursor-dev libxrandr-dev libxinerama-dev libxi-dev libxext-dev libxfixes-dev
```

The groups map onto the subsystems. Build tools and the multilib compiler packages are the toolchain, CMake is the build system, the ALSA and PulseAudio development packages are for audio, and the Vulkan and X11 family packages are for graphics and windowing.

Two details stand out. Vulkan is a dependency in its own right rather than an optional extra, which tells you something about the renderer path the framework takes on desktop. And the X11 packages are listed individually, cursor, randr, xinerama, xi, xext and xfixes, which is the set a windowing layer needs for cursor handling, screen enumeration, input devices and compositing.

The README adds one note for WSL2 users, that they may also need the PulseAudio runtime package installed, which is the kind of detail that only appears in a project with users on that specific setup.

The repository also carries platform specific convenience commands at the root, msvc2026.cmd and web.cmd, which suggests first class handling for the Visual Studio toolset and for the browser target.

## The samples directory as the real documentation

The samples folder is where this framework explains itself, and the file listing in the repository gives a better sense of its scope than the README does.

There are basic samples for input, sprites, shapes, indexed rendering, instancing, cameras and serialisation, and a basic entity component system sample. There are graphics samples for blend modes, canvas modes, canvas readback, cel shading, billboards and nine slice. There are samples using the Clay layout library, with its own UI animation sample, a compute shader sample, and a sample named crashme that suggests the author tests failure paths.

The sample set covers both languages, with .c files such as basic_input.c and 9_slice.c sitting next to .cpp files such as basic_shapes.cpp, basic_ecs.cpp and custom_shapes.cpp.

Adding a sample is a two step process, and the README describes it exactly. You copy and paste an existing sample to start, then hook it into the build with the samples CMakeLists file.

```cmake
...
add_sample(waves waves.cpp)
add_sample(shallow_water shallow_water.cpp)
add_sample(noise noise.c)
add_sample(new_sample new_sample.c)
```

If the sample needs files on disk, such as image or audio assets, you create a folder in the samples directory named new_sample_data, following the new_sample name, and add a custom command so the assets are copied into the build folder. The listing shows that convention already in use, with directories such as 9_slice_data and custom_sprite_data.

## Licence, releases and what to check first

The repository carries a LICENSE file at the root, and the licence classification in the repository metadata is not one GitHub can categorise, so read the file itself before shipping anything built on the framework.

On maintenance, the release tags are 1.1.1 from 2026-02-04, 1.1.0 from 2025-03-04 and 1.0.1 from 2024-08-18, and the last push to the repository was on 2026-10-19. The version is still in the 1.x range, which in a framework of this kind is a signal that the API may still move.

The repository has grown a modern accessory set alongside the code: an AGENTS.md file, a .claude directory, a GitHub workflow for the build, and a docs directory that is published with mkdocs.

Where the framework fits against the alternatives is a question of appetite. A larger engine gives you an editor, an asset pipeline, a scene format and a scripting language, and takes a large dependency chain and a large build in exchange. Cute Framework gives you a window and a draw path, keeps the dependency list to system libraries, and leaves the rest to you.

So the checks to make before committing are concrete. Read the sample closest to the thing you are building, because that is where the honest answer about what the framework covers lives. Confirm your platform is supported, since the README lists Windows, macOS, iOS, Android, Linux and browsers. On Linux, install the packages listed above before you start rather than after the first linker error. And if you are shipping, read the LICENSE file rather than assuming from the badge.

## Conclusion

Cute Framework is the right choice for a developer who wants to write a game in C or C++ without adopting a full engine, for a jam entry with a week of deadline, or for a team that wants to understand the rendering path rather than inherit it, because the samples and the API are small enough to read in an afternoon. It is the wrong choice for a project that needs a large asset pipeline, a scene editor, or a console porting programme, and it is the wrong choice if you want a managed scripting layer. Verify first that your platform is in the supported list, install the Linux Vulkan and audio development packages the README lists before you start, and read the sample that is closest to what you are building so you can see how far the framework actually goes.

## FAQ

### What is Cute Framework?

Cute Framework is a portable foundational layer for building 2D and 3D games in C and C++, without baggage, gnarly dependencies or cryptic APIs, and the README says it runs on Windows, macOS, iOS, Android, Linux and browsers.

### How do I build Cute Framework?

It is designed to be built from source with CMake, version 3.14 or higher, and the README recommends the Cute Framework CMake project template: copy its CMakeLists.txt into your project, replace mygame with your game name, put main.cpp in a src folder and run CMake.

### What does the minimum Cute Framework program look like?

It creates a window with make_app, checks the CF_Result with is_error, then loops while app_is_running calling app_update and app_draw_onto_screen, and finishes with destroy_app.

### How do I add a new sample to Cute Framework?

Copy an existing sample, then add a line such as add_sample(new_sample new_sample.c) to the samples CMakeLists.txt file, and create a new_sample_data folder in the samples directory if the sample needs asset files.

## Sources

- [Issues](https://github.com/RandyGaul/cute_framework/issues)
- [Project website](https://randygaul.github.io/cute_framework/)
- [RandyGaul/cute_framework on GitHub](https://github.com/RandyGaul/cute_framework)
- [README](https://github.com/RandyGaul/cute_framework/blob/master/README.md)
- [Releases](https://github.com/RandyGaul/cute_framework/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/randygaul-cute-framework