http://luajs.org2014/11/6更新：
已修复lua,js在and、or差异上导致的一系列问题。
已支持metatable。
已发布部分standard lib。 TODOs中列出的部分除外。欢迎调教。发现BUG欢迎提出issue。
https://github.com/tdzl2003/lua.js/blob/master/stdlib.lua另外stdlib的完整源码发布在此处
可作为一个不错的使用参考
@imjj
原因不明。我这里的性能明显下降应该有gc的影响。
@emptyhua
原本的目的是多用ffi，少对libuv库进行修改，避免对lua C API的调用，看能否取得更好的扩展性和性能提升。
在之前的项目里采用C API去封装回调，遇到了一些有关coroutine的坑，譬如在coroutine里开始一个主循环，在另一个coroutine里再注册一些回调，使用C API有时候很难完美解决。
所以这个项目的思路是，尽可能直接使用第三方的C库，使用ffi来访问API，而非去实现一个Lua C Module，这也是LuaJIT官方所推荐的，这会让luaJIT的优化达到极致（C API访问，以及对Lua-C Module里函数访问时的传参，会有不能被LuaJIT编译优化的开销，虽然这个开销对于非频繁调用的内容并不大）
另外一个原本预期中的好处是，希望这个项目最终能只有Lua代码，以及luajit主程序、编译好的其他库的动态链接版本，便于去修改、发布及调试。只是目前来看完全这么做还是有点困难，因为现在已经对libuv做了一些修改。但是使用其他callback不那么常见的库可能会相对轻松。我可能再进行一些尝试后再决定如何折衷，或者放弃这个，去fork和参与luvit。
另外luvit与我这边的实验均证明，使用LuaJIT会取得比V8好数倍的性能~所以这个方向应该是没错的。
Hi，此算法某情形下有问题，还需判断： 没有其它顶点在此次剖分的三角形内。
为什么要在9.0已经存在了的情况下，还用6.0呢……
别搞那么复杂，直接拿数组，每贞整体扫描一次就好了。
所以像Alpha这样的模式绝对论者，就会建议你，让全局变量全部消失掉吧……
像Vczh这样的MS毒害者就会建议你，在全局变量前面加g_吧
如果是一年前的我，就会建议你，在局部变量前面加下划线吧
如果是现在的我，我就会建议你……
碰到问题别总发呆，打断点调试下阿，否则光靠经验解决不了的问题怎么办呢？
不要想得太复杂……先按最简单的来，然后觉得哪里不够好就慢慢改进
if ( x == 23 )
怀疑你的循环周期写错了。
++x以后应该是x == 24的时候吧？
也可以这么写：
++x;
y+= x/24;
x%= 24;
这样就保证不错啦。
glutMainLoop就是一个循环，它完成：
完成消息循环，与其他程序并行工作
在循环中：
检查输入，并调用注册的键盘输入处理函数（就是那个什么key的）
调用绘图函数（那个什么display的）
还有一些定时的通知（Timer）
也许还有一些其它的通知（如按下关闭按钮阿等等）
也就是说现成的循环已经有了，你需要做的就是：
1、建立模型对象：瓶子、药丸等，模型对象可以完整地描述自身的状态，比如瓶子里哪些位置有药丸，每个药丸和哪个方向的药丸相连。
2、完成绘图函数：将模型对象的状态正确的展现到屏幕上，让用户可以观察到。
3、建立模型对象与输入之间、模型对象与模型对象之间的相关性（时间也看作一种输入），使得全部模型对象可以根据输入正确的改变自身的状态。
以上就是所谓的“模型、视图、控制器”，也就是MVC。不过一般在游戏制作中，很少将它们分离的。
在C风格的代码中，一般都是将1、3两项写在一起，因为单纯的模型对象通常只是一个或多个数组，或一个或多个变量（当然也可以将对该对象的某些常用的操作封装成函数当作模型代码的一部分）。而控制器代码和模型代码在逻辑上紧密结合，通常将它们合并作为“逻辑部分”。
在C++的风格中，有两种不同的思路：一种是依然将视图分离，逻辑层作为一个独立的部分存在，然后视图层（在我们这里叫界面层比较多）通过一定的接口获取到对象的状态，再显示。或者，有时候，界面层维护自己的一部分逻辑状态，根据逻辑层发来的通知和对逻辑层的主动调用，将自己的逻辑状态和逻辑层同步。对大型游戏来说这种方法尤其多见。
另一种就是根据具体的逻辑对象进行划分，不再划分逻辑层和界面层，将瓶子本身的状态、瓶子所能完成的操作、瓶子在某些事件下所产生的响应，也包括瓶子如何绘制，都封装到一个类中，这样外层只要简单的调用就好了。这种方法常见于各种小游戏、快速开发的手机游戏、单机游戏等等。
bioskey是DOS下的东西,比如TC。
Windows下早就不允许应用程序直接控制中断了，都得绕一圈来
关于key：
我猜测glutKeyboardFunc定义的应该是“按键”，比如说你按下a，首先是产生一次a，然后过一段时间，然后按固定的频率不断产生a。
如果使用这个接口，应该是直接在key被调用的时候向对应的方向移动就好了，不需要通过我上次说的那个复杂的状态判断。对于玛丽医生来说，这种方法其实够了。一个比较讨厌的毛病是，可能第一格移动比较慢，但后来的频率很快，如果想一直保持稳定的速度，或者自己控制这个速度，就用如下的方法：
我上次说的是另两种键盘输入获得的方法，这两种方法更原始一点：
1、某个键被按下，和松开的事件。
2、某个键是否被按下的状态。
通过这两种方式获得键盘输入，能够更精确地获得按键何时被松开、按下，或者在某个时刻是否被按住（另外这两种输入是可以互相推导的）
通常游戏都通过这两种输入之一来完成。另外这两种输入外加一个定时器也是可以推导出之前的那种方法的。
所以我一向觉得初学者用框架是不太好的习惯……
很多细节都被隐藏了。
既然你该干而没干，那就是有人替你干了（某Loop）。
re: 10月11日_不知所云_By 麦伊 天地之灵 2008-10-13 19:43
上课是什么？
加油……
vczh是位好同志，虽然伊已然叛变革命了，但OGL的基础东西倒可以多问问他。
今天发现开头一篇文章没了， 才发现原来是还有下一页的，跑去翻了下，似乎你们对DX很义愤填膺阿……
我个人觉得无所谓，基本功能和流程都差不多，毕竟大家都是在用显卡干活……不过需要注意的是，对于制作商业游戏来说，DX在某些方面“确实”相对OGL来说有一定优势。（不过真正的大公司大制作，往往都是DX和OGL都支持的）。
虽然某大牛宣称“DX11还没出来就已经过时了……”等等，但是考虑目前的市场应用，DX还是主流吧-___,-
OGL相对来说更学术一点。国外不少研究室的大牛都很控OGL。
另外，一位大牛评价说：“难道glRotatef这样的函数没有任何帮助文档可以读么？”
事实上我随便翻了下，资料还是满天飞的口牙-____________,- 善用那啥可以节约很多时间哦……
另外提醒：从长远角度来说，建议第一个Demo完成以后，务必系统学习图形学基础理论，理解其抽象的、平台无关的图形学概念，不需要写任何程序，图形学基础理论是极其重要的-_____,- 其重要性基本和算法等同。（这句话的另一个意思就是，除非你想做很深刻的研究，否则也基本上就是学学最基本的那几条就够用老-______,- ）
然后再去看看最新的技术，了解下Shader什么的（我已经迷上Shader了），去扫描下各种图形学论文（哪怕只看一遍里面的彩页插图）保持学习的活力，避免学了一两年蓦然回首一看，原来自己学的都是别人十年前就不用了的东西-______,-
喵，先写这么多-O-
欢迎vczh来鄙视我=。=