Fork adds Zig bindings (and C bindings) and a bit of memory management.

[a-day-old-bagel]

So I liked this library, and wanted to use it in my game engine. But I'm writing my engine in Zig. So I put together some bindings for Zig, and that also means bindings for C (by the nature of how Zig works with C).

Another thing that we like to do in Zig is try to have a good handle on all the memory allocation. So I did also modify the existing C++ files slightly. Just enough to allow the replacement of the STL containers with custom-allocated ones, and allow for overriding the new/delete's for each struct.

This means I just added some macros in a few places in your code, and under normal circumstances (for people calling the code from C++), they should resolve to no changes whatsoever.

Anyway, I was uncertain if you'd be interested in incorporating new bindings into your own codebase, which is why I didn't PR this stuff, and instead just left it in my fork.

But if you're interested in C and Zig bindings, and you don't mind the extra few macros, my changes shouldn't break anything for you if you wanted to pull them or something.

Or if you're interested in the idea, but don't like how I did it, I'd be happy to redo some of it in whatever style or practice you prefer. Like if you do want bindings, but you want the directory structure different, or you don't like macros, or something, etc. etc.

Anyway cool project. I think some modern CSG in gamedev is going to really open up untapped potential, in this industry saturated with mesh-first asset pipelines.

[a-day-old-bagel]

And if this all just looks like unnecessary clutter, I understand. I just wanted to make you aware that I did this stuff.

Here's a view of the changes, for easy reference.

(Oh, and also, I should mention the zig binding portion in zcsg.zig isn't complete yet - I'm still filling that out. But the C portion is, hopefully, all functional. I still have to write more tests, too, to make sure it's not broken.)

[laleksic]

Good stuff!

So, this is just an old hobby project that I made to figure out tech used by my favourite late 90s / early 00s games. Also had a dream to build a game-engine agnostic editor for "classic" style maps around it, but didn't really have the willpower at the time. If I took the idea up again, I'd probably rewrite it all from scratch - and I'd probably integrate it into the editor instead of trying to make a general purpose library.

I wasn't really planning on maintaining this repo or taking it further with bindings etc. Possibly just fixing bugs or giving a helping hand if anyone found a use for it. So feel free to ping me if you need anything of the sort.

Regarding your changes, I didn't look at the particulars but, yeah, with the rising popularity of "C but better" languages, a flexible C API ready to accommodate different memory management schemes is certainly a good thing in terms of making the library more accessible to as many people. If you're interested in developing this further as a standalone library (outside your engine), I can give you permissions for the repo or link to your fork as the definitive maintained edition in the readme.

It warms my heart though to see my baby getting love like this. Thanks! I'd love to know if you end up using it in a game or editor!

[a-day-old-bagel]

Yeah, given that the codebase isn't actually super large, it might have been more efficient for me to port it to Zig (rewriting it natively in Zig) for my own purposes, but I just went with the "bind to it instead" option because it does seem like a nice idea to have it sort of standalone and portable between popular languages.

And since now I already did most of the work (knock on wood) to get the bindings working, I might as well keep going in this direction unless some major pitfall presents itself.

And if the underlying C++ needs fixing, updating, optimizing, or feature-creeping, hopefully I don't regret binding instead of porting.

As far as taking over the maintenance of the definitive version, I think I'll wait to see if I hit any big roadblocks with it before I say "let's do it" with enough confidence. But if it all goes smoothly, then that's an appealing proposition.

Furthermore, if it all ends up being a stable, polished thing once I've used it long enough to determine that, I might suggest proposing to the zig-gamedev maintainers that it be included in their library collection. I've been contributing to zig-gamedev, and a standalone CSG library like this would fit right in there imho.

Anyway, thanks for offering your feedback on this little binding excursion, and I'll update you with any interesting news on my end.