Miniquad is a manifestation of a dream in a world where we do not need a deep dependencies tree and thousands lines of code to draw things with a computer.

Miniquad aims to provide a graphics abstraction that works the same way on any platform with a GPU, being as light weight as possible while covering as many machines as possible.

• Windows, OpenGL 3, OpenGL 2.2;
• Linux, OpenGL 2.2, OpenGL 3, GLES 2, GLES 3;
• macOS, OpenGL 3, Metal;
• iOS, GLES 2, GLES 3, Metal;
• WASM, WebGL 1 - tested on iOS Safari, Firefox, Chrome;
• Android, GLES 2, GLES 3; optional WGPU through Vulkan or GLES.

Enable the wgpu Cargo feature to use Miniquad's WGPU renderer. Desktop builds use the winit window path. Android keeps Miniquad's Java/JNI runner and supplies the current native Surface to WGPU; WgpuBackend::Auto tries Vulkan first, then GLES. Selecting WgpuBackend::Vulkan or WgpuBackend::Gles forces that backend, and failure does not fall back to Miniquad OpenGL.

Miniquad builds without wgpu retain the Rust 1.70 minimum supported version. Enabling wgpu uses wgpu 30.0.1 and requires Rust 1.87 or newer. On OHOS, select GfxApi::Wgpu to render into the retained OHNativeWindow provided by XComponent. WgpuBackend::Auto tries Vulkan, then GLES, without starting winit. ArkTS calls setAppActive(boolean) on visibility changes; rendering stops in the background and resumes with a recreated WGPU surface. XComponent destruction waits for the renderer to release the surface before its native window is released. GfxApi::OpenGl remains available. The vendored wgpu-hal 30.0.1 patch adds VK_OHOS_surface and vkCreateSurfaceOHOS, so WgpuBackend::Vulkan can present to OHOS windows. Consumers must select vendor/wgpu-hal with a workspace-root [patch.crates-io] override; Cargo ignores patches in dependency manifests. See vendor/wgpu-hal/PHIGRIM_PATCH.md for provenance and tests. The application has been verified on a MatePad Pro (Maleoon 910) with Vulkan first-frame and same-process foreground recovery. Startup logs report the actual backend.

examples/quad.rs: web demo
examples/offscreen.rs: web demo

PonasKovas/miniquad-mandelbrot: web demo

cargo run --example quad

On NixOS Linux you can use shell.nix to start a development environment where Miniquad can be built and run.

# both MSVC and GNU target is supported:
rustup target add x86_64-pc-windows-msvc
# or
rustup target add x86_64-pc-windows-gnu

cargo run --example quad

rustup target add wasm32-unknown-unknown
cargo build --example quad --target wasm32-unknown-unknown

And then use the following .html to load .wasm:

<html lang="en">

<head>
    <meta charset="utf-8">
    <title>TITLE</title>
    <style>
        html,
        body,
        canvas {
            margin: 0px;
            padding: 0px;
            width: 100%;
            height: 100%;
            overflow: hidden;
            position: absolute;
            background: black;
            z-index: 0;
        }
    </style>
</head>

<body>
    <canvas id="glcanvas" tabindex='1'></canvas>
    <!-- Minified and statically hosted version of https://github.com/not-fl3/miniquad/blob/master/native/sapp-wasm/js/gl.js -->
    <script src="https://not-fl3.github.io/miniquad-samples/gl.js"></script>
    <script>load("quad.wasm");</script> <!-- Your compiled wasm file -->
</body>

</html>

One of the ways to server static .wasm and .html:

cargo install basic-http-server
basic-http-server .

Recommended way to build for android is using Docker.
miniquad uses slightly modifed version of cargo-apk

docker run --rm -v $(pwd)":/root/src" -w /root/src notfl3/cargo-apk cargo quad-apk build --example quad

APK file will be in target/android-artifacts/(debug|release)/apk

With "log-impl" enabled all log calls will be forwarded to adb console. No code modifications for Android required, everything should just works.

To run on the simulator:

mkdir MyGame.app
cargo build --target x86_64-apple-ios --release
cp target/release/mygame MyGame.app
# only if the game have any assets
cp -r assets MyGame.app
cat > MyGame.app/Info.plist << EOF
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>CFBundleExecutable</key>
<string>mygame</string>
<key>CFBundleIdentifier</key>
<string>com.mygame</string>
<key>CFBundleName</key>
<string>mygame</string>
<key>CFBundleVersion</key>
<string>1</string>
<key>CFBundleShortVersionString</key>
<string>1.0</string>
</dict>
</plist>
EOF

xcrun simctl install booted MyGame.app/
xcrun simctl launch booted com.mygame

For details and instructions on provisioning for real iphone, check https://macroquad.rs/articles/ios/

# windows target from linux host:
# this is how windows builds are tested from linux machine:
rustup target add x86_64-pc-windows-gnu
cargo run --example quad --target x86_64-pc-windows-gnu

• Fast compilation time. Right now it is ~5s from "cargo clean" for both desktop and web.

• Cross platform. Amount of platform specific user code required should be kept as little as possible.

• Low-end devices support.

• Hackability. Working on your own game, highly probable some hardware incompability will be found. Working around that kind of bugs should be easy, implementation details should not be hidden under layers of abstraction.

• Forkability. Each platform implementation is, usually, just one pure Rust file. And this file is very copy-paste friendly - it doesnt use any miniquad specific abstractions. It is very easy to just copy some part of miniquad's platform implementation and use it standalone.

• Ultimate type safety. Library should be entirely safe in Rust's definition of safe - no UB or memory unsafety. But correct GPU state is not type guaranteed. Feel free to provide safety abstraction in the user code then!

• High-end API, like Vulkan/DirectX 12. Take a look on gfx-rs or vulkano instead!

Miniquad is supported by:

SourceGear