If you're here from crates.io and wondering where ShitHub is, it's gay and I refuse to use it.

This website doubles as a Cargo registry for libraries I wrote over time and a couple of my game projects (WIP). At first I was uploading some stuff to crates.io and even got a few downloads, but as a matter of principle I'd rather sacrifice a bit of publicity for self-reliance and freedom from a ShitHub account, and having to make a stoopid "loicense" file.

Though I'm not mirroring the dependencies, so if crates.io ever goes down stuff will break... might be a good idea even if they'd massively bloat everything.
Another caveat is I'm not gonna host each individual version of my projects, only the latest, so you might need to update your project's lock file occasionally.

To use the registry, append this to your .cargo/config.toml, and when adding dependencies with Cargo, use: cargo add --registry tesseract ...

# Docs

arg-kit

arg-kit is a featherweight library that helps parse arguments using one of Rust's most versatile and powerful syntaxes: match {}

Do you really need bloated proc macros when collecting arguments can be simplified to a .next()? You have zero indication of what's going on under the hood, so you can't implement your own behaviour.

That is why I don't call it an "argument parser" on its own. Your program parses the arguments, this just helps iterate over it, like so:

let mut argv = std::env::args();
for_args!(argv; {
    arg!(-h | --help) => eprintln!("{HELP_TEXT}"),
    arg!(-v | --value) => do_something(argv.next()?),
    unknown => panic!("Unknown argument {unknown}"),
});

...which expands to:

let mut argv = std::env::args();
while let Some(args) = argv.next() {
    for arg in args.as_arg() {
        match arg {
            ...
        }
    }
}

# Docs

mew

WIP, but definitely working

As you might have guessed, I've got a terminal (not tty) case of made-at-home syndrome - I'd rather make a complete system from scratch than learn a probably-bloated pre-existing framework, that somehow simultaneously overcomplicates and oversimplifies everything with no room for optimization. So, I figured I'd just learn how graphics worked under the hood.

wgpu is a 1:1 API for the WebGPU standard. While that makes it very portable, versatile, and pretty well-documented, since I'm not a hardcore graphics chud, I don't find it very intuitive to use. My main problem with it is how many bloody times you need to define the same thing, and quadruple-check that all the layouts line up with each other.

After my first attempt at real graphics, I concluded wgpu wasn't fit for use directly by an end-user application. The obvious next step was to read docs, find patterns in the graphics stack, read docs, come up with a data model, read docs, and extract everything I've learnt along the way into a library. And then read some more docs.

This library aims to, at least a little bit, make it easier to define all the related information in one place (in wrapper structs). It primarily uses like 20 macro_rules! to write boilerplate that generates buffer, bind group, and pipeline layouts. It also stores them in a convenient "render context" struct - see the example for details, but compare the below to having to reference 50 pages in wgpu's docs to get a pyramid to spin (I've done that job for you).

sampler! { Sampler as Filtering }

texture! { Texture {
    usage: COPY_DST | TEXTURE_BINDING,
    format: Rgba8UnormSrgb,
    dimension: D2,
    sample_type: FloatFiltering,
} }

vertex_struct! { Vertex [
    0 pos => Float32x3,
    1 uv => Float32x2,
] }

buffer! { VertexBuffer <Vertex> as STORAGE | COPY_DST | VERTEX }

shader_struct! { TransformMatrix [
    0 mat => Mat4x4f,
] }

buffer! { TransformBuffer <TransformMatrix> as UNIFORM | COPY_DST }

bind_group! { Group [
    0 texture @ FRAGMENT => Texture,
    1 sampler @ FRAGMENT => Sampler,
    2 transform @ VERTEX => TransformBuffer,
] }

pipeline! { Pipeline {
    bind_groups: [
        0 => Group,
    ],
    vertex_types: [
        0 => Vertex,
    ],
    fragment_targets: [
        0 => ALPHA_BLENDING ALL as SURFACE,
    ],
    push_constants: [],
    depth: None,
    cull: Some(Front),
} }

render_context! { RenderContext {
    features: [],
    limits: [],
    bind_groups: [
        0 => Group,
    ],
    pipelines: [
        0 => Pipeline,
    ],
} }

Again, the point isn't to create an entirely new graphics framework - or any sort of framework at all, really - rather, just to make it maybe easier for us mortals to keep on top of the rendering pipeline, while still giving complete control over what runs when.

I would still definitely recommend following the wgpu tutorial at least once to get familiar with the concepts, if you've never dealt with low-level graphics shenanigans before.

also jesus fuck, how many breaking updates can wgpu get between each time I look at it

Projects

Rust Libs

arg-kit

mew

WIP, but definitely working