Actually every single line is currently converted from C# to optimized C#, to be used on any platform that supports C#.
The same optimized C# code is then used and further changed in preparation to conversion to C++, still every single line you had is there or was converted.
For native C++ things are not working the same way, so now some replacements happen and a lot of the low level classes are replaced, changed or completely removed and get an implementation that makes sense on C++, for example there is no XNA on C++, thus Graphics has a C++ specific implementation (OpenGL), same for JavaScript (WebGL).
Entities are much harder to describe because of many optimizations in place already in the C# version of the open source engine. In general entities should be empty classes that just have a list of components and tags (and IsActive to use it or disconnect it from the EntitiesRunner).
In general all Entities get converted to plain data structures in the optimized C# version, this way execution is way faster, no reflection is needed, no casting, no type conversion or complicated Get, Contains, GetInterpolated, etc. methods are necessary because all the data is right there. We call this Flatten Entities. These are then used to be converted to any other language, which is quite simple because they all just use some data. This way the data can be optimized to fit best to the target platform architecture. Obviously we did not have the time to do much here as we are still busy with the optimized C# side of things, but the goal is to make sure we do not have too many cache misses and structure the data in a nice way the CPU and GPU like. This is something other engines cannot provide automatically, the user has to do all this work himself (or use an engine where he cannot invent new things without first understanding how it all works on the low level).
Currently whenever the build service encounters something it does not understand, it will abort and throw the exception back to the user. This is pretty much the mode we work on most of the time. The compilers after the conversion can also throw warnings and errors, which are also send back to the user. In any case the user can try to fix the problem himself (if the error makes sense and there are ways around it), or he has to ask us to support that specific feature better.
In your example the PGEntity class might not be understood by the Flatten Entities conversion step (it might work already, I don't know your code and potential issues), then you will get an error message and can either try to fix it yourself, or ask us to support it better (which we might not be able to do in a short amount of time if it is a really complex issue and we have other things keeping us busy). The more people ask and need support, the more important things become and the more we will want to support it :) So if you are the only user in the world with PGEntity and everyone else is fine, and it would take 2 months to support your crazy PGEntity because it uses all kinds of strange C#6 language features, PInvokes, whatever, then we most likely are not going to support it, you will have to fix it yourself. If everyone is doing these kinds of things, we have to support it in the long run. Just adding messaging in your example is plain C# code and should work out of the box, try it out ^^
Obviously it will take some time until things are really general. This is why we are currently not so much community focused, but instead do some internal projects and contract work to earn some money and find out the basic functionality we need. At any point in time we are still releasing versions and making the features available to all users. If someone is working on something and needs our priority support, we are also helping as best as we can, the hope is of course that things just work for most guys and we do not need to do custom support much.
Hope this helps.
Login