I'd go one further and suggest:
https://github.com/jeremyong/klein

I started to port it but hit a wall. If there's interest...?

I'd go one further and suggest: https://github.com/jeremyong/klein

I started to port it but hit a wall. If there's interest...?

There is interest, sure. I can try to help. What problem do you have?

I'll clean up the repo and make it public and then perhaps we can discuss it further :)
I had to translate the C SIMD intrinsic routines to zig's more basic vector syntax and I was getting different results to the original library. (Only got through about 15% of the full lib so far)

It might take a few weeks or more for me to find the time!

It may also be quicker to create a C interface instead of reimplementing it fully - but I was unsure about how that would affect memory allocation and lifetimes (new to systems stuff especially FFI). Can you use a custom allocator in zig when the library calls a C++ class constructor for example?

It may also be quicker to create a C interface instead of reimplementing it fully - but I was unsure about how that would affect memory allocation and lifetimes (new to systems stuff especially FFI). Can you use a custom allocator in zig when the library calls a C++ class constructor for example?

Unfortunately, if you're linking to a compiled C library and that library uses traditional malloc or new, etc..., you also have to link in libc/libcpp.

Just my 2c but I think the tradeoff would probably be worth it to get a working layer over the C library into zig-gamedev. Having such a layer working would make further Zig conversion dev work easier, having a backup in case of regressions/incompatible behavior, etc...

Often C libs expose a way to override their allocator. We use do this in zstbi for example, see https://github.com/zig-gamedev/zig-gamedev/blob/main/libs/zstbi/libs/stbi/stb_image.c

If a C library doesn't expose a way to override malloc/free it's worth considering making this change upstream or just hacking it using the preprocessor.