Oculus Rift DK2 測試報告

我的DK2終於寄到台南老家，這是我第一次使用VR裝置。在老家測試的時候是用Macbook Pro 13吋，GPU是Intel內建 Iris晶片，效能有點貧弱。出乎意料，跑SDK world demo大部份都還可以維持stereo 3D 40 FPS以上，當然這比起最起碼的要求60FPS還是有一段差距，而且DK2的螢幕事實上是可以達到75Hz的。不過這小小的整合晶片可是在render 2364x 1461的超高解析度，我也不能抱怨什麼。

一開始測試並沒有特別強烈的感覺，我清楚的看出這是computer graphics創造出來的圖像，一堆缺陷也都看的一清二楚，因為fps不高，也感覺得出latency，不過我並沒有頭暈或任何不舒服的感覺，我想這應該歸功於low persistence display和time warp等技術，因為一開始還不清楚操作，只能用方向鍵加頭的方向歪歪的走路，測試了一段時間，然後不經意的撞上了房子的柱子，我才體會到甚麼是"presence"，我的左右眼視覺和我的大腦交互作用後，明確地告訴我那真的就是一根實實在在的柱子，柱子上的紋理很模糊，不過確很真實，我伸手就可以摸到它...這應該是我第一次體會到所謂的"presence"。

接下來熟悉操作之後又多試了幾次，我發現presence強烈的地方大致上有兩種，一種是距離非常近的物體，例如非常近的柱子，窗台，燭台等，讓人有感到伸手就可以摸到那種真實感，在config選項中的demo中是一張書桌上面擺了一堆東西，就是一個很好的例子，另一種是中距離高大的物件，例如樹木或是房屋頂端等，這跟傳統的螢幕感受完全不同，可以感受到物體真實的大小。至於遠景例如遠方的房子，欄杆等，則沒有特別強烈的感覺。

接著請我媽和我哥測試。我媽從來沒玩過3D遊戲，應該算是一個很好的測試對象，她戴上HMD後，馬上就說"哇，這是立體的"，然後幾乎立即就把頭來轉去，轉到身後，然後又說，"這是360度的阿"。我哥累積了數百小時的"Star Wars Knights of the Old Republic"遊戲時數，不過他帶上HMD後，也是非常驚訝，把頭四處轉來轉去，然後他說"以後的遊戲應該都要是這樣子吧"，我問他們會不會頭暈，他們都說不會(不過他們測試的時間都很短，也沒有測試一些極限的狀況)。總之，我想對於沒有接觸過VR的人來說，DK2在第一時間造成的WOW factor是很大的，我並沒有沒有花口語解釋這是甚麼，不過戴上HMD的人馬上就能理解他酷的地方在哪裡。

回台北後，我把DK2接上桌機，GPU是nVidia 560，能用75 fps執行world demo，效果真的出乎意料之外的好，跟Macbook Pro天差地遠，我戴上HMD看了一下world demo，幾乎馬上就對自己說，"就應該要是這樣子，這真得是太棒了"，重點並不是graphics毫無缺現(缺陷很多)，而是我感覺不到latency，在40 fps的時候我多少還是覺得我在用頭部操控camera，現在我真的感覺我是在看另一個世界。接下來我測試快速晃動頭部，也還是感覺不出有甚麼延遲，我也能在demo中快速晃動頭部但是鎖定一個觀看點，也都不會有任何頭暈不舒服。總之，如果移動只是HMD造成的(轉動頭部或上下左右移動頭)，DK2表現已經到達可以欺騙過我的認知系統，而讓我相信我在看得東西是真的存在的。

相反的，如果畫面中的運動和HMD不相符，則會造成頭暈，對我來說，如果demo中只是前進後退，左右移動，而沒有轉動方向，並不會太暈，高度改變則可能造成頭暈，對我來說上樓梯不太暈，下樓梯則很暈，快速轉動方向也滿暈的，不過最暈的，莫過於一瞬間的畫面和HMD方向不符，例如原本頭斜斜的，因此render的世界也是斜的，這時候如果瞬間把畫面轉正，馬上就會有非常強的暈眩感。另一個例子是在Half Life 2中的loading畫面，因為他在loading的時候是靜止的，這時候如果轉動頭部，畫面不會更新，這時候馬上就有非常強烈的暈眩感，我是個不太會暈車也不會對遊戲有暈眩感的人，不過這種VR造成的暈眩，真的是讓我暈到需要躺下來休息。我在想以後會不會有快速造成超級暈眩為噱頭的遊戲...

