最新 | 最热门 | 最高评价
---

+0  支持部分共享的树结构

Tag: 算法 | 优化与技巧
云风 发于 2017年06月18日 16:23 | 点击: 449 | 展开摘要
因为图形引擎中的对象天然适合用树 (n-ary tree) 表达，所以它在图形引擎中被广泛使用。通常，子节点会继承父节点的一些状态，比如变换矩阵，在渲染或更新的时候，可以通过先序遍历逐级相乘。

在 PC 内存充裕的条件下，我们通常不必考虑树结构储存的开销，所以大多数图形引擎通常会为每个渲染对象独立生成一个树结构，比如 Unity 中的 GameObject 就是这么一个东西。在 Ejoy2D 中，从节约内存的角度考虑，把树节点上的一部分可共享的状态信息（不变的矩阵、纹理坐标

查看全文: http://www.udpwork.com/item/16307.html
---

+0  Lua 表的差异同步

Tag: lua与虚拟机 | skynet | 优化与技巧
云风 发于 2017年05月18日 20:10 | 点击: 464 | 展开摘要
最近同事碰到的一个需求：需要频繁把一组数据在 skynet 中跨网络传递，而这组数据实际变化并不频繁，所以做了大量重复的序列化和传输工作。

更具体一点说，他在 skynet 中设计了一个网关节点，这个网关服务可以负责把一条消息广播给一组客户端，每个客户端由内部的一个 uuid 串识别，而每条消息都附带有客户端 uuid 列表。而实际上这些 uuid 列表组有大量的重复。每条广播消息都重复打包了列表组，且列表组有大量重复信息。

一开始我想的方法是专门针对这个需求设计一组协议

查看全文: http://www.udpwork.com/item/16269.html
---

+0  Unity3D 的大场景内存优化

Tag: 优化与技巧 | 游戏开发
云风 发于 2017年04月06日 11:34 | 点击: 518 | 展开摘要
我们公司的一个 MMORPG 项目最近在内存方面碰到了红线，昨天开会讨论了一下。我提出了一个改进方案，写篇 blog 记录一下。

问题是这样的。在当下的手机及平板硬件设备条件下，操作系统留给应用的可用内存并不多，大约只有 500M 左右。

和 PC 环境不同，手机上是交换分区的机制来对应一些临时突发性内存需求的。而手机必须保证一些系统服务（某些高优先级后台业务）的运行，所以在接电话、收取推送等等意外任务发生时，有可能多占用一些内存，导致操作系统杀掉前台任务让出资源。

根

查看全文: http://www.udpwork.com/item/16200.html
---

+0  ejoy2d sprite pack 的空间优化

Tag: 优化与技巧
云风 发于 2016年02月15日 13:27 | 点击: 441 | 展开摘要
在 ejoy2d 里，我将 sprite 的结构信息储存在一组叫 sprite pack 的结构中。其中包括动画的 frame 数据，sprite 由若干部分组成，每个部分的变换矩阵，对应贴图的编码和坐标等等。

通常这些数据不会太大，所以我建议一次加载到内存就不再删除。而动态生成的 sprite 对象则直接引用这些数据，不必做引用计数。这些数据之间的交叉引用（可以像搭积木一样用很多部件构成复杂的 sprite ）也不需要额外记录。但如果保存了大量的动画信息，或 sprite

查看全文: http://www.udpwork.com/item/15186.html
---

+0  ejoy2d sprite pack 的空间优化

Tag: 优化与技巧
云风 发于 2016年02月03日 18:57 | 点击: 611 | 展开摘要
在 ejoy2d 里，我将 sprite 的结构信息储存在一组叫 sprite pack 的结构中。其中包括动画的 frame 数据，sprite 由若干部分组成，每个部分的变换矩阵，对应贴图的编码和坐标等等。

通常这些数据不会太大，所以我建议一次加载到内存就不再删除。而动态生成的 sprite 对象则直接引用这些数据，不必做引用计数。这些数据之间的交叉引用（可以像搭积木一样用很多部件构成复杂的 sprite ）也不需要额外记录。但如果保存了大量的动画信息，或 sprite

查看全文: http://www.udpwork.com/item/15169.html
---

+0  如何拼接 PVR 压缩贴图

Tag: 算法 | 优化与技巧
云风 发于 2015年01月08日 18:41 | 点击: 985 | 展开摘要
2d 游戏通常都用到很多图素，由于显卡硬件特性，我们又不会把单个图素放在独立贴图中。这样会导致渲染批次过多。在移动设备上，非常影响渲染效率。

所以，游戏运行时，这些图素一般都会合并在很少几张贴图上。要么采用离线合并的方式（利用 texture packer 这样的工具），或者在运行时使用装箱算法。

最近，朱光同学一直在为 ejoy2d 编写运行时合并图素的模块。今天我们讨论了一下他做的诸多尝试。

为了提高贴图利用率，我们可以把大的不规则图素先拆分成小块，然后再组合起来。

查看全文: http://www.udpwork.com/item/13756.html
^..^

