All posts by runner2011
关于屎山代码
业务逻辑代码有时候会成为接手的人觉得特别差的屎山代码。
多为以下原因:
- 第一手实现者,或因为能力或思考不足,设计实现问题
- 经多人经手,需求反复改,或赶deadline,先让功能工作起来,后期也没时间再优化
可能我们因为一些需求会需要修改屎山代码,个人经验,做优化的时候,步子不要迈太大,特别是遇到屎山代码的时候。不要一次优化原本内容,还同时也把看起来顺手就可以改的业务逻辑也优化了。特别是一些tricky代码,改了容易出一些特定条件的bug。还是分开一步步做比较好。
我不是说应该有屎山代码或为其辩护,只是说我们应该正确看待。
程序员应该还是要提高对自己的代码要求。但世间的事却又事多元化,就如当前语境下“圣母”带有贬义一样。
听说全球大公司微软内部也有一堆很多Could work但是程序员不想碰的屎山代码。
UE4迭代器删除元素
在一个Unreal Engine的项目中,发现TArray<AActor>迭代器循环,actor::destroy会在数组中移除该元素,和element.remove()一样, 引起迭代器失效,很奇怪。经调查原来是因为在Actor::endplay里代码把自身从数组中移除了。我因为之前没有在迭代器里删除过元素,在查这个Bug过程中,我看了下数组Remove的代码。

C++ vector::erase操作删除一个元素会导致后面所有的元素都会向前移动一个位置,这些元素的地址发生了变化,所以当前位置到容器末尾元素的所有迭代器全部失效。

这里,由于移除元素,移除元素后面的元素都向前移动,所以导致第二个元素3无法被移除掉。
3.18 Three TOPICS
Multiplayer networking with physics
https://ikrima.dev/ue4guide/networking/network-replication/physics-replication/
https://gamedev.stackexchange.com/questions/35459/multiplayer-networking-with-physics
Rendering thread
https://docs.unrealengine.com/4.27/en-US/ProgrammingAndScripting/Rendering/ThreadedRendering/
Explain P2P networking framework
This is a good example for explain P2P networking framework. Overall, No authority server in networking is P2P networking framework.
virtuos TGDC 2020 switch移植优化分享
维塔士上海技术总监Andy:Switch游戏优化经验分享
内存优化


去重复资源:贴图,shader,材质

贴图压缩格式:astc
限制最高mipmap
分辨率检查GBuffer内存布局,把不必要的效果的渲染缓冲去除掉
更激进的动画压缩算法
strip不必要的LOD
CPU

多线程渲染,对各个线程产生独立的命令缓冲

拆分render pass队列
拆分为多线程渲染,准备命令缓冲从20ms降低到6ms

GPU


Tegra GPU可以把渲染缓冲划分成很多图块,一个图块一个图块的播放渲染请求。可以提高命中cache。适用于大面积粒子效果。收集渲染命令和播放由一定开销。当使用大量的顶点属性或频繁修改属性时不建议使用。

模型、材质、粒子增加LOD使用
降低Shadow使用量
工具

最近的事
The sinking city Swith porting optimization
[UnrealFestOnline2020]如何将《沉没之城》移植到Switch
Characters optimization: Animation
Turn off physics clothing, saved over 20ms
Turn off per-bone motion blur on skeletal mesh components saved 0.5ms-2ms
Rendering



Code




create GC Uobject cluster: add more memory comsuption, but reduce the GC hitches.
十一月十四号的事
周六参加了一个小的行业分享会,好像说起来是我回成都后在成都参加的第一个外部的分享会。以下是我自己听后的理解,不全代表作者的观点。
第一个由邓春燕带来的《技术转型管理的思考》,分享了从做事、做人和思维上的转变。做事上,转型管理会有从管理自己到管理他人的转变。管理他人的前提是要先管理好自己。所以一个好的管理者,应有一个好的自我管理。春燕她自己一个时间管理,早上开会前和晚上6后是他的一个自我学习和工作总结的时间。如果做纯管理,思维上从技术性思维向一个商业性思维的转变,比如项目需要一个“天气系统”的考量。因为管理通常意味着更多的责任,自己做事的目的性会更强,遇到挫折更加坚韧。由于工作内容的转变,当然会有新的挑战,比如招聘。也会做一些以前不情愿做的事,比如辞退员工。
第二个是由Raynald Bouchard带来的《Focussing on Productivity》,分享了pipeline tool的重要性及育碧在优化pipeline上做的工作。主要集中在以下几点。
- 通过增加工具收集数据,特别是错误数据。分析pipeline瓶颈。降低相互等待的情况。
- 增加自动化工具,节约人力时间。
- 不断优化生产工具,更好用,更少的bug,让使用者专注于内容。
- 当下开放大世界越来越流行,做开放大世界,Split data对提升效率上是一个很重要的点,可以减少互相等待,及缩小反馈周期。
- 内容验证,越早越好。育碧尽可能的做内容验证,尽早发现错误。通常在生产者提交前就会做尽可能多的内容检查,比如美术内容有错误,不会被渲染出来。
邓春燕在分享开头提到了他们公司的类似“照扫建模”的技术,可以生成高质量高精度的模型,包括人物脸部模型用于游戏中。无独有偶最近我们公司美术师也在公司分享了照扫技术的应用。得益于当前计算机强大的计算能力,三维建模的工作量可以进一步降低。对照扫技术感兴趣可以看下开源的软件Meshroom。
Things new
- 最近在学UE4蓝图,学习UE4 蓝图最开始是抗拒的(笑),学会了,感觉用着还是蛮顺手的。不熟悉蓝图时感觉实现一个功能不如自己写代码快,很多简单的功能,自己写代码知道怎么做,用蓝图找模块网上查半天,而且觉得用蓝图的思维模式和写代码的思维模式还是有差别。当学会了蓝图,发现其实很多gameplay的功能比写代码快,因为功能模块的代码引擎帮你“复制”好了,不要自己再去复制自己的代码了(笑)。
- 用D3D DX12实现了一个3D BOX,成功显示出来效果很炫啊。都快忘了大学用OpenGL画一个图形的惊艳感了(那也算是自己的图形引擎第一步[笑])
六月五号的事
shader真是程序员的玩具,可以操控顶点位置,像素颜色,任意尝试,破坏,构建^_^