嗯。多谢提醒。
我的加班加点的意思,是指他中午不休息
关于预览资源加载速度的问题
感觉不是很好处理,如果预览要处理的话,等于资源系统需要将所有数据针对预览进行预处理~
这样反而会拖慢资源系统的响应。
比如原来拖入一张图片,只需要导入这张图。但加了预处理后,就需要预处理合图。只要合图里的一个资源变化了,都要重新处理。
这样开发过程体验到的感觉反而会变慢。
我们会想想有没有其他办法继续优化预览速度,大家如果有好的想法和建议,也欢迎留言给 creator 提意见吖~
果然是指望不上原生性能了,精力都在小游戏,不敢用了
小游戏性能也不行啊,这就是在小游戏上测试的
不得不说,我也陷入了深深的沉思中~
+1
赶脚楼主的测试方式很简单也很直接,既然发布版本提升性能,肯定是在发布之前测试了的,但是被这么直接了当的测试方式打脸,cc是不是现在搞花头搞的有点过了
这,。。。规避996,还是老板有招
首先问题确实存在,我们漏测了,在升级曲线数据之后,粒子的曲线数据量增涨,而且 instantiate 流程有变化,我们没有专门测试到粒子的实例化消耗。这个测试例中主要就是粒子的实例化。我们目前已经找到问题,在优化中,会在 3.3.1 修复这个加载问题。
很感谢题主及时的反馈,大家也不要误解这个问题的影响面,release note 中提到的性能优化也是我们测试过的。我们会增加测试例覆盖面,以后尽量少让大家陷入沉思,
不得不说,我不得不陷入了深深的迷思中…
"我们会增加测试例覆盖面,以后尽量少让大家陷入沉思,"有点意思,啊哈哈,看到这句话我觉得你人应该很好玩和幽默!象是那个开的起玩笑的人
别打击过度了,至少在HTML5小游戏IDE这一块,全球他们未逢敌手。大家行,大家上。
。。。我是真的夸。。。没有嘲讽
要怪就怪没有海外的已经开发好的英文版IDE能拿来汉化一下,如有,他们就能加速了。再起个名字,例如浑蒙。
请问这个有临时解决方案吗?能否给个临时修改的方案让我们自己改一下
如果只是预览慢的话,还可以接受啊
对给大家带来的影响感到十分抱歉,我们将在 3.3.1 修复此问题,
该主题在最后一个回复创建后14天后自动关闭。不再允许新的回复。