GameLib.h gives a C++ beginner a window, a game loop and a keyboard in one header

The install step is copying a file, and that is the whole pitch

GameLib is described as a single-header C++ game library for beginners, no SDL, no DirectX, no OpenGL, no setup, just include and play. The README is written in Chinese and its argument is about a specific kind of learner.

The pain it names is the gap between learning C++ and learning to program games. What hurts most when learning C++ is that for weeks you can only cout a line of text in a black console window. If you want to use SDL or SFML, the environment setup puts half of them off. The stated goal of GameLib is to remove that stretch of suffering: drop GameLib.h into the project folder, write an #include line, and ten lines of code draw a coloured circle you can move with the keyboard. Window, drawing, keyboard, mouse, sprites, sound and collision detection are all there, with no SDK to download, no paths to configure and no libraries to link.

The quick start is three steps. Download GameLib.h and put it in the project folder. Create main.cpp with the code above it. Compile and run, and the README's command for that is:

g++ main.cpp -o game.exe -mwindows

The point about the compile line is what follows it. No -lgdi32 or -lwinmm style link parameters are needed, all dependencies are dynamically loaded inside the library, and even -mwindows is optional, without it you just get a console window as well.

There is also a note for Dev C++ users, which is to create a project, add main.cpp, and compile and run. Dev C++ matters here because it is what many school programming courses use, and the library is explicitly designed for it, compatible with its bundled GCC 4.9.2 compiler, while any C++11 compiler works too.

The primary language is C++, the licence is MIT, the default branch is master, and the last push was on 2026-06-02. The recent releases are 1.9.9 from 2026-05-05, 1.9.8 from 2026-05-01 and 1.9.7 from 2026-04-21, with version numbers carrying the build date in the tag name.

The first program is twenty lines and shows the whole shape of the API

The complete example is worth reading because it is the entire API surface a beginner needs, and it is short enough to memorise.

#include "GameLib.h"

int main()
{
    GameLib game;
    game.Open(640, 480, "My Game", true);

    int x = 320, y = 240;

    while (!game.IsClosed()) {
        if (game.IsKeyDown(KEY_LEFT))  x -= 3;
        if (game.IsKeyDown(KEY_RIGHT)) x += 3;
        if (game.IsKeyDown(KEY_UP))    y -= 3;
        if (game.IsKeyDown(KEY_DOWN))  y += 3;

        game.Clear(COLOR_BLACK);
        game.FillCircle(x, y, 15, COLOR_CYAN);
        game.DrawText(10, 10, "Up/Down/Left/Right to move!", COLOR_WHITE);
        game.Update();
        game.WaitFrame(60);
    }
    return 0;
}

The structure is conventional. A GameLib object on the stack, an Open call that takes a width, a height, a title and a flag whose meaning the example does not spell out, and then a while loop that runs until IsClosed() returns true.

Inside the loop, the shape is: read input, draw, present, wait. IsKeyDown with a named constant is how input is polled, Clear with a named colour resets the frame, FillCircle and DrawText are the drawing calls, Update presents the frame, and WaitFrame(60) targets sixty frames per second.

Two design choices are visible here and both are deliberate. The constants are named rather than numeric, so KEY_LEFT and COLOR_CYAN teach the vocabulary as you read. And the game state, the x and y integers, lives in your main function rather than inside the library, so you can see that the library draws what you tell it and nothing more. There is no scene graph, no entity list and no retained mode. The library is a pen and a keyboard, and the program is the program.

That restraint is the pedagogical argument. There is no hidden state to learn, so the difference between the working example and your own code is entirely in the code you write.

What the feature list actually covers

The feature list is long for a beginner library, and each entry is a thing a course project tends to need.

Zero configuration is the headline, a single header file copied in and used, with nothing to install or link, compatible with GCC 4.9.2 and Dev C++. Drawing comes out of the box: points, lines, rectangles, circles, ellipses and triangles with both stroke and fill, a built-in 8x8 pixel font, plus scalable fonts and UTF-8 support.

The sprite system uses integer IDs so there are no pointers to manage and nothing to release, and it loads PNG, JPG and BMP with frame animation, flipping, scaling, rotation and alpha blending.

Input covers held, pressed and released key detection, three mouse buttons plus the wheel, and pausing when the window loses focus, which is the detail that stops a key from sticking when you alt-tab away.

Sound is WAV effects plus MP3 and MIDI background music on independent channels that do not interfere with each other. Collision detection covers rectangle overlap, circle collision and point-to-point distance. The tilemap has two layers, parallax scrolling, and renders only the visible region, with save and load in a .glm data file.

Then the convenience features that make small games finishable. Resizable windows stretch automatically and mouse coordinates map back to logical coordinates. Scene management uses integer identifiers so a switch statement is enough to move between a menu, the game and a results screen. Save and load are one line each with functions like SaveInt and LoadInt in a plain text key=value format. And there are UI controls, Button, Checkbox, RadioBox and ToggleButton, in immediate mode with no dependencies.

