Feedback Partial integration with the engine and API that powers DOTS using C/C++

The more I look at the data-oriented stack, the more obvious it becomes that we gradually leave in the past many aspects of the managed environment including the virtual machine itself. The idea that I would like to suggest is not something new and exotic, but very beneficial in theory for the current customers, and this should attract more new developers who use C/C++ languages and those who interop with them using VM compiled/interpreted high-level languages for making games/applications.

Since DOTS is almost the opposite tech to the managed framework/runtime, it would be awesome if Unity can provide a C interface with functionality and definitions of internal data structures that will open the doors for developers from many other programming languages, but primarily for C/C++. Some solutions already exist, but they are based on the C# bridge in order to interoperate with the engine's API which hurts performance, flexibility, maintainability, and so on. Native API is the way to new opportunities and possibilities such as custom frameworks, tight integration with unmanaged libraries, implementation of logic for games/applications without the limited translation of IL/.NET bytecode, freedom in programming workflow and native tool-chains for building and debugging.

Developers will have three options:

1. A full C# way with built-in packages such as ECS, Jobs, and Burst.
2. A full C/C++ way using an exposed native API that powers ECS and Jobs, but without C# implementation and built-in packages.
   
3. A mixed approach using the best of two worlds where Burst blurs the gaps and boundaries (already available partially without access to the engine's API from C/C++).

I think it's about the time for this since Unity with DOTS moving away from the embedded Mono and the managed runtime. I also believe that this should carry a positive effect on marketing and monopolistic competition.

I had several discussions with my friends including those who work at Unity, and they found this idea quite exciting, so I posted it here. Any thoughts are highly welcome. @Joachim_Ante @xoofx

 

The safety checks are very helpful indeed, but losing them as well as potentially better generated code would be an acceptable trade-off for me. Anyway, thanks for the answer, it helped to make some decisions in the context of this topic.

 

@Joachim_Ante (Add features powered by Unity to native mobile apps) Maybe you change your mind, and make it possible to link Unity as a library with native desktop applications as well?

For example, here's a real-world data-oriented application that I've created using Raylib as rendering library which is a mix of OpenGL and GLFW with other modules. If I only can use Unity as a static/dynamic library for rendering it would be perfect, since there are only a few alternatives that very limited in terms of 3D rendering features.

 

@Joachim_Ante Yes, I'm doing that as well. The biggest problem is the P/Invoke itself where you need to wrap functionality and create interop signatures which hurts performance and requires to do a certain amount of extra work to achieve this, look at simple native logger.

I just grabbed this from comments in the blog post:



For example, Unigine SDK provides a special class or interface that can be used for out of the box integration with MFC, SDL, Qt, and so on. All that you need to do to get access to engine's features is include a few header files, and voila, it works with the native API.

 

You have any examples of how we can use unity as a library for dektop apps?

 

It looks like it's doable at a quick glance, although there could be any number of things that block it working on desktop. The android integration looks to be using JNI which implies the low level integration is just C/C++.