mach
ComLightInterop


mach | ComLightInterop | |
---|---|---|
38 | 11 | |
3,707 | 49 | |
6.6% | - | |
9.7 | 6.2 | |
10 days ago | 6 months ago | |
Zig | C# | |
GNU General Public License v3.0 or later | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
mach
-
Show HN: Lyceum – An MMO game built with Zig and Erlang
Did you happen to tinker with https://machengine.org/ it's a Zig game engine & graphics toolkit?
-
Leveraging Zig's Allocators
We're working on a game engine in Zig[0]
If you're looking for interesting Zig codebases to read, you might be interested in our low-level audio input/output library[1] or our module system[2] codebase - the latter includes an entity component system and uses Zig's comptime to a great degree to enable some interesting flexibility (dependency injection, global view of the world, etc.) while maintaining a great amount of type safety in an otherwise dynamic system.
[0] https://machengine.org/
[1] https://github.com/hexops/mach/tree/main/src/sysaudio
[2] https://github.com/hexops/mach/tree/main/src/module
-
Zig Software Foundation 2024 Financial Report and Fundraiser
Myself and many others are betting on Zig in major ways, I truly think it has a bright future ahead.
In spare time, myself and a few others are working on a game engine in Zig[0], and the Zig core team has been very receptive to addressing issues our project faces and supporting us.
Others are working on pixel art editors[1], open source 2D RPG games[2], there's a group of independent folks working on a 3D massive immersive sim game[3], a group working on making Zig an amazing language for micro-controllers[4], etc.
Please consider donating $5-10 a month to the ZSF! They are a great group of people, and it has so many knock-on effects for others in the FOSS community. :)
[0] https://machengine.org/
[1] https://github.com/foxnne/pixi
[2] https://github.com/foxnne/aftersun
[3] https://github.com/Srekel/tides-of-revival
[4] https://github.com/ZigEmbeddedGroup
-
DevDocs
I don't know if there's anything better than a zip. For our website[0] which includes a bunch of docs for our game engine, Zig packages, etc. we just offer a link "offline version of this site" in the footer which is an ~80MB zip file.
I think the challenge with zip files is.. do you want all the images? do you want all versions of the docs, or just a specific version of the docs? It's hard to tailor the zip to the user's desire. But zip still seems to be the best.
[0] https://machengine.org/
- Not only Unity...
- Mach - Zig game engine & graphics toolkit
- New Béziers from Math
-
0.11.0 Release Notes
A game engine https://machengine.org is being written in zig, there's also https://microzig.tech as zig is well suited to embedded development.
-
Significant examples of Zig software (June 2023)?
https://github.com/hexops/mach (shameless plug)
-
Learn WebGPU
Zig fits pretty naturally here too. We've got ~19 WebGPU examples[1] which use Dawn natively (no browser support yet), and we build it using Zig's build system so it 'just works' out of the box with zero fuss as long as you grab a recent Zig version[2]. No messing with cmake/ninja/depot_tools/etc.
WASM support in Zig, Rust, and C++ is also not equal. C++ prefers Emscripten which reimplements parts of popular libraries like SDL, for me personally that feels a bit weird as I don't want my compiler implementing my libraries / changing how they behave. Rust I believe generally avoids emscripten(?), but Zig for sure lets me target WASM natively and compile C/C++ code to it using the LLVM backend and soon the custom Zig compiler backend.
[1] https://github.com/hexops/mach-examples
[2] https://github.com/hexops/mach#supported-zig-version
ComLightInterop
-
Stop Making Me Memorize the Borrow Checker
> I think Rust strikes a pretty good balance with it though
I don’t like that balance.
For performance-critical things like BLAS and other low-level numerical stuff, C++ is safer than unsafe Rust because standard library and tooling (debug heap, debug allocators, ASAN, etc.) evolved for decades making the language usable despite the unsafety. Another thing, for numerical code you probably need SIMD intrinsics. They were defined by Intel, documentation and other learning resources almost exclusively target C language; C++ got them for free due to compatibility.
For high-level pieces which are not that performance critical, I use C#. Due to VM, it’s safer than Rust. Due to GC and other design choices usability is way better than Rust, e.g. in C# asynchronous I/O is almost trivial with async/await. The runtime is cross-platform, I have shipped production-quality embedded ARM Linux applications built mostly with C#. Unlike Java, it’s easy to consume unmanaged C++ DLLs using C API, or even C++ API: see that library to do that on Linux which doesn’t have COM interop in the runtime https://github.com/Const-me/ComLightInterop
-
Writing GUI apps for Windows is painful
I do not recommend C++ CLI.
Can you elaborate on why?
I looked at various ways for interop between C# and C++ over the years, and overall found C++/CLI to be the best overall for our particular application types: it's a separate layer bewteen a C++ backend (which is also used in other non-gui applications), with a windows-only WPF desktop application on top. Mainly because the C++/CLI code itself is simple, readable and fairly effortless to write and maintain. A bit repetitive at times though. Integration on the C# is seamless, with code completion etc, and C# interfaces can be implemented in C++/CLI directly for instance. The initial setup takes some work but with conversion between common types implemented (ability to e.g. IEnumerable <-> std::vector or std::iterator etc) it's all pleasant and good.
or check this library of mine https://github.com/Const-me/ComLightInterop/
Gotta say this looks neat, but it's exactly the type of code I'd rather not write: UUIDs, bunch of macros, unclear mapping beetween return types (HRESULT vs bool), having to declare same interfaces both in C++ and C#, ...
-
Swig – Connect C/C++ programs with high-level programming languages
I have once made something remotely similar, to interop between C++ and C#: https://github.com/Const-me/ComLightInterop
I took different approach. Because I only needed to support these two languages, there’s no separate interface definition language, and no code generator for interfaces. Instead, users are expected to write both language projections manually.
Then there’s a runtime code generator on the .NET side of the interop which builds runtime callable proxy types for interfaces implemented in C++, also virtual tables for C# objects consumed by C++.
-
C# 11 Preview Updates – Raw string literals, UTF-8 and more
It’s pretty fast. Likely reason for that, MS designed both language and runtime this way since version 1.0. They needed that for their Windows Forms which consumes huge chunk of WinAPI.
I benchmarked a while ago when testing this library https://github.com/Const-me/ComLightInterop#performance On the computer I was using at that time (probably Ryzen 5 3600 CPU) the overhead was 15-20 nanoseconds per call.
-
Mach v0.1 – cross-platform Zig graphics in ~60 seconds
That thing is COM, which is a small subset of C++ ABI. Technically it’s about the same as on Windows, i.e. C ABI with extra first argument for this pointer.
Once upon a time I made this library https://github.com/const-me/comlightInterop/ The native side of the interop is idiomatic C++, here’s an example https://github.com/Const-me/ComLightInterop/blob/master/Demo... The C# side of the interop is implemented through the built-in C interop, here’s the relevant part of the library https://github.com/Const-me/ComLightInterop/blob/master/ComL... I’ve tested Linux version of that library on AMD64, ARMv7, and ARM64 CPUs, but only with gcc compiler on the native side.
-
COM+ Revisited
I like many parts of COM, but I believe that example mostly demonstrates bad parts, with IDL, registrations, and over-engineered support libraries.
There's nothing wrong with exporting factory functions from DLLs. Microsoft does it all the time, APIs like Direct3D, DirectDraw and Media Foundation don't come with type libraries are they aren't registered anywhere.
Speaking about support libraries, I once made my own: https://github.com/Const-me/ComLightInterop/tree/master/ComL... Compare examples from that article with this one: https://github.com/Const-me/ComLightInterop/blob/master/Demo... That source file is the complete DLL which implements a minimalistic COM object.
-
The Serde Rust Framework
> Does it feel "brittle" to use
Yes and no.
No because when you try to do unsupported things like calling a method on an object which doesn’t support one, you gonna get an appropriate runtime exception.
Yes because if you fail lower-level things like local parameter allocation, you gonna get an appropriate runtime exception but that one is (1) too late, I’d prefer such things to be detected when you emit the code, not when trying to use the generated code (2) Lacks the context.
Overall, when I can I’m using that higher-level System.Linq.Expressions for runtime codegen. Things are much nicer at that level. I only using the low-level thing when I need to emit new types, like there: https://github.com/Const-me/ComLightInterop/blob/master/ComL...
- Weird
-
Building a shared vision for Async Rust
> Do you have any good resources on writing dlls to consume via .net like you’re talking about?
For C APIs i.e. functions, structures and strings, the good resource is Microsoft documentation, the support is built-in, see “Consuming Unmanaged DLL Functions” section: https://docs.microsoft.com/en-us/dotnet/framework/interop/
For COM APIs i.e. sharing objects around see this library + demos: https://github.com/Const-me/ComLightInterop It’s only really needed on Linux because the desktop version of the framework has COM support already built-in, but it can be used for cross-platform things just fine, I tested that quite well i.e. not just with these simple demos.
> How do you deal with the managed memory when using the gc from .net
Most of the time, automatically.
When you calling C++ from C#, the runtime automatically pins arguments like strings or arrays. Pinning means until the C++ function returns, .NET GC won’t touch these things. This doesn’t normally make any copies: C++ will receive raw pointers/native references to the .NET objects.
Sometimes you do want to retain C# objects from C++ or vice versa i.e. keep them alive after the function/method returns. An idiomatic solution for these use cases is COM interop. IUnknown interface (a base interface for the rest of COM interfaces) allows to retain/release things across languages.
-
Experimental Nintendo Switch Emulator written in C#
C++ interop is not supported in modern .NET out of the box, but wasn't too hard to implement as a library: https://github.com/Const-me/ComLightInterop
What are some alternatives?
quickjs-emscripten - Safely execute untrusted Javascript in your Javascript, and execute synchronous code that uses async functions
ioccc-obfuscated-c-contest - IOCCC International Obfuscated C code contest entries
SDL.zig - A shallow wrapper around SDL that provides object API and error handling
Ryujinx - Experimental Nintendo Switch Emulator written in C#
arocc - A modern fully featured C compiler.
sapio - A Bitcoin Programming Language
zig - General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
miniserde - Data structure serialization library with several opposite design goals from Serde
glibc_version_header - Build portable Linux binaries without using an ancient distro
pfr - std::tuple like methods for user defined types without any macro or boilerplate code
mach-glfw-vulkan-example - mach-glfw Vulkan example
create-rust-app - Set up a modern rust+react web app by running one command.

