iPhone學習雜感

先跟著Apple的教學跑過一個簡單的iPhone程式(First iPhone Application)會有利於學習動力，一開始就去k Objective C會讓人頭昏眼花。

Stanford大學有一個課程是apple在大學開的iPhone程式課程，還有影片可以看。它會從Objective C開始說起，目前為止還在繼續上，聽力ok的話是不錯的教材。

先別想說有中文的書可以看了啦~連簡體版的都只有一本而且台北還找不到。Apple的文件提供得很豐富了，乖乖k吧。網路上有一些中文的教材可以抓來看，我自己是認為要先trace或跑過一次First iPhone Application會比較容易了解他們在說的是什麼。

要做遊戲的話恐怕就要直攻OpenGL ES了，這就不是apple會講的很多的東西了，乖乖去找相關的資料來看比較快。另外要記得，iPhone是OpenGL ES 1.1。

XCODE的快捷鍵與VS完全不同(廢話)，去找幾個常用的多用幾次就背起來了，絕對比起慢慢地按滑鼠好多了(尤其在13吋的macbook時...眼睛都快脫窗了)。

就這樣啦，有進展再說。

關於Deferred Rendering的一些想法

1. 應該是未來的趨勢。其壞處之一是需要大量VRAM，但在硬體的快速進展下應該不成問題。
2. MRT數量問題應該也會被硬體進步下解決。
3. Lighting model要全部用同一個的問題也可能被硬體進步後MRT數量變多解決，但相對的pixel shader也要強悍很多才行，不然耗費很多計算在根本沒有作用的東西上(像SSS或parallax occlusion)會跑不動。我想Lighting model部分要依靠硬體進步解決有點難。
4. Lighting model雖然不能變，但是shader依然可以在做一定程度的變化，只是要在一開始輸出給MRT時就先做好計算。像valve source engine裡面用到的Radiosity normal mapping就沒辦法跟一般lighting model混用，但carton render的描邊就可以。因為後者可以直接輸出成只有ambient來做lighting，而前者卻必須要在lighting查照三張不同座標的light map。
5. CPU近期內不會有大幅的速度躍進，能加速的部分看來只有多核心的運用，對於大量的物件與大量燈光的配對(計算物件是否在燈光內以判定要不要計算lighting)可能有一定的幫助，但對與整體繪製速度幫助有限。畢竟大量燈光造成的問題是同一物件不能接受那麼多光源(shader register有限)，且要繪製後才被z-test拿掉的over-draw過多。
6. DX11不知道有沒有將z-test在進pixel shader就先做的機制做出來，如果有的話deferred rendering的好處會下降非常多。但shader register有限的問題依然沒被處理掉。
7. Z-Pass在現階段對over-draw也會有一定的幫助。但同樣的shader register有限的問題還是沒得解。
8. 我沒試過multi-pass來做多盞燈可以做到什麼程度，但我想CommitChanges會吃掉很多效能。另外公司同仁提過用一張貼圖來描述所有燈光的做法我想也是可行，不過因為shader內的loop不可以用即時讀進來的數字(好像是因為PS2.0不是真正的loop而是將HLSL loop展開的關係)，所以只能不管實際有多少盞燈都要跑一個固定的上限值。另外，shader model 3對loop的限制是24，也就是說即使這樣做也只能跑24盞燈。
9. 需要用到多盞燈在同一物件繪製的狀況大多在Terrain上。
10. 看來想要有超過24盞燈在同一個物件作用的話還是乖乖去寫deferred rendering好了。

開張大吉

這裡是用來寫一些我對遊戲開發的一點想法，留做未來檢視自己思路的紀錄。