对于国内大量使用lua的情况，在尽量避免C#与lua相互调用的前提下，不建议使用新特性。
纯C#开发的，你还等啥呢？赶紧用啊。 现在有点青黄不接。我挺佩服unity的宣传策略，没有把这个巨大的青黄不接暴露出来 可以通过这两篇文章了解一下
Noahha：Unity ECS(一)了解ECS与DOTShttps://connect.unity.com/p/li-yong-dotszhi-zuo-yi-kuan-di-san-ren-cheng-sang-shi-she-ji-you-xi?app=true 本质上充分利用多核能力，并行处理数据流，这不就是gpu干的事情么
与传统cpu单线程开发思路不同，需要较大的调整编程思想
传统面向对象，一个对象，身上挂着多个组件，处理流程是一个对象一个对象，每个对象处理完所有组件，接着下一个
现在变成，所有对象的某个组件，构成数组，cache友好的处理完，
接着处理下一个组件数组
那gpu编程的难题都出现在cpu上了，没办法在一个pass里面组件之间互相拿数据了
如果能拿数据，那就打断了流水线，那相当于没性能了，那改造图啥
要么做多遍pass
但是这种处理结构，一般也就适合渲染和物理系统，这种数据交互少，有明显并行需要的
ai可能也可以，但是要看你是什么业务逻辑了
别的系统这么写能累死
那问题来了，物理和渲染很少人会动，一般都是相当稳定的系统，变动少，做一次就好了
别的也用不上
就看有没有大规模数据流要处理了，
但是做手机游戏的能有多大规模
所以你看Unity 也是拿来写物理和渲染或者群体AI, 这些对CPU性能有较大需求，别的也没啥大计算量的需求的，主要都是数据在内存里面挪来挪去 学习中，还是疑问比较多。 目前感觉优势就是大佬们说的cache miss，并行化，模块性强。但看官方目前给的2个sample，觉得类还是太多不知道后期管理起来会不会乱。目前的困惑是，这个理念和GPU计算是一样的吗，ECS和ComputeShader可以完美结合吗，我感觉是可以的，但不知道对不对，随学随更。
页:
1
[2]