Show HN: Vrmac Graphics, a cross-platform graphics library for .NET
github.com
github.com
> I have only open sources .NET parts. The native library is shipped in binaries, with a permissive license which allows free use in any software (attribution is required).
Also from the eula:
> 3. You may not reverse engineer the software, except when this is allowed by EU Directive 2009/24 https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CEL... or the laws of your jurisdiction.
> 5. If you institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the program itself (excluding combinations of the program with other software or hardware) infringes your patent(s), then your rights granted by this license agreement shall terminate as of the date such litigation is filed.
I mean... good job and all, but let’s not pretend this an MIT cross platform graphics library.
It’s a closed source core that runs on windows and an source available C# wrapper.
Also ARM Debian Linux.
> an source available C# wrapper.
The wrapper is there: https://github.com/Const-me/Vrmac/tree/master/VrmacInterop
This one there https://github.com/Const-me/Vrmac/tree/master/Vrmac is not a wrapper. It implements majority of 2D engine except SIMD-optimized C++ functions, raw input including keyboard layouts, dispatcher, animations, timers, text rendering (except FreeType integration and SIMD-optimized bitmap transforms), and more.
Having said that, I am not sure why someone would use this compared to other completely free or open source engines.
Such as?
Indeed, there were many small problems I did not expect, I underestimated time by a factor of 3.
The geometry/math/GPU issues were expected and planned as I have decades of programming experience in the field. What I did not expect was the amount of smaller issues, like missing Unicode keyboard input on Linux, or missing direct D3D12-D2D integration on Windows.
I'm really liking the .NET Core. Seems like a really productive platform with no obvious downsides (good performance, and cross-platform compatibility?)
You did a lot in 1.5 months. How much would you contribute your speed to the platform of choice vs your experience vs time available, etc?
ARM Linux support is lacking. To make my library easy enough to use, I had to make the Debian package myself. Wasn’t too hard, here’s a bash script https://github.com/Const-me/Vrmac/blob/master/net-core/packa... but still.
The newer .NET Core-introduced features are still not integrated perfectly into the older ecosystem. The new ref structs can’t be generic arguments, resulted in copy-pasting there: https://github.com/Const-me/Vrmac/blob/1.0/Vrmac/Draw/Text/K...
For some use cases, generics are not good enough, again had to copy-paste a few lines: https://github.com/Const-me/Vrmac/blob/1.0/Vrmac/Draw/Main/I... This last one can be trivially solved with OOP stuff, however I didn’t want any virtual calls or heap allocated objects in that particular place of code, for performance reasons.
Even in the latest .NET Core 3.1, SIMD support is not good enough. Compiler generates very inefficient code: https://github.com/dotnet/runtime/issues/13811 ARM Neon support is lacking. Even on PCs, in my C++ I needed instructions, both vector like vcvtph2ps and scalar like BSR, not exposed to .NET but readily available as compiler intrinsics in C++, including ARM-targeted gcc on Linux.
But overall, .NET is quite good. Sometimes it can even beat C++ performance wise, like I did there https://github.com/Const-me/Vrmac/blob/master/Vrmac/Draw/Tex... or there https://github.com/Const-me/Vrmac/blob/master/Vrmac/Input/Ke... by embedding data into code and passing the code to JIT. The readability suffers, though.
I’m equally proficient in C++ and I would estimate it would take me 2x longer to do completely in C++. (1) GC is just too good to ignore for non-performance critical parts. (2) Runtime library is awesome in .NET: I/O, compression, text handling, weak references, async-await, thread pool helped a lot. The C++ equivalents are either nonexistent, or twice as hard to use. At least based on my experience.
And since then, while not perfect, the use cases where it is required deminishes with each platform release.
Plus any of the languages are better options than plugging a scripting language.
Good job.
Vrmac graphics only uses CPU to prepare triangle meshes and upload them to GPU.
In terms of image quality, I would expect Anti-Grain to deliver better results. However, I wouldn’t expect AGG to do it at 60 FPS in FullHD for complex vector images on the Pi.
Will probably improve that library when I’ll have more time, I have some missing features on the back log.