我還沒有測試過很多遊戲和demo，不過就我目前所看到的，VR就技術上來說，我相信的確是可以被解決的，DK2在關鍵的地方已經突破了那個threshold，他還有非常多缺陷，例如工業設計不佳，體積過大，螢幕解析度太低，FOV還是有點小等等，另一方面，他對效能要求也非常高，需要超高解析度，又需要3D rendering，還要高fps，不過這些隨著時間都可能被解決，他現在缺少的，就只有一個目前大家都在問的問題，我們有了VR，人們要拿來幹嘛，所謂的VR killer app，除了遊戲，到底是甚麼呢?不過對我來說，光是想到"Matrix"，"攻殼機動隊"，"夏日大作戰"中的世界，我就極度的希望VR能夠成功，我必須要有最好的VR設備，才能去到那些有趣的世界。

東京馬拉松 - 旅遊篇

發現居然有寫一天的遊記，雖然已經過期很久，還是po一下吧。

我不是個擅長規劃旅行行程的人，但是要帶媽一起去玩，總是要個排稍微像樣的行程。

現在回想起旅程，其實好像沒有非常特別好玩的景點，也就是沒有那種，阿這輩子還好有來過這地方的這種感覺。不過倒也沒發生趕不上車，迷路，挨餓受凍等意外。總之就是一次安全牌的旅程吧，不過帶老媽出門，沒有意外，不趕路，風景不錯，中間還跑了一場馬拉松，我猜這樣應該算是成功了吧。

第一天&東京馬拉松Expo

因為第一次來東京，又要跑馬拉松，我很沒種的選擇住起跑點旁的新宿華盛頓飯店，不過一進房間就有點後悔了，空間實在小的嚇人，一個人住還可以，兩個人住真的是連走路轉身都有困難。優點是真的就在起跑點旁，不過馬拉松當天我沒有好好利用這個優勢，另外飯店附的早餐老媽覺得普通，不過我個人倒是覺得碳水化合物供給量相當足夠所以不錯，沒辦法，那幾天滿腦子只想到跑步而已，衡量事物的標準可能都已經偏差了吧。

從成田機場到新宿最划算的方式應該是N'EX+Suica套票，不過新宿車站到華盛頓飯店要走大約十分鐘，所以還是多花了點錢坐利木津巴士直達飯店，搭車的人有滿多都是台灣要去跑東京馬拉松的，會看得出來是因為他們都帶著路跑協會的紅袋子，這袋子還真是好用阿從國內路跑到國外路跑都有人用，不過我自己是能不用就盡量不用，能低調就盡量低調一點。

到飯店時間大約是四點半或五點，晚餐到新宿車站，繞了一下找不太到老媽說的地下街，結果在一個有點奇怪的地下街吃了有點奇怪的東西，是韓式石鍋拌飯和煎餅，來日本第一餐就吃韓式料理，恩...，不過其實也還算滿好吃的。

搭海鷗百合號到expo會場，台場的Tokyo big sight

到達Expo會場時已經大約是七點了，首先報到領號碼布晶片，工作人員的英文並沒有特別好，不過還好只是領東西看著指示走也不會有什麼問題吧。

人家都說如果有時間Expo可以來逛一天，如果是我自己來逛可能也會逛很久吧，總之各種東西都有，衣服褲子襪子鞋子還有補給品，各種品牌都有，其中很多東西在台灣還滿難買的，例如跑步的壓縮緊身褲在台灣體育用品店可能都找不到CW-X，Skin或2XU這些高級品，這裡反正每種品牌旱型號都有，至於有沒有比較便宜就不太清楚了。有可能因為時間有點晚，我有些心急吧，不知道為什麼心裡就設定了要買CW-X的(是因為來到日本所以買日本品牌嗎？)，到了CW-X的攤位試穿了一件generator覺得不錯就買了。現在想想，其實應該每種品牌都去試穿一下的，不過那個晚上時間真的也不是很多，而且這件褲子在比賽那天應該算是有幫助吧，我目前也覺得真的不錯啦。

