3.6 UITransform的priority属性不能用了,新的方案是什么?

parent=xxxnode

你是没做过这样的游戏是吧?看到你这个回复我就不会再回复了

请你更新一下编程思想

你先顺着想,想不出正确的,再说它错

今年看到的最大笑话,用父节点控制层级来实现地下城与勇士这样的游戏

1赞

parent本身就是一种排序,之前引擎没有实现parent排序,现在实现了不是更方便了

这是笑话吗@jare

diff --git a/cocos/2d/framework/ui-transform.ts b/cocos/2d/framework/ui-transform.ts
index 4be2516f7..dfab34062 100644
--- a/cocos/2d/framework/ui-transform.ts
+++ b/cocos/2d/framework/ui-transform.ts
@@ -729,9 +729,10 @@ export class UITransform extends Component {
         }
     }
 
-    private static _sortChildrenSibling (node) {
+    private static _sortChildrenSibling (node: Node) {
         const siblings = node.children;
         if (siblings) {
+            // @ts-expect-error
             siblings.sort((a:Node, b:Node) => {
                 const aComp = a._uiProps.uiTransformComp;
                 const bComp = b._uiProps.uiTransformComp;
@@ -741,6 +742,9 @@ export class UITransform extends Component {
                 if (diff === 0) return a.getSiblingIndex() - b.getSiblingIndex();
                 return diff;
             });
+            for (let i = 0; i < siblings.length; ++i) {
+                siblings[i].setSiblingIndex(i);
+            }
         }
     }

我站你队,我就是部落冲突类型的游戏,强烈需要zIndex排序的,跟你杠的这个人,他就不知道假如45度2D游戏,战斗中实现士兵在地图中Y轴上下移动时刻改变层级时,使用setsiblingIndex是如何糟心烂肺的开发体验

哈哈,你每个帖子都要回复一下吗?在官方不太会改的情况下,只能自己封装下了

为了性能考虑,没有每个都排序,只改了当前变化的那个,且变化的这个已经加到了父节点

https://gitee.com/dream93/scl/blob/main/SCL.ts

2赞

请参考 3.7 setSiblingIndex 如何实现zindex
做引擎的人都是做过游戏的,这个无需多虑。

这个方案并不算好,设置一次sibling就for一次,尽管只排序当前Node,对于没有JIT加持的IOS也是一笔开销。
最好的方案是 在设定的帧数范围内,无论怎么修改zindex,达到设定帧数后,才执行一次整体刷新,比如每一秒 全局刷一次zIndex。这样才能应对大场景zIndex排序。
而setsibling只要调用,就会触发引擎的for循环等一系列排序的吧?没看setsibling的引擎代码,想象应该只要调用即触发排序。而且我也能想到,引擎一定没有提供整体刷新渲染顺序的接口,依然是单接口打天下。
之前因2.2 zindex性能不行,自己写过一次zindex,就是时间范围内怎么改都只做记录,最后才批量刷新zindex,后来官方优化了zindex性能,于是就不再用自己写的。
这3.x又开始唱setsibling,我是实在怕了,就想拿来就用就行了,因为我日常要开发、维护、策划、还要当客服,真的不想在某些地方钻研优化了,因为花了很多时间,做的还是之前已经做过的事,很不出活,关键是setsibling并不会带来多大的性能提升。
我是怕了,真的怕了

之前2.x有个版本zindex性能不佳,自己写了一个优化方式,即每x秒内,所有的zindex不真实奏效,只记录,达到设定时间后,整体刷新一次,也是修改引擎的方式实现的。
直到后来官方优化了zindex性能,我觉得性能表现挺优秀了,不会拖油瓶,所以我转变了想法,觉得某些地方还是官方最为擅长,因为自己写用了好几天一星期的时间,而官方的优化会让代码更规整,不凌乱,升级版本也无需再去调整引擎代码,直接升就行。我一直认为想做长久的游戏,所使用的引擎版本也必须时刻保持着更新。
无论是zindex,还是UITransform,我觉得转变的是引擎团队的设计理念,2.x时想的,是给保姆级的开发体验,毕竟小游戏居多,现在3.x所追求的,是3a,是大作,如果依然保姆级,对某些专业3a团队来说可能会显得臃肿。
但不能不管我们小制作人啊! [哭唧唧]

1赞

使用你的方案,ios也能合批了,只通过UITransform修改节点前后顺序并不会合批,setsibling才能合批,这意味着不入setsibling坑也不行了,必须使用setsibling,UITransform被废弃也是有原因的,独立于setsibling,又不能合批,单纯的进行前后排序,还是挺鸡肋的
谢谢你的方案,在ios试了下,并没有导致game logic有明显升高。

我这个可能适合首次就定好顺序或者后续每帧只有少数几个变动的场景,数量极多的话,可能做全排的性能更好

全排就要自定引擎,我是不给自己挖这个坑了。
能用就行,只要不拖后腿就行

感谢老铁,CC官方,把我的zIndex删了,2D的世界,我们需要一个zIndex来排序,而非3D的Z,首先是节点的排序,然后是同一层子节点的排序,如果有10000个,几十万个兄弟,可能也没那么费排序,当发现这些兄弟的需要排序时,我们通过ZINDEX 做计数/基数排序O(N+K)排好就行了,最好是发生在投递渲染数据的刚刚的那个前面,尽量少的内存拷贝与数据挪动,比如NODE的数据前面有个Z(INT)标记,投递数据前,拿这个ZINDEX做计数/基数排序O(N+K)排好

我后面重写了类似 zIndex 的机制,性能更好,可以自己下载下来试试

  • 使用方式:
    N(this.node).order_n = 100;
    
  • 源码
3赞

大佬 这个能改变节点全局的层级么?

如果你说的全局是指跨父节点的话,那么你的是特殊需求,用的人不多只能你自己实现,这个只是同级节点之间的排序