Will throw a `Error` object containing the error message.

load (ld [, source [, mode [, env]]])

Only ld and env has meaning now.

dofile/loadfile, io.open, io.close, os.tmpname, os.remove, os.rename

Not supported cause there's no build-in file system supported for javascript. You can reimplement these functions on specific environment.

package.searchers, package.config, package.path, package.cpath, package.loadlib, package.searchpath

No build-in searchers for Lua files. You can reimplement searcher on specific environment. Mostly use package.preload instead.

No C loader/C lib. Use inline javascript instead.

next (table, index)

Not supported. use pairs instead.

pairs(t)

Will be supported next version, but cannot check table changes while iterating.

Will be slow if you call pairs but not iterate on it.

xpcall(f, msgh[, arg1, ...])

The stack was rewinded when msgh is called. So you cannot do anything like traceback the stack or read local variables.

string.*

There's encoding issues with lua.js now. Mostly, string.* API will use unicode instead of ANSI.

string.find, string.format, string.gmatch, string.gsub, string.match

Pattern will be supported in future. string.find with "plain = true" is usable.

os.execute, os.exit, io.popen, os.getenv

No process supported in lua.js.

os.setlocale

Not supported.

coroutine.*

The whole coroutine lib will not be supported for a long time. The browser context cannot support this feature.

debug.*

The whole debug lib is not supported now. But maybe some of them will be supported in future.

metatable:

__gc was not supported.

__mode was not supported.

天地之灵 2014-11-06 05:07 发表评论

Lua.js采用一个不同的方案，它将lua代码转变为一个AST树，经过一系列的转换函数，最后产出一个合乎js标准的AST树，随后生成一个合法的js代码。因此转换后直接执行的代码，比VM on VM要快2-5倍，高效的执行速度有助于让你的应用或游戏展现流畅的极致体验。

另外，压缩后的Lua.js难以置信的小。这里是当前lua.js和lua.vm.js的对比：

	文件大小	传输大小(gz压缩)
lua.js	22.7K	8.3K
lua.vm.js	638K	203K

尽管当前lua.js还有一些功能没有实现（如metatable、Lua标准库等），但可以预见全部实现后的尺寸也不会有大幅的增长，基本上不会超过30K/12K。

再谈论性能，这里使用了lua.vm.js官方的几个benchmark代码（稍做修改使得可以在当前版本的lua中运行）（lua.js和lua.vm.js均在chrome下运行），结果如下：

	lua.js	lua.vm.js	lua 5.2.3	luaJIT 2.0.3	Scale	What it measures
Binary Trees	8.526s	10.198s	4.006s	0.731s	seconds (lower numbers are better)	GC Performance
Scrimark	26.98	8.84	30.52	1249.73	MFLOPS (higher numbers are better)	numeric computation performance

在当前版本中，GC仅仅比lua.vm.js略快，这是因为现在lua.js对于table模拟还处于较为原型的阶段，没有经过充足的优化。但即使这样也比lua.vm.js更快

而在数值计算上，性能远超lua.vm.js，逼近官方lua，这同样是在lua.js还没有经过充足优化的前提下。经过优化，完全有超过官方Lua的可能性。

lua.js的benchmark可以在http://luajs.org上找到，lua.vm.js的benchmark在 http://kripken.github.io/lua.vm.js/lua.vm.js.html

如果你对lua.js感兴趣，在这里可以下载独立的js文件：

lua.js尚处于不完善状态，如果你决定尝试使用，务必关注本项目的更新，及时替换更新的版本！

天地之灵 2014-11-05 20:17 发表评论

server "account-server-1" "account" register master failed
阅读讨论帖后发现，是新版添加了adminServer.json，需要在这里添加每种服务器类型的token（默认创建的只有connector）

天地之灵 2013-11-10 15:23 发表评论

('object' === typeof module ? module.exports : (this.Protocol = {}),'object' === typeof module ? Buffer : Uint8Array, this);

天地之灵 2013-11-10 11:17 发表评论

我们认为，对未知东西的迅速了解、分析能力是非常重要的，这也可以认为是我们团队的天分所在。我们不会花太多时间去仔细研读一个开源项目的源代码，相反，我们迅速的阅读完它提供的tutorial，查看社区与搜索结果，和很多已经用过它们及用过同类项目的人讨论，熟悉它的风格与用法，猜测它的整体结构，思考它能做什么，不能做什么，擅长做什么，不擅长做什么，再然后，通过api reference扫描寻找我们所需要的东西。

天地之灵 2013-08-11 19:37 发表评论

因为Seed Engine诞生之初，就定位为主要面向Android、iOS等移动设备（直到2012年6月才有了Flash平台的内部版本，才开始正式需求鼠标事件），所以Seed的输入模块除了对键盘做了简单支持（主要是出于调试目的）外，在很长的一段时间内，鼠标事件都是被wrap成为触摸事件。所有后续关于输入的工作都是针对触摸来做的。所以这篇文章主要重点讲触摸这个方面，尤其是手势识别的做法。

在Seed发展至今的期间，面临了大量复杂的需求，不断改进完善，目前还有很多不尽善尽美的地方。这篇文章会回顾一下这个过程，重点介绍一下当前的处理机制，再展望一下将来期望进行的改进工作。

Seed目前总计支持四种输入：键盘、鼠标、触摸、重力感应。