部落格再開

再度開啟已經棄置了很久的blog。

一年來發生了很多事情，可能有點太多了吧，我完成了許多與本業無關的事情，單車環島，救生員訓練，東京馬拉松，我好像在追趕著一些伸手無法觸及的事物，只是我的人生前半段浪費太多時間所塑造出的畸形性格，恐怕不是把身體鍛煉好，或去到更多地方就可以扭轉過來。很多時候我只是戴著假面具假裝自己是個正常的人可以樂在其中，不過我猜有些人還是可以輕易看穿我不過是在假裝罷了。

在工作的部分，則完全沒有任何可以值得提起的地方，不到一年，我的程式員靈魂就已經快要枯萎了，在生活上也完全是一片混亂，很多事情實在不願意再回想起來了。

跑步這件事情，幾乎完全沒有運氣的成分，練習多少，大致上就會拿到相對應的成績，比賽當天的身體或天氣的狀況如何都不是我能夠完全掌握的，有時候成績也會因此被影響，不過，對自己誠實，努力練習過了，最後的結果如何其實不是最重要的，只是我的心智畢竟不夠成熟，無法全然無動於衷。希望能夠有一天，我可以真正地享受這一切的過程，然後在踏過終點線後就瀟灑的離開，不回頭去看最後的成績如何，這真的很難，所以我還是來列一些想要完成的目標吧，這些就是終點線了：

1. Run Together： 要怎麼開始還完全沒有概念
2. 土炮graphics engine計畫：已經累積了太多想要做卻沒有做的事情了
3. 學日文：目前連五十音都背不完
4. 馬拉松：短期目標3:20，最終目標sub 3，可能有點太難了...
5. 認真寫blog：包含跑步，遊記，還有技術。所以應該會先寫東京馬拉松吧。

每一項看起來都很難很不可能完成，我也有點年紀，很多事情可能都已經太遲了，不過目前的身體狀況還是可以跑完全馬，記憶力有點衰退不過頭腦還算可以正常運作，很多事情也許還是有改變的機會吧。

我想要去遠方

「所謂職業選手是指能夠得到比外界期待更好的成績，不然的話，我要怎麼離開自己生長的故鄉呢？我想要去遠方。」

「想要把這些傢伙拖著走，這種衝刺還不夠看，需要有自我毀滅覺悟的超全力衝刺才行。」

—茄子，安達魯西亞之夏

NPAPI & anothor single triangle

不久前看到Insomniac game他們的新工具是利用各種網業技術做出來的，包含html，java script等等，其中有個地方還滿特別的，他們的場景編輯器的3D視窗是利用瀏覽器的plugin方式，直接嵌進瀏覽器中。

於是，我發現了一個長久以來我都視為理所當然，可是一直忽略的事實，那就是瀏覽器應該可以用native code寫plugin吧...flash，quick time，甚至Unity3D引擎，quake live這些技術，看起來不可能是用script寫出來的。

於是我用google查了web browser native plugin或類似的東西，結果就掉出了google html5 native code計畫，html 5大業的確很有潛力，sand box的環境也可能提供比較好的安全性，不過native code計畫看起來還不太成熟，目前只有gcc的環境，而我是個用visual studio的軟派程式員，只好放棄這個方向。不過flash，或unity引擎，都是在html 5的native code計畫出現前就有的東西，顯然有其他的方式可以達成，經過一堆亂七八糟的關鍵字搜尋，終於找到了關鍵字是甚麼---NPAPI和ActiveX。

NPAPI是給非IE用的瀏覽器plugin API(Firefox，Chrome等等)，ActiveX就是...恩，微軟的IE。這兩個API，都可以讓我們在瀏覽器中，用C/C++寫plugin。另外這也是為甚麼plugin都分IE和非IE兩種...

有關NPAPI的資訊，其實在網路上還滿少的，官方文件和這個blog，我覺得算是比較好的資源。其中那位blog的作者，開發了FireBreath這套可以跨NPAPI和ActiveX的plugin API。另外在codeproject上有一個範例。

因為我只想用OpenGL畫一個三角形，於是我下載了codeproject上的範例修改了一下，把有關scriptable的部分全部拿掉，然後就畫了一個三角形。

