#graphics #3D #opengl #gamedev #windowing

miniquad

Cross-platform window context and rendering library

71 releases

0.3.0-alpha.13 Sep 6, 2020
0.3.0-alpha.12 Jul 27, 2020
0.3.0-alpha.10 Jun 19, 2020
0.2.53 Mar 31, 2020

#2 in #3d

Download history 278/week @ 2020-06-09 135/week @ 2020-06-16 103/week @ 2020-06-23 210/week @ 2020-06-30 218/week @ 2020-07-07 289/week @ 2020-07-14 274/week @ 2020-07-21 161/week @ 2020-07-28 201/week @ 2020-08-04 562/week @ 2020-08-11 860/week @ 2020-08-18 523/week @ 2020-08-25 303/week @ 2020-09-01 294/week @ 2020-09-08 185/week @ 2020-09-15 194/week @ 2020-09-22

1,405 downloads per month
Used in less than 6 crates

MIT/Apache

1.5MB
51K SLoC

Miniquad

Github Actions Crates.io version Discord chat Matrix

Miniquad is safe and cross-platform rendering library focused on portability and low-end platforms support

API is highly inspired by sokol-gfx (sokol overview, 2019 update). Implementation influenced by crayon.

For context management and input on Windows/Linux(and potentially mobiles) "sokol-app" was used. And no external dependencies for WASM.

For higher level API take a look on:

good-web-game: implementation of some ggez subset on top of miniquad, made as compatibility layer to run ggez games on wasm

macroquad: raylib-like library on top of miniquad. 100loc arkanoid with macroquad

Supported platforms

  • Windows, OpenGl 3
  • Linux, OpenGl 3
  • macOS, OpenGL 3
  • iOS, GLES 3
  • WASM, WebGl1 - tested on ios safari, ff, chrome
  • Android, GLES3

Not supported, but desirable platforms

  • Android, GLES2 - work in progress.
  • Metal. For both MacOs and IOS metal rendering backend next to opengl one is highly desirable. But I just dont have any MacOs capable hardware to start working on it :/

Examples

Imgur

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

PonasKovas/miniquad-mandelbrot: web demo

Worth to mention zemeroth port and astroblasto, built with miniquad-powered good-web-game

Building examples

linux

# ubuntu system dependencies
apt install libx11-dev libxi-dev libgl1-mesa-dev

cargo run --example quad

windows

# 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

wasm

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

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

index.html
<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 .

android

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

docker run --rm -v $(pwd)":/root/src" -w /root/src notfl3/cargo-apk cargo 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.

iOS

See miniquad iOS sample project.

cross compilation


# 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

Goals

  • 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.

Non goals

  • 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!

  • sokol-gfx api compatibility. While sokol is absolutely great as an API design foundation, just reimplementing sokol in rust is not a goal. The idea is to learn from sokol, but make a library in a rust way when it is possible.

Dependencies