Search Unity

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

Discussion in 'Data Oriented Technology Stack' started by nxrighthere, May 9, 2019.

  1. nxrighthere

    nxrighthere

    Joined:
    Mar 2, 2014
    Posts:
    522
    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
     
  2. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    4,642
    You can interop with p-invoke already. That is not easy or recommended, but it's possible. Making it easier than that is not desirable for the ecosystem in the long run and we do not want to encourage anyone to use C++ for game code.

    Our system will or is already offering:
    * Safety against race conditions, making it realistic even for beginner to write multithreaded code.
    * floating point determinism offered in the compiler
    * Higher quality codegen than C++

    C++ can not support those quite important requirements we set out to solve with DOTS.

    We also have no interest in fragmenting our eco system into multiple languages.
     
  3. nxrighthere

    nxrighthere

    Joined:
    Mar 2, 2014
    Posts:
    522
    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.
     
  4. nxrighthere

    nxrighthere

    Joined:
    Mar 2, 2014
    Posts:
    522
    @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.
     
  5. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    4,642
    You can use Unity as a library and you can use PInvoke from jobs or anywhere else. That is a perfectly valid and recommended use of Unity. Unity, unity users and asset store devs have been writing integration code with existing codebases, platform features etc in C++ for many years.

    It's a far shot from us recommending to use C++ to write game code.

    I believe the integration of C++ with Pinvoke & unity as a library you linked is sufficient for the use case you describe.
     
  6. nxrighthere

    nxrighthere

    Joined:
    Mar 2, 2014
    Posts:
    522
    @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:

    native_plugin.PNG

    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.
     
    Last edited: Jul 15, 2019
    wobes likes this.
  7. rdprado21

    rdprado21

    Joined:
    Jul 24, 2014
    Posts:
    1
    You have any examples of how we can use unity as a library for dektop apps?
     
  8. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    2,314
    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++.