真的有興趣的人，可以用svn checkout http://ianjoker.googlecode.com/svn/trunk/npgl下載source code。

稍微紀錄一下NPAPI的設計，首先，他是"真正"的plugin設計，compile好的NPAPI plugin是一個動態函示庫(.dll或.so)，而且，這個plugin理論上可以給FireFox，Chrome，Safari或任何支援NPAPI的瀏覽器使用，而不用重新compile或link任何東西。這與一些不太plugin架構的plugin很不一樣，例如Ogre引擎中的RenderSystem或SceneManager等plugin，只要OgreMain有改變重新compile，這些plugin就必須重新compile或link OgreMain.lib，否則不保證plugin可以用。

可是NPAPI plugin不用重新link卻可以給各個瀏覽器(還包括不同版本，不同compiler等)使用，這是怎麼辦到的呢？好吧，原因很簡單，因為一開始就根本不用link任何.lib。

NPAPI靠的，是用C語言的ABI(Application binary interface)非常統一的特性，幾乎所有的interface都使用C語言制定，其中有三個C的inteface是瀏覽器與plugin的接口。

NPError OSCALL NP_GetEntryPoints(NPPluginFuncs* pFuncs);
NPError OSCALL NP_Initialize(NPNetscapeFuncs* bFuncs);
NPError OSCALL NP_Shutdown();

C的interface，可以利用GetProcAddress(windows)或dlsym(Linux)來取得位址。因此瀏覽器不用去link任何plugin的lib就可以呼叫這三個function。這當然是任何plugin設計的基礎，但是還缺了一半，如果plugin不link瀏覽器的.lib，那plugin就無法呼叫任何瀏覽器本身的function，瀏覽器無法提供任何服務給plugin使用！

解決方案很簡單，NP_Initialize這個function會在plugin被瀏覽器載入時呼叫，這時候會傳進來一個NPnetscapeFuncs，這其實是一個function pointer的table，裡面每個function pointer就是瀏覽器提供給plugin呼叫的function，例如我想跟瀏覽器alloc一塊記憶體，我可以呼叫NPnetscapeFuncs::memalloc。因此plugin不用link瀏覽器的.lib，link這件事情，是在runtime執行NP_Initialize的時候做的。

反向的則是NP_GetEntryPoints會需要我們填function pointer進NPPluginFuncs這個function pointer table，這些function pointers是plugin提供給瀏覽器呼叫的callback，例如當瀏覽器需要new一個新的plugin的instance的時候，瀏覽器會呼叫NPPluginFuncs::newp這個callback，我們必須實做這些function，然後把他們填入NPPluginFuncs交給瀏覽器。

因為我想做的是利用OpenGL畫三角形，想要OpenGL就必須要有window handle，而NPPluginFuncs正好有提供setwindow這個callback，會在瀏覽器建plugin window的時候呼叫，瀏覽器呼叫這個callback的時候，會傳進一個NPWindow struct，這個struct可以拿到window handle！任何一個graphics programmer，只要能拿到window handle就可以解決一切難題！！！

當然，事情永遠不會這麼簡單的...

首先是API的header問題，雖然說理論上這是一個跨瀏覽器的API，包含了npapi.h，npfunctions.h，npruntime.h，nptypes.h四個檔案，不過只要有人的地方，就有紛爭，更不用說瀏覽器這種兵家必爭之地了。我在demo中放了Mozilla的官方SDK版本。我試過在FireFox 3.x或4.x都是ok的，不過很可惜的是Chrome似乎不能用。Google他們自己可能也看到了這個問題，因此他們maintain了一份號稱可以跨平台的header，可惜的是我試過似乎在FireFox下會當掉。我還沒有仔細檢查哪裡出了問題，不過如果真的要寫跨平台的plugin，說不定比較好的方式還是去用FireBreath那套API比較好，否則要自己去處理一些跨瀏覽器的問題。