Cross-platform is the separate header GameLib.SDL.h, an SDL2 version supporting Linux, macOS and the web, documented in SDL2PORT.md. The top-level entries confirm the two product lines, with GameLib.h and GameLib.SDL.h sitting side by side, plus the assets, docs, examples and tests directories.

Fifteen examples, grouped by what they teach

The examples directory is the curriculum, and the README groups the fifteen programs by topic rather than numbering them arbitrarily. Each example is compatible with both the Win32 and the SDL product lines, which is a useful constraint because it means the examples double as documentation for the port.

The first group is the basics. 01_hello.cpp is Hello World and covers the game loop, window creation and text drawing. 02_movement.cpp is keyboard movement plus a bouncing ball, covering keyboard input, GetDeltaTime and wall bouncing. 03_shapes.cpp shows every drawing call, with the stroked and filled versions of lines, rectangles, circles, ellipses and triangles. 04_paint.cpp is a simple paint program, with mouse input, wheel-controlled brush size and pause on focus loss.

The second group is sprites and sound. 05_sprites.cpp covers sprite basics plus frame animation, with CreateSprite and directional animation. 06_sound.cpp demonstrates PlayBeep, PlayWAV and PlayMusic. 07_shooting.cpp is a simple shooter, with bullet spawning and collision-driven destruction.

The third group is complete small games. 08_breakout.cpp is breakout, covering collision detection and managing many objects, and 09_snake.cpp is snake, with DrawGrid and FillCell plus a state machine.

The fourth group is tilemaps and text. 10_tilemap.cpp is a two-layer parallax scroller. 11_font_text.cpp covers scalable fonts and UI, with DrawTextFont and ShowMessage.

The last group is the advanced features. 12_sprite_transform.cpp scales and rotates sprites with DrawSpriteScaled and DrawSpriteRotated. 13_clip_rect.cpp demonstrates clipping with SetClip and ClearClip. 14_space_shooter.cpp is a space shooter described as a comprehensive exercise. And 15_ui_controls.cpp demonstrates the Button, Checkbox and RadioBox controls.

Building any of them is one command:

g++ -o 03_shapes.exe examples/03_shapes.cpp -mwindows

The naming convention is itself part of the pedagogy. Every file name states the topic, the numbers give a reading order, and the two digit prefix with a separator sorts correctly in a file listing.

Where GameLib is the wrong choice

Three limits, and the first is about what the zero-dependency approach costs.

The first is that the primary backend is the Win32 API. The library dynamically loads GDI and WinMM at runtime, which is what removes the link parameters, and it means the Win32 line is the one that gets the full feature set and the best-tested path. The SDL2 header is a port, documented separately, and the README describes the SDL version as needing SDL2 and optional extensions. For a learner on Windows that is the ideal arrangement. For a team shipping on Linux or the web, you are on the port rather than the main line, and the examples being compatible with both is a claim worth testing rather than assuming.

The second is the performance ceiling of a design optimised for clarity. The examples are a bouncing ball, a paint program, breakout and snake, and the library gives you immediate-mode drawing with no retained scene, no batching and no GPU path in the Win32 line. That is entirely the right trade for the stated audience and entirely the wrong trade for a game with thousands of sprites. The library will not stop you from writing that game, but it will not help either.

The third is the maintenance question of a single-header library. The whole project lives in one file that you copy into your project, which means every fix requires you to replace the header, and the version has to be tracked by whoever compiled your build. There is no package manager story, no version constraint in your build file and no way for the toolchain to tell you that a fixed version exists. For a course exercise, copying a file is a feature. For a project that lasts a year, it is a maintenance tax.

The alternative approach for anything beyond teaching is one of the libraries the README names. SDL requires configuring header paths and linking a dozen DLLs and is complex to use. SFML requires CMake. And raylib requires understanding linear algebra, three-dimensional basics and fluent C or C++, plus compiling and installing it. That list is the argument for GameLib, and it holds: for someone whose first language is C++ and whose goal is a bouncing ball by Friday, those three setup requirements are the barrier.

So the honest framing is that GameLib is not trying to beat SDL or raylib at games. It is trying to get a beginner to the first line of game logic before the setup problems decide for them that programming is not for them, and the fifteen examples plus the ten-line first program are the argument that it succeeds at that. Once someone has written a game, the next step is a real engine, and the README's own resource links for sprites, music and pixel art are the handoff to a more serious setup.

Editorial conclusion

Adopt GameLib if you are teaching C++ to people who have never written a game and need the smallest possible gap between a first line of code and a moving character, because the install step is copying one header into the project folder and the first program is twenty lines. Do not adopt it for a commercial game, because the zero-dependency approach means the Win32 line is the primary target and the SDL2 port is the secondary one, and the API is designed for clarity rather than for performance headroom. Verify first that your compiler meets the stated requirements, C++11 with GCC 4.9 or newer, MSVC 2015 or newer, or Clang, that you are on the Win32 line or the SDL2 line and know which, since they are separate headers with different backends, and that the licence position is acceptable, since the project is MIT and the README simply says use it freely.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. skywind3000/GameLib on GitHub