UnityNativeScripting:C ++中的Unity脚本

  • S2_595136
    了解作者
  • 112.8KB
    文件大小
  • zip
    文件格式
  • 0
    收藏次数
  • VIP专享
    资源类型
  • 0
    下载次数
  • 2022-06-16 01:16
    上传日期
Unity本机脚本 一个库,允许使用本机代码(C,C ++,程序集)编写Unity脚本。 目的 该项目旨在为您提供C#的可行替代方案。 用C ++编写脚本并不适合每个项目的所有部分,但现在是一个选择。 目标 使C ++中的脚本编写像C#一样容易 低性能开销 轻松与任何Unity项目集成 快速的编译,构建和代码生成时间 不要失去Unity Technologies的支持 比C#更偏爱C ++的原因 快速的设备构建时间 更改一行C#代码要求您重新构建游戏。 典型的Android构建时间通常至少为10分钟,因为必须运行IL2CPP,然后必须编译大量的C ++。 通过使用C ++,我们可以在大约1秒钟内将游戏编译为C ++插件,将插件交换为APK,然后立即安装并运行游戏。 这极大地提高了生产力! 快速编译时间 C ++的比C#。 仅更改一个文件(最常见的构建)时的增量构建可以比使用C#快15倍。 随着时间的流逝,编译速度加快,从而提高了生产率。 更快的迭代时间使它更容易停留在编程的“流程”中。 没有垃圾收集器 Unity的垃圾收集器是强制性的,存在很多问题。 它很慢,在主线程上运行,一次收集
UnityNativeScripting-master.zip
内容介绍
# Unity Native Scripting A library to allow writing Unity scripts in native code: C, C++, assembly. ## Purpose This project aims to give you a viable alternative to C#. Scripting in C++ isn't right for all parts of every project, but now it's an option. ## Goals * Make scripting in C++ as easy as C# * Low performance overhead * Easy integration with any Unity project * Fast compile, build, and code generation times * Don't lose support from Unity Technologies # Reasons to Prefer C++ Over C# # ## Fast Device Build Times Changing one line of C# code requires you to make a new build of the game. Typical Android build times tend to be at least 10 minutes because IL2CPP has to run and then a huge amount of C++ must be compiled. By using C++, we can compile the game as a C++ plugin in about 1 second, swap the plugin into the APK, and then immediately install and run the game. That's a huge productivity boost! ## Fast Compile Times C++ [compiles much more quickly](https://github.com/jacksondunstan/cscppcompiletimes) than C#. Incremental builds when just one file changes-- the most common builds-- can be 15x faster than with C#. Faster compilation adds up over time to productivity gains. Quicker iteration times make it easier to stay in the "flow" of programming. ## No Garbage Collector Unity's garbage collector is mandatory and has a lot of problems. It's slow, runs on the main thread, collects all garbage at once, fragments the heap, and never shrinks the heap. So your game will experience "frame hitches" and eventually you'll run out of memory and crash. A significant amount of effort is required to work around the GC and the resulting code is difficult to maintain and slow. This includes techniques like [object pools](https://jacksondunstan.com/articles/3829), which essentially make memory management manual. You've also got to avoid boxing value types like `int` to to managed types like `object`, not use `foreach` loops in some situations, and various other [gotchas](https://jacksondunstan.com/articles/3850). C++ has no required garbage collector and features optional automatic memory management via "smart pointer" types like [shared_ptr](http://en.cppreference.com/w/cpp/memory/shared_ptr). It offers excellent alternatives to Unity's primitive garbage collector. While using some .NET APIs will still involve garbage creation, the problem is contained to only those APIs rather than being a pervasive issue for all your code. ## Total Control By using C++ directly, you gain complete control over the code the CPU will execute. It's much easier to generate optimal code with a C++ compiler than with a C# compiler, IL2CPP, and finally a C++ compiler. Cut out the middle-man and you can take advantage of compiler intrinsics or assembly to directly write machine code using powerful CPU features like [SIMD](https://jacksondunstan.com/articles/3890) and hardware AES encryption for massive performance gains. ## More Features C++ is a much larger language than C# and some developers will prefer having more tools at their disposal. Here are a few differences: * Its template system is much more powerful than C# generics * There are macros for extreme flexibility by generating code * Cheap function pointers instead of heavyweight delegates * No-overhead [algorithms](http://en.cppreference.com/w/cpp/algorithm) instead of LINQ * Bit fields for easy memory savings * Pointers and never-null references instead of just managed references * Much more. C++ is huge. ## No IL2CPP Surprises While IL2CPP transforms C# into C++ already, it generates a lot of overhead. There are many [surprises](https://jacksondunstan.com/articles/3916) if you read through the generated C++. For example, there's overhead for any function using a static variable and an extra two pointers are stored at the beginning of every class. The same goes for all sorts of features such as `sizeof()`, mandatory null checks, and so forth. Instead, you could write C++ directly and not need to work around IL2CPP. ## Industry Standard Language C++ is the standard language for video games as well as many other fields. By programming in C++ you can more easily transfer your skills and code to and from non-Unity projects. For example, you can avoid lock-in by using the same language (C++) that you'd use in the [Unreal](https://www.unrealengine.com) or [Lumberyard](https://aws.amazon.com/lumberyard/) engines. # UnityNativeScripting Features * Code generator exposes any C# API to C++ * Supports Windows, macOS, Linux, iOS, and Android (editor and standalone) * Works with Unity 2017.x and 5.x * Plays nice with other C# scripts- no need to use 100% C++ * Object-oriented API just like in C# > GameObject go; Transform transform = go.GetTransform(); Vector3 position(1.0f, 2.0f, 3.0f); transform.SetPosition(position); * Hot reloading: change C++ without restarting the game * Handle `MonoBehaviour` messages in C++ > void MyScript::Start() { String message("MyScript has started"); Debug::Log(message); } * Platform-dependent compilation (e.g. `#if TARGET_OS_ANDROID`) * [CMake](https://cmake.org/) build system sets up any IDE project or command-line build # Code Generator The core of this project is a code generator. It generates C# and C++ code called "bindings" that make C# APIs available to C++ game code. It supports a wide range of language features: * Types * `class` * `struct` * `enum` * Arrays (single- and multi-dimensional) * Delegates (e.g. `Action`) * `decimal` * Type Contents * Constructors * Methods * Fields * Properties (`get` and `set` like `obj.x`) * Indexers (`get` and `set` like `obj[x]`) * Events (`add` and `remove` delegates) * Overloaded operators * Boxing and unboxing (e.g. casting `int` to `object` and visa versa) * Function Features * `out` and `ref` parameters * Generic types and methods * Default parameters * Cross-Language Features * Exceptions (C# to C++ and C++ to C#) * Implementing C# interfaces with C++ classes * Deriving from C# classes with C++ classes Note that the code generator does not yet support: * `Array`, `string`, and `object` methods (e.g. `GetHashCode`) * Non-null string default parameters and null non-string default parameters * Implicit `params` parameter (a.k.a. "var args") passing * C# pointers * Nested types * Down-casting To configure the code generator, open `Unity/Assets/NativeScriptTypes.json` and notice the existing examples. Add on to this file to expose more C# APIs from Unity, .NET, or custom DLLs to your C++ code. To run the code generator, choose `NativeScript > Generate Bindings` from the Unity editor. # Performance Almost all projects will see a net performance win by reducing garbage collection, eliminating IL2CPP overhead, and access to compiler intrinsics and assembly. Calls from C++ into C# incur only a minor performance penalty. In the rare case that almost all of your code is calls to .NET APIs then you may experience a net performance loss. [Testing and benchmarks article](https://jacksondunstan.com/articles/3952) [Optimizations article](https://jacksondunstan.com/articles/4311) # Project Structure When scripting in C++, C# is used only as a "binding" layer so Unity can call C++ functions and C++ functions can call the Unity API. A code generator is used to generate most of these bindings according to the needs of your project. All of your code, plus a few bindings, will exist in a single "native" C++ plugin. When you change your C++ code, you'll build this plugin and then play the game in the editor or in a deployed build (e.g. to an Android device). There won't be any C# code for Unity to compile unless you run the code generator, which is infrequent. The standard C# workflow looks like this: 1. Edit C# code in a C# IDE like MonoDevelop 2. Switch to the Unity editor window 3. Wait for the compile to finish (slow, "real" games take 5+ seconds) 4. Run the game With C++, the workflow looks l
评论
    相关推荐