目测回不了本。
每个节点原先被每个摄像机遍历一次,改为用Map查询一次,但是Map的hashkey计算是要时间的,这个结构的时间复杂度常数就比较高。
每帧用Array重新组织所有节点,加重GC。
只适用于特定场合,比如所有节点layer都永远不变化的情况下做特殊优化。
目测回不了本。
每个节点原先被每个摄像机遍历一次,改为用Map查询一次,但是Map的hashkey计算是要时间的,这个结构的时间复杂度常数就比较高。
每帧用Array重新组织所有节点,加重GC。
只适用于特定场合,比如所有节点layer都永远不变化的情况下做特殊优化。
把性能分析测试结果发出来,有理有据让人信服,你就比天高比地厚就是神。
思路我觉得没问题,目前的无效遍历损耗确实存在
兄弟这还需要性能分享报告么。看代码就知道是无效循环。不要无脑喷呀
既然panda都说了那是在下错了
你说的问题也存在的,需要维护 model 的 layer 更新逻辑,这块少不了额外的事件监听和处理。map 的检索性能和节省的遍历比起来应该是有收益的。
题主的实现不一定是最合理的实现,但是在 TS 中减少 scene culling 的遍历肯定是有必要的
culling 能给个开关吗?
实际有些游戏,本来就一个范围全可见,
用户自己控制就好,减少损耗。
大佬可以提交一个pr,帮助引擎引改进一下性能。
你的帖子已经被社区标记并被临时隐藏。
我这个实现主要是想表示这个可以提前分组减少不必要的循环。如果不怕麻烦不用map其实一个32的数组就够了。毕竟只要32位layer就够了。之所以我回去深究这些点主要是最近在优化游戏性能。再优化完游戏逻辑后看到引擎底层还有这方面的浪费感觉挺可惜的。本身目前引擎性能还存在一定问题的情况下这种浪费我觉得是值得去细究的。毕竟这种改动不大但是收益是明显的。我也是被逼疯了。目前游戏render time iOS能有20ms感觉任何浪费我都想节省下来。也是希望引擎越来越好!
嗯嗯,理解,这个思路对于普通模型 model 问题不大,对于 2d draw batch 可能会有排序问题,还需要仔细推敲一下。这块是肯定需要优化的,不仅是场景的模型收集和剔除,更重要的还有光源和阴影的收集剔除。
也欢迎提交你的解决方案到仓库,我们也会给你审核和完整的反馈
谢谢楼主的建议,所有无关且无意义的争论已被删除
人家LZ发现了问题,发帖出来,不管怎么说,官方或开源贡献者首先应该与LZ沟通了解情况,而不是两句话一说就开嘴炮,就算是LZ最后的建议不被官方采纳,LZ也是一片好心,楼主一开始说话有点责怪的意思,但是事实就是这样啊,CC本来就在成长中,还有很多问题需要改进。人家抱怨一下也是正常的,像这样的BUG贴我感觉才是社区中对CC最有益的帖子,人家帮你找到了BUG你还喷了人家一脸,开源贡献者有点飘了,大神确实是大神,我也拜读过不少的帖子,但是大神+平易近人才是真正的大神
还好吧?这个帖子不是都在正常讨论问题吗,哪有开嘴炮的。。
被隐藏被删除
被删帖的就一个人,而且那个人是针对官方的,不是针对发帖人的
na,na,na,好一个“所有”,是怕别人觉得你们不够光明是吧?
有点意思,我可没对官方引擎有看法,官方论坛管理人员滥用职权倒是一如既往
论坛管理就是引擎官方呀,panda还不能代表cocos吗
为了避免误解再次借楼主的帖子解释一下,我完全赞同应该专注在问题和贡献的思路本身进行讨论,但其他人脱离主题就互相之间的措辞的讨论,甚至引申到完全无关的沟通话术上,使我觉得实在过于小肚鸡肠和失焦。就问题本身的抱怨我们是非常欢迎的,这确实是我们前进的动力。
最后,关于论坛的管理,我们确有主观因素,但主要诉求就是希望大家聚焦在问题本身,而不是论坛用户几个词语的措辞上,我没有袒护任何一方的意思,我真是觉得措辞上的问题不值一提,不应该冲淡问题本身的讨论。基于此我才删除之前的争论,不代表我认可任何一方。如果 AnkoGo 对我们论坛管理和态度的批评可以重开一贴,我非常欢迎也愿意加入讨论。
多一些互相理解,我们才能更好得成长。