posted by wap, platform: Chrome

引用:

原帖由 @MacPhisto  于 2025-1-4 11:50 发表
如果目标平台是steam pc，那么优化不是最大的问题，毕竟用户可以掏钱升级硬件。但如果目标是console ，那用unreal 就是作茧自缚了。这也是为什么顶级3a都是自研引擎，说白了，首当其冲，内存对象的所有权，必须在游戏开发者手中，而不是被引擎隐藏起来

233还在搁这UE不能管内存只能单线程呢，UE确实是把门槛拉太低了什么阿猫阿狗都能来锐评两句

posted by 论坛助手, platform: iPhone

引用:

原帖由 熊熊哥哥 于 2025-01-04 12:08 发表
steamdeck都能运行，xss应该比sd强吧。

sd内存16g

posted by 论坛助手, platform: iPhone
不上是对的。强上怕是和心灵杀手2一样，在xss上不定时闪退。

posted by wap, platform: Chrome

引用:

原帖由 @ginaamix  于 2025-1-5 00:17 发表
233还在搁这UE不能管内存只能单线程呢，UE确实是把门槛拉太低了什么阿猫阿狗都能来锐评两句

UE的uobject，aactor这些基础设施都是单线程思维。AActor::GetComponentByClass, GetComponents这些基础api更是多线程的灾难

现代多线程引擎的设计思路是ecs，强调的是数据流和代码流的并行化。不存在什么强actor，最多只有弱的entity handle。对内存的读写是在system这个级别发生，以component为单位的。system和components的依赖关系是可以在编译期确定和验证的

当然我说的这些是大体思路，不同公司的自研引擎实现方法有自己的区别。gdc上最近十年都陆续有大公司分享自己的设计，也有很多公司的设计思路并没有公开。比较典型的例子可以参考remedy在GDC 2024的ECS in Practice: The Case Board of Alan Wake 2

本帖最后由 MacPhisto 于 2025-1-5 02:12 通过手机版编辑

posted by wap, platform: Android
袈裟个jb

posted by wap, platform: 小米
xss 难道还不如 steam deck？

posted by wap, platform: Chrome

引用:

原帖由 @MacPhisto  于 2025-1-5 02:10 发表
UE的uobject，aactor这些基础设施都是单线程思维。AActor::GetComponentByClass, GetComponents这些基础api更是多线程的灾难

现代多线程引擎的设计思路是ecs，强调的是数据流和代码流的并行化。不存在什么强actor，最多只有弱的entity handle。对内存的读写是在system这个级别发生，以component为单位的。system和components的依赖关系是可以在编译期确定和验证的

当然我说的这些是大体思路，不同公司的自研引擎实现方法有自己的区别。gdc上最近十年都陆续有大公司分享自己的设计，也有很多公司的设计思路并没有公开。比较典型的例子可以参考remedy在GDC 2024的ECS in Practice: The Case Board of Alan Wake 2

本帖最后由 MacPhisto 于 202515 02:12 通过手机版编辑

嗯，报了半天ECS菜名，然后举个单线程跑Lua虚拟机的例子，你是懂幽默感的

posted by wap, platform: iPad

引用:

原帖由 @ginaamix  于 2025-1-5 13:59 发表
嗯，报了半天ECS菜名，然后举个单线程跑Lua虚拟机的例子，你是懂幽默感的

我给你的这个例子是讲remedy 如何在编译期确定system 和component 的依赖性的，这个才是重点。因为很多ecs引擎对依赖性的检查是放在运行期，局限性和风险都很大。正好我们公司目前使用的自研ecs引擎就是在编译期静态检查依赖性，而我们的研发是从2020年开始的，可以说和remedy 是不谋而合

posted by wap, platform: Android

引用:

原帖由 @DKNYZK  于 2025-1-5 10:23 发表
xss 难道还不如 steam deck？

sd有16个g吧，我看到不少人还真用sd玩黑神话，我也是佩服的

posted by wap, platform: Chrome

引用:

