Amazig: Origin Shift maze generation library for Zig

Showcase
1

amazig is a non-allocating library for generating perfect mazes for games and puzzles, using the recently (re)discovered Origin Shift algorithm.

If you’re into game- and puzzle development, maybe you’ll find it useful:

https://github.com/cryptocode/amazig

zig build run shows a terminal-based animation using the maze generator (requires a modern terminal like Kitty, Ghostty or WezTerm) - the library itself is obviously rendering agnostic and just needs a buffer for the maze paths.

2 Likes
2

With modern terminal, do you mean support for the kitty graphics protocol or something else?

3

The demo is text-based, though it uses mode 2026 for smooth refreshing

(The library itself has nothing to do with terminals - it just needs a buffer to work on)

2 Likes
4

:+1:
This is the right approach.

If a library mixes up CPU only stuff with I/O per se ((like libpq, or libmodbus, or libhiredis, hundreds of them…) - it’s not a good general purpose (“calculative”) library. Well, you can use such a library in a, perhaps, multi-threaded app, but if an app uses some more sophisticated I/O strategy, I/O hardcoded into a library inevitably will became a pain in the ass.

1 Like
5

Can you expand a bit? Where does, for exmaple, libpq mix CPU and IO?

6

I think he means that libpq and friends are the I/O part. So binding a computation library to those makes it less useful. Is how I read it.

7

Ah, that makes sense.

8

CPU+MEM only stuff

  • constructing requests, parsing replies (client side)
  • parsing requests, constructing replies (server side)
  • buffer managment

I/O (possibly event driven or asynchoronous)

  • sending requests, reading replies (client side)
  • reading requests, sending replies (server side)

Examples of “fat” API functions:

  • FCGI_Accept() from libfcgi - reads request and parses it
  • PQconnectdb from libpq - constructs messages, send messages, reads messages, parses messages. Decomposition, pg connector state machine.
  • a lot more…

Of course, using such fat functions is ok for a simple one-shot program or for a multi-threaded program, but for a single-threaded program with event driven I/O and fine grained concurrency it’s better to have only “CPU+MEM” API in a library and let an application itself control all I/O within chosen strategy.