(本文约 4500 字，阅读时间约 10 min)Visual Assist多年来始终是 Visual Studio 开发环境下的一款难以逾越的经典辅助插件。难得的是，这些年来它的重心一直围绕着 C++ 程序的编写辅助和增强。近年来，逐渐开放的微软加快了 Visual Studio 的演进速度，持续地吸收了不少 VA 的特性，但多年的积累使得 VA 的对应实现仍有着很强的竞争力。就拿代码重构里最基本的“重命名”来说，VA Rename 就比 VS Rename 步骤更少，速度更快，也更为方便和顺手一些。在上个月偶然间了解到新加的静态分析功能之后，我这两天下载了最新版本的 VA，发现比自己用了好一阵的老版本多了不少新东西，就想试着集中梳理一下。这篇文章里，那些经典功能如符号查找 (Find Symbols / Find References)，函数列表 (List Methods in File)，代码片段 (VA Snippets) 我就不再多说了，只是对相对较新的特性和技巧做了整理。特性和功能Code Inspection 静态分析和快速修正VA 开始支持基于 LLVM/Clang 的代码静态分析了。与 VS 原生的 Code Analysis 不同的是，VA 支持直接一键修复提示的问题。可以在汇总窗口里查看所有静态分析时找到的问题。并选中关心的项目，右键 “Apply Quic ...继续阅读 (4)

从 GDC 分享中汲取养分GDC Awkwardness Bingo board, @Sosowski on Twitterindienova 约我聊一下这个话题（开发者如何最大程度地利用 GDC 分享提高自己的技术水平？），我觉得灰常汗~ 因为我自己都还有一大摞 GDC Talks 等着翻牌子已经很久了。这些自己的存货都还没来得及消化吸收，更遑论为他人提供有效的利用方法——实在汗颜。也正是因为 GDC Vault 的免费内容不少，虽然明知收费的里面有价值的内容更多，也还是几次三番地压抑着自己购买年费会员的冲动。本文 6000 字左右，阅读时间 15 分钟。BTW, 如果没有细看开头图上的字，现在可以翻上去看一下——比正文有趣得太多，凡是参加过这类会议的同学，都会会心一笑吧~首先想说一下参加行业会议（包括 GDC）的一个感受：坦白地说，如果觉得经常参与各色的行业会议，就仿佛能从演讲者身上快速获取价值，直接转化到自身的业务水平和技能提高上，那一定是种错觉。这就好像整天刷知乎，仿佛动动手指就能把大V们的见解化为己用，其实是一样的迷思。原因很简单——招式虽可模仿，但若缺乏内功和心法的支撑，一味地追求好的工具和方法，只会变成中看不中用的花架子（这方面我自己有深刻的教训和体会）。所以我们不要学 xx 记者，水平有限，但是跑的比谁都快。那么内功从哪里来呢？多看书，提高理论水平；多写代码，提高实 ...继续阅读 (5)

