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來鄙視我=。=