http://luajs.org

2014/11/6更新：
已修復(fù)lua,js在and、or差異上導(dǎo)致的一系列問題。
已支持metatable。
已發(fā)布部分standard lib。 TODOs中列出的部分除外。歡迎調(diào)教。發(fā)現(xiàn)BUG歡迎提出issue。

https://github.com/tdzl2003/lua.js/blob/master/stdlib.lua

另外stdlib的完整源碼發(fā)布在此處
可作為一個不錯的使用參考

@imjj
原因不明。我這里的性能明顯下降應(yīng)該有g(shù)c的影響。

@emptyhua

原本的目的是多用ffi，少對libuv庫進行修改，避免對lua C API的調(diào)用，看能否取得更好的擴展性和性能提升。
在之前的項目里采用C API去封裝回調(diào)，遇到了一些有關(guān)coroutine的坑，譬如在coroutine里開始一個主循環(huán)，在另一個coroutine里再注冊一些回調(diào)，使用C API有時候很難完美解決。

所以這個項目的思路是，盡可能直接使用第三方的C庫，使用ffi來訪問API，而非去實現(xiàn)一個Lua C Module，這也是LuaJIT官方所推薦的，這會讓luaJIT的優(yōu)化達(dá)到極致（C API訪問，以及對Lua-C Module里函數(shù)訪問時的傳參，會有不能被LuaJIT編譯優(yōu)化的開銷，雖然這個開銷對于非頻繁調(diào)用的內(nèi)容并不大）
另外一個原本預(yù)期中的好處是，希望這個項目最終能只有Lua代碼，以及l(fā)uajit主程序、編譯好的其他庫的動態(tài)鏈接版本，便于去修改、發(fā)布及調(diào)試。只是目前來看完全這么做還是有點困難，因為現(xiàn)在已經(jīng)對libuv做了一些修改。但是使用其他callback不那么常見的庫可能會相對輕松。我可能再進行一些嘗試后再決定如何折衷，或者放棄這個，去fork和參與luvit。

另外luvit與我這邊的實驗均證明，使用LuaJIT會取得比V8好數(shù)倍的性能~所以這個方向應(yīng)該是沒錯的。

Hi，此算法某情形下有問題，還需判斷： 沒有其它頂點在此次剖分的三角形內(nèi)。

為什么要在9.0已經(jīng)存在了的情況下，還用6.0呢……

別搞那么復(fù)雜，直接拿數(shù)組，每貞整體掃描一次就好了。

所以像Alpha這樣的模式絕對論者，就會建議你，讓全局變量全部消失掉吧……
像Vczh這樣的MS毒害者就會建議你，在全局變量前面加g_吧
如果是一年前的我，就會建議你，在局部變量前面加下劃線吧
如果是現(xiàn)在的我，我就會建議你……
碰到問題別總發(fā)呆，打斷點調(diào)試下阿，否則光靠經(jīng)驗解決不了的問題怎么辦呢？

不要想得太復(fù)雜……先按最簡單的來，然后覺得哪里不夠好就慢慢改進

if ( x == 23 )
懷疑你的循環(huán)周期寫錯了。
++x以后應(yīng)該是x == 24的時候吧？
也可以這么寫：
++x;
y+= x/24;
x%= 24;
這樣就保證不錯啦。

glutMainLoop就是一個循環(huán)，它完成：
完成消息循環(huán)，與其他程序并行工作
在循環(huán)中：
　　檢查輸入，并調(diào)用注冊的鍵盤輸入處理函數(shù)（就是那個什么key的）
　　調(diào)用繪圖函數(shù)（那個什么display的）
　　還有一些定時的通知（Timer）
　　也許還有一些其它的通知（如按下關(guān)閉按鈕阿等等）

也就是說現(xiàn)成的循環(huán)已經(jīng)有了，你需要做的就是：
1、建立模型對象：瓶子、藥丸等，模型對象可以完整地描述自身的狀態(tài)，比如瓶子里哪些位置有藥丸，每個藥丸和哪個方向的藥丸相連。
2、完成繪圖函數(shù)：將模型對象的狀態(tài)正確的展現(xiàn)到屏幕上，讓用戶可以觀察到。
3、建立模型對象與輸入之間、模型對象與模型對象之間的相關(guān)性（時間也看作一種輸入），使得全部模型對象可以根據(jù)輸入正確的改變自身的狀態(tài)。

