又是新的一周了呢。

1. UE4 feature level

       这周在测试UE4的材质的时候，发现的一个情况。我以前的blog中提过，UE4的feature level和实际的openGL版本无关，openGL ES2加几个扩展也能实现feature level ES31。不过，是所有支持openGL ES3.1的GPU就都支持feature level ES31了吗？还真不是。高通625的GPU adreno 506就不行。这个GPU虽然确实挺坑的，性能还不到Adreno 420的一半，但是我以前一直认为GPU出的越晚特性就越强。因为AN都是出一个完整规格再一刀一刀切，同一个世代虽然性能有差异但是支持的特性相同。想不到高通这边就来些骚操作。比如Adreno 506不支持GL_EXT_shader_io_blocks这个扩展，这也是其虽然支持openGL ES 3.1，但是并不能用UE4的feature level ES31。

2. UE4 blueprint

       要说这周最大的收获，应该就是用了半天时间，把蓝图的用法学明白了吧。在看Epic还有fmod的一些演示视频的时候，看到人家的工程师拖拖拖贼快，都眼花了，所以就真的研究了一下蓝图系统。一看，还真的被蓝图圈粉。以前被太多太多图形化编程语言荼毒过，以至于对蓝图有些抵触。必须向蓝图道歉。蓝图的开发效率，是真高。

       自己平时开发项目的时候，如果只改cpp文件，那还好，编译很快，就是link的时候费点劲，但是可能也要几十秒甚至数分钟。如果你动了头文件，那所有引用此文件的cpp都要重编译。如果你不小心动了csharp脚本，那你就惨了，cs脚本控制UE4预编译头(PCH)的行为，动了cs，就等着该模块，还有依赖该模块的模块都重新编译一遍吧。而蓝图就没有这些问题，当测试某些程序的时候修改起来看效果很快。

       蓝图不仅仅修改方便，写起来，还有运行起来都很快。

  1. 蓝图作为一个脚本语言，是强类型的。这就意味着参数输入或者接收返回值的时候，线连出来的那一刻，就能根据类型缩减可能需要语句的类型，提供比很多编程语言都要更精确更实用的提示。
  2. 在游戏运行中打开蓝图窗口，会直接进入debug模式。鼠标放在各个槽位上就可以查看各个槽的值。如果想精确到某一帧，只要在UE4 editor中按暂停即可。这个调试是不是很赞。
  3. 蓝图作为游戏的资源文件存在，而不是源文件。资源可以热更新。对于线上项目紧急bug可以用蓝图打临时补丁，下一个版本再用native code重写。这个思想和腾讯的xlua如出一辙。
  4. 蓝图可以编译成native code，可以获得和cpp代码近乎一致的运行速度

       蓝图还有一个优点，这是我(不得不)研究蓝图的原因，就是公司需求。公司使用lua作为业务层，而将引擎层和业务层划分上，UE4的蓝图就是很好的参考。并且，UE4的蓝图系统，其实是调用native的接口，所以可以通过蓝图的声明，依靠反射机制，快速自动化的完成c++到lua的绑定。怎么样，这个操作是不是很6。

3. 3D portable API

       2016年的SIGGRAPH上，Khronos Group提出了这个概念，希望能在DX12，vulkan和metal的基础上，再造一个能跨所有平台的高性能图形API。

       这个计划在2017年貌似被废止了。Khronos也从官方上删除了所有相关页面。仿佛这个提议从来就没存在过。

       不过，就在2018年的2月末，这件事迎来了转机。lunarG更新了vulkan SDK的1.0.69.0版本。添加了mac的vulkan支持。其实之前的moltenVK项目，就是以metal为底层，为mac何ios提供vulkan支持。而这次的lunarG SDK，也是直接使用了moltenVK的技术作为底层。以前moltenVK说希望引入lunarG的标准验证层，结果直接把自己引入到标准里了，这波操作666。

       现在，其实已经可以断言了，vulkan，已经实现了3D portable API当初设计时的目标。相信vulkan以后会有更好的发展。下一步，相信就是wasm + vulkan了(其实NXT已经进入可运行的状态了，只不过Google发现wasm比vulkan可玩性高多了，Google发现wasm的动态链接比.so文件强多了，正在计划用wasm代替.so做安卓的动态链接库呢)。