另外是plugin安裝的方式，按照Mozilla官方文件說法，在windows平台上要去registry註冊一些機碼好讓瀏覽器可以認得plugin放的地方，application的MIMEType，附檔名等資訊等等。不過我試了老半天沒辦法work，去看了codeproject的demo做法是直接用.rc檔內嵌在編譯出來的.dll中了，然後必須把編譯好的.dll丟到(FireFox安裝資料夾)\plugins\這個資料夾下面，如果沒有這個資料夾就自己建一個。當然這好像不是理想的做法，因為plugin無法安裝到我們自己想安裝的地方。另外還有個小地方也很奇怪，那個.rc檔裡面有個語言的選項，因為我的VC是中文版的，所以他預設都設成中文，可是中文的plugin無法用，一定要改成英文才行，這裡也是完全不知所以然

最後，因為plugin畫面更新是lazy的方式，瀏覽器覺得需要更新那個window才會有windows message重畫那個window，當然這樣做無法做real time的遊戲，如果要自己控制更新window，只好自己開另一個thread來建OpenGL context。總之，這只是implementation detail，好讓我可以得到60 FPS的triangle。60 FPS就是比較帥(自high)~

結論是，雖然這不是甚麼很難的技術，不過感覺網路上資源還滿少的，如果真的想要把這鬼東西放進工具，可能很多小細節都會讓實作的人很痛苦吧，而且那個痛苦的人看起來就是我啊...

題外話，IE9的javascript支援真是爛到爆了，編個blogger結果無法存檔也無法publish，而且這已經不是我第一次犯這個錯了。

麥田捕手

"如果對社會有不滿，就改變自己吧，如果不想改變自己，就把耳朵，眼睛，嘴巴閉上，孤獨地過日子吧" -- 草薙素子

"I Thought what I'd do was, I'd pretend I was one of those deaf-mutes."

"一個不成熟的人的特徵，是他願意為某種信念英勇的死去；一個成熟的人的特徵，是他願意為某種信念謙卑地活著。"

看了攻殼機動隊，所以去找了這本名著來看。

OpenGL extensions & code generator

Yeah, OpenGL extensions sucks, but we have to live with it.

To get extensions work on different platforms often means various mechanisms to get the extensions' function pointer, deal with different calling conventions, etc.

The easiest way to deal with such mess is use a library like GLEW and forget about it. But sometimes when I code my own little stuff, I only use a very small set of extensions(often times I just want to test the extensions functionality) , GLEW's mega-header is often very browse/search unfriendly, and if the GLEW's version is out of date, I have to download it again.

I used to code every single extension manually, and it's really boring and repeated work. I don't know if there exist an automatic extensions generator(I know it exist, most extensions lib is generated by such generator, I just have to find an excuse to make my own), give it a file which contain the function definition, and it output the .h and .cpp. Then I put the two files in my project and voila.

I think this is an interesting little project and recently I have been learning Python. So I give it a try using Python.

The gl extension source file looks like this

[core]
void glEnable (GLenum capability)
void glDisable (GLenum capability)
void glBlendFunc (GLenum sfactor, GLenum dfactor)
...

[GL_EXT_texture_compression_s3tc]
...

The generator read each line of the file, then using Python's regular expression module re to parse the line to see if it's an [...], which means a group of extensions. [core] group is special, which contains functions in core GL spec . Other [...] must contains it's extension's name string. And if the line is parsed as function declaration, it is split into three pieces - return type, function name and args list, then it's stored in a Python dictionary using function name as key for latter use.

When parse complete, the generator output .h and .cpp. The .h look like this(with a lot of hassle omitted),

//core
extern void(JGL_API_ENTRY jglEnable) (GLenum capability);
extern void(JGL_API_ENTRY jglDisable) (GLenum capability);
extern void(JGL_API_ENTRY jglBlendFunc) (GLenum sfactor, GLenum dfactor);
...
//GL_EXT_texture_compression_s3tc
...

namespace joker
{

struct glCaps{
bool support_core;
bool support_GL_EXT_texture_compression_s3tc;
};

void InitGL(glCaps** caps);
}

then in my project, I just call InitGL(&caps), init the extensions and get the caps, if the extension is supported, I can call it's jglXXX function.

the generator is halfway done, the caps check is not implemented yet, and I also want to add log version of gl functions. And it only support Mac/Windows.

The source can be found here. and the extension def file here.

Yeah, many stuff looks like Quake 3's qgl, because I steal most ideas from it :) .

And of course this is only a toy, any production code should use GLEW instead.

P.S. Now I am really confused, what's the difference between core/extension? OpenGL sucks...