所有的输入会被响应的处理模块封装成一个struct，这个struct的头四个字节表明了触摸的类型。在单线程模式下，这个struct会被直接传递给应用。在多线程模式下，这个struct会在堆上分配，将指针传递给逻辑线程。这样的好处是在逻辑线程忙的时候，消息处理函数可以更及时返回，避免诸如窗口拖动卡顿之类的问题。

这一部分极其简单，因为简单，所以不容易出问题。之所以把底层架构放在历史之前谈，正是因为自从2011年10月份Seed诞生以来，引擎的这部分代码几乎从未变过。

对于Lua层来说，这部分的接口一直表现为一个全局事件，input.key、input.touch等等，参数struct会被iLuaWrapper(Seed中一个神秘组件)包装成Lua可以直接访问的数据，由Lua脚本去做任何上层的处理。

Seed诞生以后的一段时间内，当时的工作重心在完善2D渲染基础、2D场景管理，2D物理等等较为繁杂的模块上。因为没有具体项目的负担，当时的输入模块只以满足调试需求、实现简单交互为目的。因此，Seed在2011年10月以前，一直处在输入裸奔的状态。譬如只用键盘做操控，那就直接注册input.key去监听需要的事件。为了实现诸如简单的按钮之类的功能，当时产生了一堆垃圾代码，在事件里直接判定坐标等等。当然，这样写代码是不可能做出没有BUG的游戏来的，于是我们在一个游戏项目的原型阶段结束后不久的时间，迅速推出了第一套框架。

因为需求紧迫，做任何游戏至少都少不了做一堆能tap的button出来，所以我们抓紧推出了第一版的input_ex插件。

input_ex以尽可能简单的方式实现了对指定对象的触摸事件处理。场景中的node可以被注册到input_ex中，以接受tap、hold、drag事件。在touchdown的时候，input_ex会遍历所有注册的结点以找到被命中的node，之后的消息都会派发给这个node。

好吧，至少现在可以创建一堆不同的button了。input_ex的严重不足主要体现在功能上：

        1、input_ex中的手写状态机，几乎决定了除了tap、hold、drag以外，每加一个新的操作种类都是一个巨大的困难。

        2、input_ex不能很好的处理多点触摸。在多点的设备上各种出问题，以至于后来在某些项目里，强行屏蔽了除了1号手指（对应安卓里的0号手指）以外的所有操作。

        3、消息最开始就确定了对象，随后的过程不能改变消息的对象。譬如一个scrollview上面有一堆button，那么当button截获了消息的时候，scrollview就无法处理相应的拖拽事件了。

除此以外，在使用上，每个节点存在一个独立的用于处理输入的对象，其生命周期需要手动管理，错误的使用会导致各种问题。初学者几乎很难写出正确的代码。因为实现复杂，input_ex本身也在很长的时间内都存在引用关系的BUG，导致不需要的资源不能被正确的释放。总体来说，使用input_ex插件做游戏简直是一段不堪回忆的黑历史。

山寨时代之后

在使用input_ex完成了三四个界面操作简单的小游戏后，我们开始构思新的输入系统。我们理想中的输入系统应该符合如下几个条件：

1、很好的支持多点触摸。这包含两方面：第一，必须能够很好的识别利用多个手指的操作，譬如scale, pinch, rotate等。第二，我们认为对于大屏幕的触屏设备，能让多个玩家在不同的地方互不干扰的进行多个操作也是很有必要的需求，这会给游戏设计师带来很多新奇的玩法创意。

2、一定要很方便的加入各种不同的操作识别。我们希望能够实现很多有创意的小游戏，依靠触摸的操作来做很多有意思的事情。我们也希望我们的界面能够交互起来更酷，可以操作控制的地方更多。那么操作一定不能只局限于区区数种，一定要在特定的游戏里就能通过代码添加大量不同的全新操作才行。

3、操作对象的识别更智能。在scrollview 上面的button做scroll操作时，操作对象要能正确的变成scrollview。

4、根据操作对象所接受的事件有所不同，以及其父结点所接受的事件有所不同，对同一事件的处理可能会有差别。譬如一个button接受tap，当触摸并移动的时候，只要没移开范围，逻辑应等待手指松开时再判定为tap成功（正如你在windows下按住一个按钮然后小范围拖动鼠标，click并不会因此而失败）。但假如这个button有一个父结点甚至是祖先结点接受drag，那么早在刚开始移动的时候，就应该判定为tap取消，事件转为drag事件而派发给相应的祖先结点。

5、不会为了满足上面的需求，把上层逻辑代码搞的太麻烦。最理想的情况下，上层逻辑代码只要选择好自己所接受的操作种类，然后安心等待事件监听器被调用就好了。

而我们不想要：

1、像安卓那样复杂的事件分派机制，所有的触摸都被绑在一起依次分派下去，在结点上依据类型的不同写代码去做对应的操作。我们认为应该要有一个很好的手势识别底层，仅仅把结点关心的信息抛给它。

2、像HTML DOM那样的事件冒泡机制。因为触摸处理的复杂性，在touch down的时候往往根本不能确定真正用户想要进行何种操作。而如果等操作进行完了才给予反馈，那操作过程就很难得到非常及时的反馈。在上述scrollview和button的例子里，button必须首先获得事件以立即展现被按下的效果，等到用户的操作能够明确为一个scroll操作之后，再由scrollview来处理后续的事件。再加上之前所述的期望4，已经不是简单的对同一事件的冒泡足以满足的。

真的有一套框架能完美的解决我们的需求吗？下一章起，我会逐步讲解我们为此所做的努力。

天地之灵 2013-04-12 01:49 发表评论

天地之灵 2013-02-24 14:36 发表评论