原帖由 @MacPhisto  于 2025-1-5 15:22 发表
我给你的这个例子是讲remedy 如何在编译期确定system 和component 的依赖性的，这个才是重点。因为很多ecs引擎对依赖性的检查是放在运行期，局限性和风险都很大。正好我们公司目前使用的自研ecs引擎就是在编译期静态检查依赖性，而我们的研发是从2020年开始的，可以说和remedy 是不谋而合

我又没和你讨论ECS该怎么写，你一上来说虚幻gamethread多线程不方便内存不可控所以UE本质单线程，然后甩过来个阿兰醒醒的例子是需要ECS停下来单线程去跑LuaVM，这不纯纯搞笑么？按你分类方式这不更加单线程内存更加不可控？更何况ECS又不止system和component的依赖这一个问题。

233菜就别找理由，人都说自己没水平了还在洗啥

posted by wap, platform: Chrome

引用:

原帖由 @ginaamix  于 2025-1-5 18:53 发表
我又没和你讨论ECS该怎么写，你一上来说虚幻gamethread多线程不方便内存不可控所以UE本质单线程，然后甩过来个阿兰醒醒的例子是需要ECS停下来单线程去跑LuaVM，这不纯纯搞笑么？按你分类方式这不更加单线程内存更加不可控？更何况ECS又不止system和component的依赖这一个问题。

你对ecs 的理解有误。ecs并不是只有并行update，而是并行update 串行update 交替进行，因为concurrency 的本质是不确定性，所以为了在多线程环境下保证游戏逻辑deterministic，串行阶段是必要的。否则会导致相同的输入产生不同的输出，也就是代码行为的不可控，会带来很多问题，比如bug难以复现

我们公司的自研ecs 引擎就允许每个system做并行 串行 两种update，而且我们还提供了debug模式允许你用单线程运行ecs。具体到游戏脚本，如果你的项目选择lua 做脚本，又不是性能热点，切换回串行完全是可以接受的，毕竟你在这部分选择lua那就说明你看中的是快速迭代和方便易用，而不是实时性能。顽皮狗甚至用类lisp做脚本，这不代表他们引擎的技术含量低。事实上过去十年欧美ecs引擎的发展都离不开GDC 2015的Parallelizing the Naughty Dog Engine Using Fibers

本帖最后由 MacPhisto 于 2025-1-6 05:40 通过手机版编辑

posted by wap, platform: Chrome
前些年在国内某大厂做unreal 3a项目，为了性能优化，完全砍掉了apawn, uactorcomponent, uasset等垃圾，用自研的资源序列化代替，为的就是尽量避免uobject。如果不是aactor和其他unreal子系统的耦合过高，其实aactor也应该砍掉。blueprint这种垃圾脚本更是完全禁用，用自研脚本代替

当时内部交流得出的结论就是多线程性能优化这部分，国内至少落后欧美十五年。我觉得十五年也许有些夸大，但至少十年是有的

posted by wap, platform: Chrome
确定system和component的依赖性是非常重要的，这是并行update成立的前提。你不解决依赖性这个问题，那么结果就是要在运行期做各种双缓冲甚至三缓冲来避免race condition，增加了系统复杂度不说，还白白浪费了cpu和内存资源

之前那个国内大厂项目是在运行期检查依赖性(类似bungie在destiny的做法)，可以说比以前有进步，但结果很不理想，因为没有任何单元测试或者人肉qa可以在运行期覆盖到所有可能的代码路径和数据路径。也就无法实现真正的线程安全

实现了编译期静态检查依赖性之后，哪怕是初级程序员写出的业务逻辑代码也是线程安全的，你在运行期不必担心race conditon的风险，同时还减少了不必要的开销。这个技术并不是remedy首创，但真正production ready用在成品3a游戏应该是第一个。所以说remedy的northlight engine很强大，相比几年前顽皮狗和bungie的实现方法有了很大进步

本帖最后由 MacPhisto 于 2025-1-6 05:33 通过手机版编辑

posted by wap, platform: iPhone
xss设计相当失败，价格和性能非常尴尬。