以上就是所謂的“模型、視圖、控制器”，也就是MVC。不過一般在游戲制作中，很少將它們分離的。
在C風(fēng)格的代碼中，一般都是將1、3兩項寫在一起，因為單純的模型對象通常只是一個或多個數(shù)組，或一個或多個變量（當(dāng)然也可以將對該對象的某些常用的操作封裝成函數(shù)當(dāng)作模型代碼的一部分）。而控制器代碼和模型代碼在邏輯上緊密結(jié)合，通常將它們合并作為“邏輯部分”。
在C++的風(fēng)格中，有兩種不同的思路：一種是依然將視圖分離，邏輯層作為一個獨立的部分存在，然后視圖層（在我們這里叫界面層比較多）通過一定的接口獲取到對象的狀態(tài)，再顯示。或者，有時候，界面層維護自己的一部分邏輯狀態(tài)，根據(jù)邏輯層發(fā)來的通知和對邏輯層的主動調(diào)用，將自己的邏輯狀態(tài)和邏輯層同步。對大型游戲來說這種方法尤其多見。
另一種就是根據(jù)具體的邏輯對象進行劃分，不再劃分邏輯層和界面層，將瓶子本身的狀態(tài)、瓶子所能完成的操作、瓶子在某些事件下所產(chǎn)生的響應(yīng)，也包括瓶子如何繪制，都封裝到一個類中，這樣外層只要簡單的調(diào)用就好了。這種方法常見于各種小游戲、快速開發(fā)的手機游戲、單機游戲等等。

bioskey是DOS下的東西,比如TC。
Windows下早就不允許應(yīng)用程序直接控制中斷了，都得繞一圈來

注意點特殊情況阿,比如垂直狀態(tài)靠邊時發(fā)生旋轉(zhuǎn)……

關(guān)于key：
我猜測glutKeyboardFunc定義的應(yīng)該是“按鍵”，比如說你按下a，首先是產(chǎn)生一次a，然后過一段時間，然后按固定的頻率不斷產(chǎn)生a。
如果使用這個接口，應(yīng)該是直接在key被調(diào)用的時候向?qū)?yīng)的方向移動就好了，不需要通過我上次說的那個復(fù)雜的狀態(tài)判斷。對于瑪麗醫(yī)生來說，這種方法其實夠了。一個比較討厭的毛病是，可能第一格移動比較慢，但后來的頻率很快，如果想一直保持穩(wěn)定的速度，或者自己控制這個速度，就用如下的方法：

我上次說的是另兩種鍵盤輸入獲得的方法，這兩種方法更原始一點：
1、某個鍵被按下，和松開的事件。
2、某個鍵是否被按下的狀態(tài)。

通過這兩種方式獲得鍵盤輸入，能夠更精確地獲得按鍵何時被松開、按下，或者在某個時刻是否被按住（另外這兩種輸入是可以互相推導(dǎo)的）
通常游戲都通過這兩種輸入之一來完成。另外這兩種輸入外加一個定時器也是可以推導(dǎo)出之前的那種方法的。

所以我一向覺得初學(xué)者用框架是不太好的習(xí)慣……
很多細(xì)節(jié)都被隱藏了。

既然你該干而沒干，那就是有人替你干了（某Loop）。

上課是什么？

加油……
vczh是位好同志，雖然伊已然叛變革命了，但OGL的基礎(chǔ)東西倒可以多問問他。

今天發(fā)現(xiàn)開頭一篇文章沒了， 才發(fā)現(xiàn)原來是還有下一頁的，跑去翻了下，似乎你們對DX很義憤填膺阿……
我個人覺得無所謂，基本功能和流程都差不多，畢竟大家都是在用顯卡干活……不過需要注意的是，對于制作商業(yè)游戲來說，DX在某些方面“確實”相對OGL來說有一定優(yōu)勢。（不過真正的大公司大制作，往往都是DX和OGL都支持的）。
雖然某大牛宣稱“DX11還沒出來就已經(jīng)過時了……”等等，但是考慮目前的市場應(yīng)用，DX還是主流吧-___,-
OGL相對來說更學(xué)術(shù)一點。國外不少研究室的大牛都很控OGL。

另外，一位大牛評價說：“難道glRotatef這樣的函數(shù)沒有任何幫助文檔可以讀么？”
事實上我隨便翻了下，資料還是滿天飛的口牙-____________,- 善用那啥可以節(jié)約很多時間哦……

另外提醒：從長遠(yuǎn)角度來說，建議第一個Demo完成以后，務(wù)必系統(tǒng)學(xué)習(xí)圖形學(xué)基礎(chǔ)理論，理解其抽象的、平臺無關(guān)的圖形學(xué)概念，不需要寫任何程序，圖形學(xué)基礎(chǔ)理論是極其重要的-_____,- 其重要性基本和算法等同。（這句話的另一個意思就是，除非你想做很深刻的研究，否則也基本上就是學(xué)學(xué)最基本的那幾條就夠用老-______,- ）
然后再去看看最新的技術(shù)，了解下Shader什么的（我已經(jīng)迷上Shader了），去掃描下各種圖形學(xué)論文（哪怕只看一遍里面的彩頁插圖）保持學(xué)習(xí)的活力，避免學(xué)了一兩年驀然回首一看，原來自己學(xué)的都是別人十年前就不用了的東西-______,-

喵，先寫這么多-O-

歡迎vczh來鄙視我=。=