Looks interesting. I wonder how feasible it is for a single dev / small team to keep such a thing going. The sheer volume of little problems (especially if multi platform) seems overwhelming.
Thanks. It was me alone, and I’ve spent about 1.5 months on that, because quarantine.
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.
At some point you have to be expert on a lot of complex systems, all with their own set of weirdness and inconsistencies. I think it’s great you got as far as you did in such a short time. Probably learned a lot.
> 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).
> 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.
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.
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?
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.
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.
There are similarities, but AFAIK AntiGrain and derived projects all render on CPU.
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.
Awesome project! Would like to subscribe to minor updates on your projects. Do you post more often anywhere? Like Secure Scuttlebutt, or anything more common, like blog or Twitter/FB?
16 comments
[ 1.8 ms ] story [ 44.9 ms ] threadHaving 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.
Will probably improve that library when I’ll have more time, I have some missing features on the back log.
> 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.
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.
[1] http://agg.sourceforge.net/antigrain.com/index.html.
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.