+0  字体勾边渲染的简单方法

Tag: 优化与技巧 | 游戏开发
云风 发于 2013年09月03日 12:46 | 点击: 1072 | 展开摘要
我们的游戏中需要对渲染字体做勾边处理，有种简单的方法是将字体多画几遍，向各个方向偏移一两个像素用黑色各画一遍，然后再用需要的颜色画一遍覆盖上去。这个方法的缺点是一个字就要画多次，影响渲染效率。

前几年有人发明了另一种方法，google 一下 Signed Distance Field Font Rendering 就可以找到大量的资料。大体原理是把字体数据预处理一遍，把每个像素离笔画的距离用灰度的形式记录在贴图上，然后写一个专门的 shader 来渲染字体。好处是字体可以缩

查看全文: http://www.udpwork.com/item/10586.html
^..^

+0  去掉 full userdata 的 GC 元方法

Tag: lua与虚拟机 | 优化与技巧
云风 发于 2013年08月27日 11:13 | 点击: 998 | 展开摘要
根据 Lua 文档中的说法，lightuserdata 比 fulluserdata 要廉价一些。那么，其中的区别在哪里呢？

空间开销上，fulluserdata 是一个 GC 对象，所以比 lightuserdata 要多消耗一点内存，这点内存往往对程序不造成太大的影响。

时间开销上，fulluserdata 在访问它时和 lightuserdata 并无太大区别，它们都只能通过元方法才能在 Lua 中使用。所有 lightuserdata 共用一个元表，不如 full

查看全文: http://www.udpwork.com/item/10501.html
---

+0  最近一些心得

Tag: 优化与技巧 | 语言与设计 | 杂记
云风 发于 2013年03月11日 11:54 | 点击: 1211 | 展开摘要
最近特别忙, 每天写程序的时间都不够。有些东西在做完之前不想公开谈，所以只把一些笔记发在公司内部的周报里了。等这段时间过去，再贴到这里来。

不过还是有一些泛泛的心得可以写写的。

前几天遇到一个优化的问题。我想采用定期计算路图的方式优化寻路的算法。而不用每次每个单位在想查找目标的时候都去做一次运算并记录下路径结果。一切都看起来很顺利，算法的正确性很快就被验证了。可是最后实际跑的时候，发现在生成路图的地方会稍微卡一下影响流畅性。

遇到这类问题，第一反应通常是考虑如何优化。比

查看全文: http://www.udpwork.com/item/9434.html
---

+0  Lua 字节码与字符串的共享

Tag: lua与虚拟机 | 优化与技巧
云风 发于 2012年11月16日 15:40 | 点击: 1315 | 展开摘要
我们的系统的应用场合比较特殊，在同一个进程内存在数千个 lua_State 。

Lua 的虚拟机占用的内存已经足够小了，但还是抗不住数量多啊。所以我希望有版本节约一些内存。

最想做的一件事情是把不同 lua_State 中相同的函数字节码合并起来共用一块内存。要做到这一点并不复杂。而且可以提高一些内存访问的效率。（因为大部分 lua 程序在并行执行相同的逻辑）

首先我们需要准备一个用来共享数据块的模块，它必须是线程安全的。因为既然分到了不同的 lua_State 就是想

查看全文: http://www.udpwork.com/item/8597.html
2

+1  开发笔记(21) : 无锁消息队列

Tag: 优化与技巧
云风 发于 2012年06月20日 17:49 | 点击: 2082 | 展开摘要
最近三周按计划在做第一里程碑的发布工作，几乎所有新特性都冻结了。大家都在改 bug 和完善细节。

服务器的性能还有不小的问题，压力测试的结果不能满意。原本我希望可以轻松实现 40 人对 40 人的战场。现在看起来在目前台式机上还有困难，虽然换上高配置的服务器可以达到，但会增加不少成本。我们决定动手做一些优化。

固然过早优化的必要性不大，但早期发现的性能问题有可能是设计原因造成的。尽早发现设计中的错误，早点改正，比后期在低层次优化要省力的多。

我们采用的是大量进程（非 O

查看全文: http://www.udpwork.com/item/7512.html
2

-2  Ring Buffer 的应用

Tag: 网络与安全 | 优化与技巧
云风 发于 2012年02月02日 22:20 | 点击: 1991 | 展开摘要
这是一篇命题作文，源于今天在微薄上的一系列讨（好吧，也可以说是吵架）。其实方案没有太多好坏，就看你信不信这样做能好一些或坏一些。那么，整理成 blog 写出，也就是供大家开拓思路了。

我理解的需求来源于网络服务提供程序的一个普遍场景：一个服务器程序可能会收到多个客户端的网络数据流，在每个数据流上实际上有多个独立的数据包，只有一个数据包接收完整了才能做进一步的处理。如果在一个网络连接上数据包并不完整，就需要暂时缓存住尚未接收完的数据包。

问题是：如何管理这些缓冲区比较简洁明

查看全文: http://www.udpwork.com/item/6775.html
|<<<12>>>| 一共2页, 16条记录