CHello, I watched the Jetbrains talk and wondered where to start on using the code gen system on other libraries. I would love to have Entt.net become a thing? 
Poh boy, that sounds like something to answer at a desk. Will get out of bed and get back to you in 10 minutes or so
CHahaha, the bed is sometimes the best place to throw ideas around before committing to something 
CI think the main issue is that Entt uses C++ templates so it might just be that a code generator needs to be built that outputs C++ classes which tie directly into Entt and then call a C# function
SWhy not use genetics?
CWell I don't know how well c# generics tie into c++ templates?
CI have a feeling not very well 
SI came up with a few ideas while laying in bed before sleeping.
I wasted few minutes next day just to remind myself what they was.
I wasted few minutes next day just to remind myself what they was.
SYes but they can be different
S(not everything can be converted to c#)
S(not all templates)
CYeah which is why i think that just generating a stub c++ class that you have more control over might be simpler
CSo you could just make a c# class with the generic types that you want to see in the Entt template and it makes it for you with all the callbacks
CI'm not really an expert when it comes to interoperability in generated code...
Pright back
Pso the state of our generator stack right now is a bit variable. assuming the base knowledge from the webinar:
BuildTools is currently quite finicky to get working, but when it does work it can bind pure C APIs quite well. When it doesn't work, however, the errors aren't very obvious and you end up spending 15 minutes just tweaking specific settings until it works. BuildTools is not intended for general consumption.
BuildTools is currently quite finicky to get working, but when it does work it can bind pure C APIs quite well. When it doesn't work, however, the errors aren't very obvious and you end up spending 15 minutes just tweaking specific settings until it works. BuildTools is not intended for general consumption.
Cyes but with it being 9 months ago I was hoping that some of the issues would be improved
PIt also doesn't cope well with very C++-like APIs, such as templated APIs (which are entirely impossible to bind without writing more C++) or C++ functions which are mangled in inconsistent ways
SPThat, coupled with the artform that is ECS design, would lead me to suggest you're probably better off making an entirely C# ECS implementation, as they tend to be designed such that memory is laid out in a specific way (usually sequentially) which would be thrown off by managed-to-native transitions and other CLR specifics (you lose the benefits of a lot of the optimizations made in the library you're using)
CWell I've been making a small bechmark of existing c# ecs libraries and they are a little lacking
C
Ccomared to entt which is under a ms for 10m entries
CI know there would be an overhead to using c# but even if it halves performance it would be a lot faster than what c# can do currently
Pif you were prepared to make a C wrapper over EnTT, using BuildTools to bind it would be trivial
Pbut EnTT is very C++, and using BuildTools is not officially supported outside of Silk.NET itself
Pthat is changing in 3.0, but that rewrite is still being designed today
CThats fine, I can always work away at it in the background then then share what I have done and maybe everyone befits
CDo you know roughly what the overhead is of the code generation that you have with Silk.net
CI imagine it's lower than p/invoke
CWith Entt I'd be sending over structs back and forth with can be expensive but if they are limited to being blittable I would think it's just a memcopy? or is that to naïve?
Pfor non-blittable P/Invokes SilkTouch is faster than DllImport
Pfor fully blittable P/Invokes DllImport is marginally faster, but that's only because it's baked into the runtime and as such has the function pointer baked into the assembly rather than having to do a lookup like we do
Pbut all in all the overhead only amounted to a nanosecond in benchmarks we did in the early days of silk.net
CHmm
CThat's promising
CSo I might look into making something that just makes C++ shims based on C# generic classes
CI'll have a look at that biohazard thing that was linked
CAt the moment I'm just trying to get an idea of the steps involved in making the whole thing (or at least covering the basic ECS functionality) and then I'll start this little project early January
SThere are c# ecs libraries
Cyes and so far they don't handle lots of entities very well
C
SWhat about https://github.com/sschmid/Entitas-CSharp?
GitHub
Entitas is a super fast Entity Component System (ECS) Framework specifically made for C# and Unity - GitHub - sschmid/Entitas-CSharp: Entitas is a super fast Entity Component System (ECS) Framework...
CI haven't done that one yet
Psaw unity nomenclature and was turned off instantly
SWonder if i can use ecs for rendering ;)
Cbut based on this I don't think it'll be any faster https://github.com/Doraku/Ecs.CSharp.Benchmark/blob/master/results/Ecs.CSharp.Benchmark.SystemWithOneComponent-report-github.md
CI actually really like it because it's super simple to use. It's changed since the original 2019 release to something much better if that's what your basing your opinion on?
Pthey’ve stopped using camelCase?
SIt also allocates something :p
