posted by wap, platform: Chrome

引用:

原帖由 @MacPhisto  于 2024-2-10 22:49 发表
Unreal 的痛点并不是基于c++，而是它在c++的基础上 自己实现了一套垃圾回收。这种自动内存管理系统只适合做规模不大 角色不多的游戏。一旦做开放世界 npc 数量多的 就露馅了

喷了，头一回听说UE GC是痛点的

posted by wap, platform: Chrome

引用:

原帖由 @MacPhisto  于 2024-2-14 03:38 发表
做小项目无所谓。做3a 用gc，从技术角度来说就是给自己找别扭。。从商业角度，说是自寻死路一点都不夸张

自寻死路喷了，这都哪听来的胡话，别看到GC两个字就默认性能不行

posted by wap, platform: Chrome

引用:

原帖由 @MacPhisto  于 2024-2-15 15:00 发表
gc是为了提升开发效率，降低开发门槛，代价是牺牲运行时性能

3a是追求极限运行时性能的，需要给每个子系统量身定制最优的内存分配方案，对每个程序员的素质要求很高，所以不会依赖gc

你是不是以为UE引擎子模块也在用GC？
UE GC和编程语言的GC是两码事。UE GC要慢也是标记阶段卡，正常tick能有多少运行时开销？实在嫌慢就关了呗
gameplay这种需求变动多杂活多的地方必然一堆屎山，有个GC托底定时整理内存指不定性能还会更好，别太高看所谓3A的能力，如果真的能做到处处追求极限运行时性能，那为何DOD讲了这么多年还没普及呢

posted by wap, platform: Chrome

引用:

原帖由 @MacPhisto  于 2024-2-15 16:02 发表
UE 到现在连个基本的jobification 都很难做到，根本原因就是它的内存模型和线程模型都是严重拖后腿的。大部分ue 开发者使用的多线程都是system on thread，这种属于二十年前的开发范式了，严重落后于时代

这也是为什么大部分3a都是自研引擎

顶级的3a游戏甚至可以做到每个子系统都job 化，在n个worker thread 并行执行，甚至连主线程都没有了。这就暗示了内存对象的ownership 不可能交给一个外部的系统

这和GC有什么关系？
而且谁说没job system的，task graph不就是？

posted by wap, platform: Chrome

引用:

原帖由 @MacPhisto  于 2024-2-16 00:49 发表
task graph的粒度太粗糙了，和当代3a引擎的jobification不是一个概念

这也是为什么ue5搞了一个实验性质的MassEntity出来。可惜unreal自身的线程模型 内存模型都严重拖后腿，MassEntity只不过是屎上雕花

哪粗糙了，你什么粒度的任务连个正常job system都跑不了？3A游戏里纯jobify的本来就是少数，全打包成job又不代表速度一定更快

mass是ECS插件，ECS有自己的适用场景，和你多线程用什么粒度跑有什么关系

posted by wap, platform: Chrome

引用:

原帖由 @MacPhisto  于 2024-2-17 03:47 发表
ecs和job化本来就是深度绑定的。job化暗含了ecs。没有ecs，连基本的内存读写访问都很难控制，就别提job化了

unreal的mass和unity的dots是一回事，都是在老化且过时的基础上强行搭一个新的框架，坑实在太多。这就是为什么大多数3a都是自研

那请问哪个3A做到全部ECS化全部job化了？你当ECS化做起来这么简单？合着不ECS job化就做不了3A了？

mass用了什么“老化且过时的基础”了？ECS哪个不是自己开内存池自己管理内存模型？你就算用默认malloc能慢到哪去？