上一次参加 GDC 是在七年前。有趣的是，2010 那年，John Carmack 获得了终生成就奖 (Lifetime Achievement Award)；而 2017 年的 GDC 上，获得这个奖项的是 Tim Sweeney。这是两位真正的行业传奇。他们的代码，令我满心钦佩且受教良多。这一篇快速记录中，我粗粗地整理了一下自己听过的演讲，并把那些觉得很有收获的标注了一下。还有不少演讲是因为分身乏术错过的，这里也一并记了，这样晚些时候可以到 GDC Vault 里去听回放。维护和更新地址：(github.com) dev-awesomenesses/awesome-gdc17还有一个半小时的访谈，是陈杰老师和我一起最后一天晚上做的。头一次上镜头，感觉自己不忍直视 (捂脸逃~~对内容感兴趣又不想花时间看视频的同学，可以扫视下面的零散文字——这其实是我在录节目前记录的一些简短脚本 (就在我手上端着的 Surface 里)。GDC17 总体感觉：严谨传统 hack -> 规模越来越大，复杂度 hold 不住 -> 机器性能的提高使得不少 hack 不再有意义 -> 通过严谨的设计来简化问题主要分享三堂课内容：英雄联盟的制作守望先锋的逻辑状态和同步寒霜引擎的图形渲染架构改造1. (LOL) 游戏制作 Productiona. 英雄的制作 (DNA)新做的内容需要先把握好 DNA，这样你 ...继续阅读 (8)

关于 Unity 的垃圾回收 (GC) 你可能已经看到不少的文章讨论了。下面是一个极简形式的 Cheatsheet，希望能在最小的篇幅内尽可能全面地列出关于 GC 你需要注意的事项。Unity GC Cheatsheeta01. struct Foo 在栈上，但 struct Foo[] 分配在堆上a02. GetType() 会产生 GC Alloc (每个调用 20 Bytes)a03. delegate 的创建时 (赋值 = 或以参数传递) 在堆上分配 (如将方法做为参数传入)a04. delegate 尽量使用 = 而不是 += (后者会导致 InvocationList 不断增长且会被调用多次)a05. 在针对 GC Alloc 做优化时，对象数量 > 引用关系复杂度 > 对象尺寸a06. 当可以使用整数句柄来代替引用时，尽量使用整数句柄 (简化引用关系)a07. 优化内存布局：利用“数组对 GC 而言是单一对象”这一特性a08. (a01推广) 单个 ValueType 直接在栈上分配，但 ValueType Array 总是分配在堆上b01. 避免频繁调用分配内存的 accessors (如 .vertices/.normals/.uvs/.bones)b02. 避免频繁调用 Int.ToString() 及其它类型的衍生b03. 避免在 Update() 内使用Ga ...继续阅读 (5)

[按] 此文内容摘自《王朝的家底》第一篇：三千年的粮仓保卫战。标题和其他非原文部分为笔记，文内不再另行区分。《王朝的家底》第一篇：三千年的粮仓保卫战从狗尾巴草说起狗尾巴草是（中国古代一种重要农作物）粟（谷子，小米粥）的祖本植物。狗尾巴草是粟的野生种，也叫“莠”（二者刚长出的幼苗很难区分，所以有“良莠不分”的说法）粟（谷子），黍（黄米）和菽（大豆），读音相近，最重要的共同点是耐旱耐贫瘠，是先秦时期最重要的农作物。他们生长期短，适合北方旱地，所以率先从百草中脱颖而出。夏朝和商朝曾被称为“粟文化”的王朝。在那以后，随着人口增加，需要开垦更多的荒地，来种植产量更大的作物。小麦：秦国崛起，文景之治和农民起义小麦的故乡在西亚，在距今3800年前经由新疆传入我国。由于我国北方是温带季风气候，春季较为干旱，而小麦更适应地中海气候，刚来时“水土不服 ”，有了大规模灌溉，保证水分充足之后，产量才把粟远远地抛在后面。在战国七雄中，秦国地处西方，最早接触小麦，而且渭河冲积形成的关中平原很适合种植小麦，当时的国家力量也发展到能够组织大量人力来兴修水利（郑国渠）。所以后来秦国有实力连年征战，最终一统天下，是有充足的物质基础的。后人评价文景之治，大多归功于战乱平息后政治稳定、皇帝以身作则勤俭持家、减轻农民的赋税徭役等因素。这些解释固然都有道理，但我们应该关注更为主要的一个原因，那就是小麦的广泛种植。（盐碱化）种 ...继续阅读 (4)

[按] 此文内容摘自《王朝的家底》第一篇：“三千年的粮仓保卫战”。标题和其他非原文部分为笔记，文内不再另行区分。从狗尾巴草说起狗尾巴草是（中国古代一种重要农作物）粟（谷子，小米粥）的祖本植物。狗尾巴草是粟的野生种，也叫“莠”（二者刚长出的幼苗很难区分，所以有“良莠不分”的说法）粟（谷子），黍（黄米）和菽（大豆），读音相近，最重要的共同点是耐旱耐贫瘠，是先秦时期最重要的农作物。他们生长期短，适合北方旱地，所以率先从百草中脱颖而出。夏朝和商朝曾被称为“粟文化”的王朝。在那以后，随着人口增加，需要开垦更多的荒地，来种植产量更大的作物。小麦：秦国崛起，文景之治和农民起义小麦的故乡在西亚，在距今3800年前经由新疆传入我国。由于我国北方是温带季风气候，春季较为干旱，而小麦更适应地中海气候，刚来时“水土不服 ”，有了大规模灌溉，保证水分充足之后，产量才把粟远远地抛在后面。在战国七雄中， 秦国地处西方，最早接触小麦，而且渭河冲积形成的关中平原很适合种植小麦，当时的国家力量也发展到能够组织大量人力来兴修水利（郑国渠）。所以后来秦国有实力连年征战，最终一统天下，是有充足的物质基础的。后人评价文景之治，大多归功于战乱平息后政治稳定、皇帝以身作则勤俭持家、减轻农民的赋税徭役等因素。这些解释固然都有道理，但我们应该关注更为主要的一个原因，那就是小麦的广泛种植。（盐碱化）种小麦的地区，不论是关中平原，还是后 ...继续阅读 (21)

Unity 的开源内存分析工具MemoryProfiler非常有用，可以提供所有由 Unity 分配的 C++ 对象的内存信息，在该工具内被称为NativeUnityEngineObject(Native-only Mode)。当 C# 脚本经由 il2cpp 编译为 C++ 时，此工具可以提供额外的所有 C# 对象的信息，在该工具内被称为ManagedObject(Full Mode)。本文简单地描述了该工具的工作机制，并探讨了一下基于该工具的一些可能的改进。工作机制这个工具中所能提供的所有的内存数据均来源于一个 Unity API：UnityEditor.MemoryProfiler.MemorySnapshot.RequestNewSnapshot();通过调用这个函数，我们可以向一个运行着的 Unity 程序请求一个新的内存快照。如果是运行于编辑器内的程序，该请求同步地返回上面说到的 Native-only Mode 数据；如果是运行于 iOS 上的基于 il2cpp 的应用，该请求异步地返回上面说到的 Full Mode 数据。刚收到的快照存在于下面这个紧凑数据对象里：publicclassPackedMemorySnapshot{publicConnection[]connections{get;}publicPackedGCHandle[]gcHandles{get; ...继续阅读 (28)

[按] 在上个月 [2016-12-17] 的 2016 金山技术开放日上，俺做了一个游戏引擎相关的分享。结束之后，俺断断续续地在零碎时间里把分享的内容整理了一下，为每张幻灯片配上了简单的文字注解，就形成了这篇小结。参与了现场交流的同学可能会发现，这篇文字版跟现场版相比，虽然幻灯片保持原状，但文字注解部分略有出入 (增加的内容主要是第二部分“评估，运用和改造”，这一部分在现场时因为时间关系说得非常简略)，还请见谅。内容提纲游戏引擎的十年变迁 (2006-2016)(对过去十年的游戏引擎发展的简要小结)游戏引擎的评估，运用和改造(对一次技术迭代周期内的主要实践的归纳)游戏引擎的下一个十年(一些很零碎的对未来十年可能值得深入的技术的思考和启发点)第一部分：游戏引擎的十年变迁 (2006-2016)在这次分享中，我着重对比了个人相对有所了解的五款商业引擎，分别是 Unity、Unreal、CryEngine、Gamebryo 和 Torque。而下面划掉的开源引擎 OGRE/Irrlicht/cocos2d-x 性质不同，放在一起对比并不公平，所以排除在这一回讨论的范围以外。前几个 (Unity、Unreal、CryEngine) 比较知名，就不多做介绍了。这里简单介绍一下 Gamebryo 和 Torque。Gamebryo 是当年 (2007-2010) 国内非常流行的商业引擎之一， ...继续阅读 (7)

协程 (Coroutine) 是大部分现代编程环境都提供的一个非常有用的机制。它允许我们把不同时刻发生的行为，在代码中以线性的方式聚合起来。与基于事件与回调的系统相比，以协程方式组织的业务逻辑，可读性相对好一些。Unity 内的协程实现是传统协程的简化——在主线程内每一帧给定的时间点上，引擎通过一定的调度机制来唤醒和执行满足条件的协程，以实际上的分时串行化执行回避了协程之间的通信问题。但由于种种因素，协程的执行情况对程序员而言相对不那么透明，可以通过一些简单的机制来对其进行监控和优化。Warm up: 从复用 Yield 对象说起先从一个最简单而直接的改进开始吧。下面一个在每帧结束时执行的协程的例子：voidStart(){StartCoroutine(OnEndOfFrame());}IEnumeratorOnEndOfFrame(){yieldreturnnull;while(true){//Debug.LogFormat("Called on EndOfFrame.");yieldreturnnewWaitForEndOfFrame();}}在 Profiler 内可以看到，上面的代码会导致WaitForEndOfFrame对象的每帧分配，给 GC 增加负担。假设游戏内有 10 个活跃协程，运行在 60 fps，那么每秒钟的 GC 增量负担是10 * 60 ...继续阅读 (5)

[按] 本文刊发于《程序员》2016年12月，转载请与该刊物联系。年度 VR 盛会 Oculus Connect 3 上，Michael Abrash 和 John Carmack 和往年一样带来了精彩的演讲。和以往一样，Abrash 的发言以前瞻性的研究和底层技术发展趋势为主，而Carmack 的发言一如既往地更关注在当下的平台上 (主要是移动 VR)，通过工程化努力可以把交互和应用做到什么程度。本篇主要包含了与 Michael Abrash 的演讲相关的内容。回顾开始之前，我们先简单回顾一下 Abrash 在近三年前 (2014年1月) 的Steam Dev Days 2014上曾作出的判断和预测——在名为"What VR Could, Should, and Almost Certainly Will Be within Two Years"的演讲中，Abrash 的开场白就说到 “Compelling consumer-priced VR hardware is coming, probably within two years” ("消费级 VR 硬件将会在两年内出现")。而正是两年后的 2016 年，三大厂商都把自己的产品送到了消费者手中。下面这些是当时的部分辑录，而括号内是实际发生的情况。"We strongly be ...继续阅读 (3)

tl;dr ("Too long; didn’t read.")信息过载是我们每天都要面对的问题。有趣的是，随着信息鉴别，过滤，处理能力的提高，我们往往不自觉地会延展自己的信息渠道（新 app、新 feed 和新的公众号，等等），接着让自己陷入更大的信息漩涡——明明是效率提高了，吞吐量增大了，为什么好像每个人都更加不堪重负了？It's not information overload. It's filter failure.Clay Shirky, excerpted fromInformation overload (Wikipedia)在即将过去的 2016 年，我形成了一些小习惯，帮助自己更好地应对信息过载的难题。整理一下，分享给有同样困扰的同学。本文中，我会列出一些自己觉得好用的小技巧，然后是作为容器的信息库的分拣标准，最后谈一下我是如何用最低的时间成本去维护这套体系的。tl;dr- (chiefly Internet) "Too long; didn’t read." Used to indicate that one did not read a (long) text, or to introduce a short summary of an overly long text.Excerpted fromtl;dr (Wik ...继续阅读 (2)

Unity 游戏的 string interning 优化问题描述在开始之前，先说一下这个问题为什么很容易被忽视吧。正常情况下，我们通常难以注意到运行着的 Unity 程序内 string 的实例化情况。这些字符串的创建，销毁的时机是否合理，是否存在有重复 (相同内容的字符串)，冗余 (存有已不再有意义的垃圾字符)，低效 (capacity 远大于 length)，以及泄漏 (没有在期望的时机及时销毁) 的情况就更容易被忽视了。由于 string 没法随时像普通的 Unity 对象那样通过调用Object.GetInstanceID()来查看实例id，我们不太容易感知字符串对象的实际内存开销。其实要不是偶然在工具里发现了大量的此类情况，俺也没想到看起来颇单纯的 immutable string 里居然隐藏着这么多秘密。一次只说一件事，这次我们只讨论重复字符串的问题。使用自制工具ResourceTracker，可以发现 Unity 游戏运行时 mono(il2cpp) 内有大量重复的字符串，如下所示：手动 Intern()对 .Net 特性有了解的同学，应该知道 C# 同 Java 一样，提供了一套内建的 string interning 机制，能够在后台维护一个字符串池，从而保证让同样内容的字符串始终复用同一个对象。这么做有两个好处，一个是节省了内存 (重复字符串越多，内存节省量越 ...继续阅读 (3)

题图引自timestamp.io上周在知乎上答了一题：日常生活中有哪些十分钟就能学会并可以终生受用的技能？说一个微不足道只要 1 分钟就能 get 的小玩意，但是没想到真正改变了我的工作习惯，每天都要用到数十次。我有一个开机启动的 AutoHotkey 脚本，里面设置了一些常用的环境配置，这样每到新的机器上直接把这个文件拖过来双击一下就是自己熟悉的环境了。这个脚本里其他的就不说了，下面三个快捷输入的使用频率最高：::[d::FormatTime,DateString,,[yyyy-MM-dd]SendInput%DateString%return::[t::FormatTime,TimeString,,[yyyy-MM-ddHH:mm]SendInput%TimeString%return::[s::FormatTime,TimeString,,[HH:mm]SendInput%TimeString%return它们的作用分别是：当输入[d时回车，能够自动展开成当天的日期 [2016-10-28][t和[s分别展开成 [2016-10-28 09:06] 和 [09:06]d, t, s 分别是 data/time/short 的首字母，当然也可以是别的字母好了，到这里就具备随时随地对你经手的任意材料任意信息秒打时间戳的能力了。虽然刚开始这么做的时候一点也没意识到，但现在回过头来看 ...继续阅读 (2)

用了两个周末，快速过了一遍 CppCon 2016 的 112 个演讲，筛出了下面我觉得最有价值的 18 个 (其中有八个 must-reads 标注了星号)。文档的实际链接地址是：https://github.com/mc-gulu/dev-awesomenesses/blob/master/awesome-cppcon.md为了方便查看，这里直接使用该页面的截图 (如无意外不会更新)。在awesome-cppcon页面中，也包含了 CppCon 2014 时我挑出的 10 个值得一看的演讲及其它的相关信息。后续的更新和问题修复也都会出现在那里。下面挑了几张图，没有时间去看列表的同学可以随便翻翻感受一下。The roots of C++- 一张图展示 C++ 的来源Major Design Decisions- How does it change the way we write code?#C++ users- C++用户量的历史增长情况 (I)#C++ users- C++用户量的历史增长情况 (II)uftrace- A function graph tracer for userspace programsLock Analyzer- Rainbow Six Siege - Quest for PerformanceSingle Source Compilation M ...继续阅读 (3)

本文是我昨晚在知乎上的一个回答：程序员工作中占时间最长的是哪个步骤？下面的图表是我个人工作十年以来各项时间占用的大致变化情况。需要说明的是，这不是由精确的统计汇总而来，而只是大致估算；不是我认为理想的情况，而只是此期间实际发生的情况。(设计和实现) 长期来看，你愿意花在设计和实现的时间，基本上取决于你对这项工作的热爱程度。我见过一些进入管理岗位的同事，这两项迅速地滑落至接近 0 的；也见过始终对编码本身情有独钟的——这并没有对错，只是不同个体的兴趣，权衡和选择。(测试和调试) 总得来说，随着工程能力的提高，程序员的职业生涯里的测试和调试时间应该是稳步降低的。基本上你总是能把越来越多本来需要手动完成的事情交给机器去做，比如包括运行整个游戏流程和查看渲染效果这类本来需要人来做的事情，运用恰当的脚本和图像对比手段，在绝大部分情况下都能比人做得更快更好。(沟通) 沟通需要单独拎出来说一下。随着时间推移，不管是否情愿，用于沟通的时间应该是逐渐增加的。但当接近或到达一个分水岭 (对我来说是 C 阶段的 50%) 时，我意识到如果不做点什么，很快会演变成做一整天讨论，只有晚上瞅着空写写代码的凄惨结局，于是学着不断地有意识地限制沟通的频率和长度，利用各种策略来避免无效的沟通，到现阶段能大致控制在工作时间的 1/3 左右。关于几个阶段，简单补充说明一下，阶段 A 时我刚刚毕业入行，在一家外企做普通程 ...继续阅读 (7)

昨天遇到了一个 C# DLL 动态载入后调试信息缺失的问题，今天上午解决后记录一下，以便遇到这个问题的同学可以参考。（注）此文中的截图内文字偏小，可以 Ctrl + 鼠标滚轮放大查看。问题描述我们知道，Unity 中的Debug.Log()系列函数不仅能输出用户内容，而且能通过类似StackTraceUtility.ExtractStackTrace()这样的机制把该输出对应的堆栈打出来；当用户代码出现未捕获异常时，Unity 也会利用该机制输出异常及相关的完整堆栈信息。如这个函数：voidPrintStacktraceOrdinary(){Debug.LogFormat("Stacktrace (ordinary): \n{0}",Environment.StackTrace);}会输出下面的结果：注意，此图中 StackTrace 上的每个函数都有完整的调试信息（函数，源文件，行号）。但是，当调用链中有一部分位于一个外部 DLL 中时，位于外部 DLL 中的这一部分函数调用，是无法像正常的函数那样显示堆栈的。如下面位于单独 DLL 的函数：namespacetest_stacktrace_dll{publicclassFoo{publicstaticstringGetStacktraceInDLL(){returnEnvironment.StackTrace ...继续阅读 (6)

(3/3) DOOM3 网络架构本文是系列的第三篇：DOOM3 技术点滴DOOM/Quake I/II/III 网络模型的演化DOOM3 网络架构本文绝大部分为较简短的记录，进一步的描述请参考原文。架构客户端把输入采样等玩家动作发给服务器，服务器回之以 PVS 内的压缩后的状态快照。C/S 架构图Doom3 做到了同样的玩家输入序列总是能产生同样的结果，因为以下两点得到了保证：除玩家输入外整个系统的确定性 (system-wide deterministic)不管渲染性能如何，整个游戏的逻辑状态总是以 60 fps 的频率更新C/S 时间线服务器以 10-20 Hz 的频率向客户端发状态快照。由于快照是一个 rtt 之前的状态，客户端需要回到那个时间点上去处理这个“过去的”状态，然后再基于这个状态重新预测并刷新所有物体在当下的状态，如下图：预测示意图(Prediction at the client with a snapshot rate at 20Hz and a ping of around 80 milliseconds)由于玩家输入的频率 (input per second) 远低于逻辑处理的频率 (60 Hz)，一个合理的推论是，最接近当下的几个逻辑帧，继续沿用与之前同样的输入一般是安全的。客户端使用服务器同步过来的其他玩家的输入来预测其接下来的运动，这些物理响应的机制 ...继续阅读 (1)

(2/n) DOOM/Quake I/II/III 网络模型的演化这一篇是上一篇DOOM3 技术点滴的自然延续，但内容上独立成篇，实际上描述了 id software 从 DOOM 1 开始的若干款 FPS 游戏在网络架构方面的演化。同样的，更多的细节可参考这里和 Quake III Arena 网络协议规范(非官方) (看起来在互联网上已经找不到链接了)。本文是系列的第二篇：DOOM3 技术点滴DOOM/Quake I/II/III 网络模型的演化(后续 Posts 补齐中...)一般性说明游戏网络架构通常体现在四个要素的平衡上：一致性，响应性，带宽，延迟 (consistency, responsiveness, bandwidth and latency requirements)“Multiplayer gaming is aboutshared reality.”FPS 游戏的状态通常表现为一个实体列表：玩家，怪物，导弹，门等，这些实体 (entities) 与其全部作为不同的元素去区分对待，不如提供一个公共的结构和接口来简化通信。“Networking in first person shooters is all about synchronizing the state of multiple copies of the same game entities suc ...继续阅读 (16)

DOOM3 技术点滴今天下午读到一组 DOOM 3 相关的技术文章，这些文章描述的是十年前 (2006) 的技术，但依然有较强的参考价值。其中的一份技术记录描述了 DOOM3 BFG 开发过程中遇到的一些特定的性能问题。这里的记录和描述非常简略和仓促，更详细的解释可参考原文。[注] DOOM3 BFG 是 DOOM3 的全平台资料片。技术背景DOOM3 在发售时 (2004) 的性能状况是，在最低配的机器上效果全关 640*480 的情况下维持在 20fps，而资料片 DOOM 3 BFG 的目标是在 2012 年的机器上 1280*720 下平稳地地运行在 60 fps 上，这意味着使用原版的 1/3 的时间绘制 3 倍于原版的像素数量。硬件变化上，这些年中 CPU 频率变化不大，但多核化使得多线程能够更有效率 (而 DOOM3 原版是单线程)；GPU 发展很快，使用新功能来优化特定的渲染特性 (比如用 coarse Z-Cull / Hierarchical-Z 来优化 Stencil Shadow Volumes)就很重要；内存的性能提高不大，导致单次内存访问对应的可执行指令数提高了，利用这一点可以做很多对应的优化。内存约束从 DOOM3 到 DOOM3 BFG 的一大困扰是缓存颠簸 (cache thrashing)，由于 DOOM 的光影模型及由此导致的特殊的内存访问模式 ...继续阅读 (20)

这是(Youtube) Blizzcon 2015 Engineering Community Amphitheater Discussion的部分内容。挑了重点，简单记录了一下。设计和工程风暴英雄的数据驱动做得很好 (因此设计自由度很大)。在这样灵活度的支持下，设计师在 Blizzcon 上想搞个大新闻：两个不同的玩家可以控制同一个英雄。程序员们一听都慌了，后来想了想，搞定了。工程师们不会随便说“这不行”，要想让设计师们尽情发挥就不该随便说 No ——尤其是你要是不给弄，设计师们分分钟自给自足把自己的需求给实现了(掩面)。有张图 (此处应有图) 上画的是，一个垃圾桶上放了个插着电的熨斗，熨斗上放了咖啡壶，咖啡壶里装着意大利面。duang, 搞定，意大利面做成了~守望先锋有 “strike team” 内含来自不同部门的 n 个人 (Gameplay/Engine/Designer/Animator/FX Artist) 在一起配合完成一个功能 (通常是某个特定的英雄，如 Hanzo) 这些人一起配合，把一个特性打造到极致。(下一条紧接着说的是 —— 即使这样，D.Va 还是很难搞，花了 n 个月 —— There are two types of heroes in Overwatch: D.Va and not D.Va.)从工程师的角度，寻找并解决设计师的痛点很重要 (就像产 ...继续阅读 (41)

问题描述Unity 项目在实践中往往选择使用 Lua 作为更上层的逻辑脚本。这一方面是由于 Unity 本身对热更不是很友好，用 Lua 热更灵活得多，另一方面也是简化与服务器共享代码和数据。目前多种不同的 Unity + Lua 集成方案中，实践中采用比较多的是庞巍伟同学的slua方案。使用 Lua 的团队，往往倾向于“较重的”集成，也就是暴露相当大规模的引擎接口给 Lua，这样逻辑上才能有足够的自由度对游戏和引擎做全面的控制。当 C#/Lua 之间的互操作接口迅速增长到成千上万的数量时，一个重要的问题就会浮现出来：C# 和 Lua 的交互层对引擎是封闭的，很多引擎内建的工具，没有办法跨越宿主 (C#) 和脚本 (Lua) 的边界。这些受到影响的机制里，最重要的就是 Unity Profiler。Unity Profiler 是 Unity 提供的一个有力的性能分析工具 ，能够在优化阶段有效地帮助定位瓶颈，有时也容易借机发现一些潜藏的 bug。而当我们定位到某个 Lua 函数有较大的开销（CPU 或内存 GC Alloc）时，由于跨语言边界的影响被阻拦，就难以进一步观察更多的细节。“正常的”做法由于 Profiler 的 API 接口也一并暴露给了脚本，正常的做法是：根据 C# 这边的有问题的调用，翻到对应的 Lua 代码，把相关的脚本逻辑读一遍，为那些潜在的开销大的逻辑添加对应 ...继续阅读 (29)

在 C++ 和 Lua 协作时，双方的互调用是一个绕不开的话题。通常情况下，我们直接使用 Lua/C API 就可以完成普通的参数传递过程。但在代码中直接操作 lua stack，容易写出繁冗和重复的代码。这时我们往往会借助 tolua++ 之类的库，把参数传递的工作自动化，降低负担。进一步讲，由于 Lua 的参数传递在个数和类型上非常灵活（任何一个函数可以传递任意个数和类型的参数），有时我们会希望在与 C++ 的互操作时保留这种灵活性，比如 C++ 向 Lua 发一个消息时，如果可以是一个消息 ID 带上任意数量和类型的参数，就会很方便（反过来也一样）。由于 C++ 能通过可变参的模板函数实现类型安全的参数传递，与 Lua 的动态参数列表相结合后，我们就能在一个接口上实现更大的跨语言自由度。有不少第三方库能够简化 C++ 和 Lua 之间的互调用，这次我们使用 LuaBridge 来完成工作。开始前我们先介绍一下普通的互调用怎么做。首先，从 C++ 调 Lua 的函数：-- lua sidefunctionfoo(str,i,f)returnstring.format("%s, %d, %f",str,i,f)end// C sideluabridge::LuaReffoo=luabridge::getGlobal(L,'foo');autoretString ...继续阅读 (14)

这是一篇看过@顾煜老师的信息过载和@陈章鱼老师的独孤求败的剑冢，和时间管理的书单后有感的 reblog，主题可能稍有呼应但略有不同，不管啦~~工作十年来，我在看待自己的时间上，大致有下面的三个阶段：唯快不破刚毕业没几年的自己，飞扬跳脱，总会试着以最快的速度完成手头的任务，正如对代码的优化那样，对时间管理效率的追求没有止境。简单地说，没有最快，只有更快。什么，你说实现这个系统只需要一周？No，我只需要三天。这个阶段的我，对时间的认识就像是待挤的海绵——时间就像xx，挤一挤总是有的，对吧~~分拣梳理后来我意识到，快是有代价的。当你在高速公路上开的越来越快时，两旁飞快重复和闪退的街景会降低你的反应，你的视野会变得越来越狭窄，如果不能学会控制和驾驭，那么翻车是迟早的。在这个阶段，我学会了把不同的事情区分开，梳理暗流和分岔，在工作和生活中保持稳定的节奏。要同时面对多个任务？没关系，良好的隔离让它们不会互相影响，顾此失彼。处理不好工作和生活的平衡？没关系，上班前旋转起你的“陀螺”，下班时别忘了清理你的“回收站”。顺其自然，肆意流淌再后来，三十岁慢慢近了。一直以来，为了“醒转来生活（wake-up-and-live）”，我一直是“工作和生活应当很好地分离”的拥护者，认为工作时间和私人生活不应互相侵占。后来我逐渐领悟到，如果说生活是一幅不断变动的大油画，那么工作应该是有机地融入这幅大油画中的一个角 ...继续阅读 (31)

昨天在飞机上读完《京华烟云》，余味掩卷不散，顺手整理了一下笔记。关于《京华烟云》 （林语堂长女林如斯）（节选）...我知道父亲每晨著作总是起来走走吃吃水果，当他写完红玉之死，父亲取出手帕擦擦眼睛而笑道：“古今至文皆血泪所写成，今流泪，必至文也。”有情感又何妨。《京华烟云》在实际上的贡献，是介绍中国社会于西洋人。几十本关系中国的书，不如一本道地中国书来得有效。关于中国的书犹如从门外伸头探入中国社会，而描写中国的书却犹如请你进去，登堂入室，随你东西散步，领赏景致，叫你同中国人一起过日子，一起欢快，愤怒。...你一翻开来，起初觉得如奔涛，然后觉得幽妙，流动，其次觉得悲哀，最后觉得雷雨前之暗淡风云，到收场雷声霹雳，伟大壮丽，悠然而止。留给读者细嚼余味，忽恍然大悟；何为人生，何为梦也。而我乃称叹叫绝也！未知他人读毕有此感觉否？故此书非小说而已！或可说，“浮生若梦”是此书之主旨。...此书的第三部题为“秋季歌声”（即第三个题目），取庄周“臭腐化为神奇，神奇化为臭腐”，生死循环之道为宗旨：秋天树叶衰落之时，春已开始，起伏循环，天道也。故第三卷描写战争，可谓即描写旧中国的衰老，就是新中国的萌芽。故书中有“晚秋落叶声中，可听出新春的调子，及将来夏季的强壮曲拍”等语。...木兰的生活变迁，也很值得研究：从富家生长享用一切物质的安适，后变为村妇，过幽雅山居的生活，及最后变为普通农民，成为忍苦，勇敢，伟大 ...继续阅读 (7)

此文写于大约两年前 ([2014-07-13])，整理旧文档时发现的。和孩子一起长大不知不觉，儿子已经三岁半了。随着他的日渐成长，我越来越觉得有必要，把成长过程中一些经验，教训和弯路记录下来，也算是一份小小的成长记录吧。跟我小时候“略微内向腼腆，对外界以顺应为主”不同，想想是一个倔强，顽皮, 颇有主见的孩子。记得半年前还在上海的时候，有一次带他去那种充气的儿童乐园玩，里面是各种充气的小房子和滑梯。想想和比他高一个头的孩子们一起爬充气滑梯，那些孩子三两下就爬上去了，他折腾了半天还在原地。我在旁边看了一会儿，想伸手帮帮他，结果他果断地把我的手推开，一脸“我就不信这个邪”的表情，在那儿满头大汗地扑腾，各种姿势各种摔倒，十五分钟后，终于全身湿透地站在了滑梯顶上。我瞬间眼泪就出来了。有时，这种倔强会显得很任性。作为家长，什么时候应该鼓励，什么时候应该劝阻，甚至制止，中间的界限很微妙，大部分时候都很难找到一个简单的原则去处理。不过我发现，只要能始终做到平等沟通和耐心引导，很多时候就能妥善化解，如果做不到这两点，往往就会以一场哭闹收尾。以前在小足迹上托班的时候，每天放学一定要到地下车库去看车，坐电梯一定要自己按楼层按钮，坐车一定要自己关车门，都是这样。很多生活琐事的处理看似影响不大，其实知易行难，细究起来，真实生活从来都由不得照搬书上的最佳实践。作为父母，我们在成年人的世界里待得太久，经常会在不 ...继续阅读 (7)

需求在使用 ndk 做 Android 开发时，一件比较麻烦的事情是编译脚本 (也就是 Android.mk 和 Application.mk ) 的维护工作。今天尝试了一下把这个维护的工作自动化，完成以后简单记录一下。在日常工作里我尝试过不少生成脚本的自动化工具，用下来觉得最方便的是Premake，这个工具的好处是 Lua 语法，跟 cmake 之类的脚本相比，非常清晰易读。我用 C++ 写的库，大多是用这个工具生成工程文件 (sln/vcxproj) 的，这样的生成两大好处：可以使工程文件与磁盘上的目录结构自动对应。所有的编译选项清楚地列在一个简短的 Lua 内，维护时不容易出错。这一次我的目标就是使用 Premake 把 Android.mk 和 Application.mk 这两个脚本的维护自动化，最好能做到一键生成 vs2013/vs2015/android 三个平台的编译脚本。Make it run从这个页面可以看到，Premake 没有原生对 android ndk 的支持，但在 Third-Party Modules 里可以看到两个相关的包，一个是 TurkeyMan(Manu Evans) 的premake-android，另一个是 Meoo(Bastien Brunnenstein) 的premake-androidmk，这一次我们使用后者。阅读 Premake ...继续阅读 (7)

我从未度过没有编程的一天，这就是我的全部。 — John Carmack日常一天清晨清晨很清醒，可以用来做计划，也可以做简单的重构和清理，就像开场前的热身那样，帮助进入工作状态。上午上午设计和实现每天的首要目标相关的任务。我发现不结合代码的，纯粹的为了设计而支出的时间是很低效的，边想边写比较容易保持状态，不跑偏，不过度设计。中午看看各种新闻八卦，上上B站，刷刷知乎什么的。下午下午处理次要和临时目标，和那些需要静下心来反复思考和权衡的事情，这一类事情的特点是“要想清楚，但是动手不多”。下班前一个小时集中修复各类 bug，如果一天的效率还算不错，那么这会儿体力下降，应该缓一下了。把能今天收掉的就收掉，给明天少留一点负担。晚上晚上如果不累的话，我一般看看书，整理一下读书笔记，用涂书笔记把重要的段落摘录下来，写上一两句自己的感想；如果有点累，就看看电影，打打游戏啥的。心情好的话会唱首歌，还有就是会读一下白天遇到的各种好玩但还没来得及读的材料。工具辅助我使用下面几个工具作为日常的辅助。RescueTime我使用 RescueTime 帮助自己记录时间实际使用情况，最大的好处是零设置和零干扰。这里统计了本周记录在案的工作时间，包括每一天的具体情况。也可以看到自己在每种类型的工作上花费的时间，还有自己的工作节奏评分和与上周相比的趋势。可以看到我一般周一是峰值，在周三会回升一下，周五会比较 ...继续阅读 (56)

除夕夜，抢红包的间隙跑过来答一发知乎的提问：问题：C++左值和右值区别问题：关于C++左值和右值区别有没有什么简单明了的规则可以一眼辨别？看了一下现有的答案，讲概念和理论的多，谈可操作性的少。我来说两个办法吧，不过都不是俺原创的。来自 Scott Meyers 的方法判断表达式是否是左值，有一个简单的办法，就是看看能否取它的地址，能取地址的就是左值。A useful heuristic to determine whether an expression is an lvalue is to ask if you can take its address. If you can, it typically is. If you can’t, it’s usually an rvalue. A nice feature of this heuristic is that it helps you remember that the type of an expression is independent of whether the expression is an lvalue or an rvalue.--"Effective Modern C++", Introduction - Terminology and Conventions, Scott Meye ...继续阅读 (9)

需求分析 (3个原因)产生这个需求，通常有以下的原因：这个 goroutine 的运行超出了太多预计的时间，以致后续的计算不再有意义这个 goroutine 阻塞在某个 read/write channel 变得没有响应这个 goroutine 阻塞在某个系统调用，外部调用或业务逻辑的死循环这种时候很自然地就会产生“主动外部 kill goroutine”的需求 (正如手动结束掉一个无响应的进程那样)。然而 goroutine 被设计为不可以从外部无条件地结束掉，只能通过 channel 来与它通信。也就是说，每一个 goroutine 都需要承担自己退出的责任。(A goroutine cannot be programmatically killed. It can only commit a cooperative suicide.)以下我们分可响应 (1 & 2) 和不可响应 (3) 两种情况分开讨论处理仍可响应 channel 的 goroutine (1 & 2)最直接的方法是关闭与这个 goroutine 通信的 channelclose(ch)。如果这个 goroutine 此时阻塞在 read 上，那么阻塞会失效，并在第二个返回值中返回 false (此时可以检测并退出)；如果阻塞在 write 上，那么会 panic，这时合理的做法是在 goro ...继续阅读 (7)

这是今天在知乎上的一个回答，原题如下：问题：求问有哪些合用的遮挡剔除技术?问题补充：我们的flash3d的fps游戏 面向的受众 机器性能差的占不少，很多都是很低端的集成显卡。像素填充率很低。目前我们用的遮挡剔除技术是quake的bsp+portal。但是在一些没有明显房间分划的场景就显的几乎没什么用了。 求问 有什么合用的剔除技术适用于室外场景，没有明确房间概念 但是互相之间还是有遮挡关系的 另外umbra3d所用的技术都是公开的么? 如果我要能做到它的程度 有哪些paper可以参考。因为umbra3d没有针对flash的sdk.所以买了也没法用上 另外我对这个领域的知识是很碎片化的 请高手推荐些paper或者书籍能让我对这个领域有些系统的认识 知道哪些问题可以解决 而哪些问题其实目前还解决不了以下部分是我的答案：@庞巍伟的方案是比较流行的思路，不过感觉用在题主提到的低端集成显卡上，可能会有些限制。这里我先补充一些实时OC的思路和实践，然后再针对题主这种情况提个离线的方案，看起来可能 low 一点，仅供参考。先说明一下，遮挡剔除 (Occlusion Culling) 本质上是这样一个过程——消耗一小部分 CPU 来去掉不可见的物体，不改变最终渲染的画面的同时，降低 GPU 的负载。实时的 OC 已经有题主提到的 umbra 方案，背后的原理是dPVS (Wikipedia)以及 ...继续阅读 (3)