【圖形學與遊戲程式設計】開發筆記-入門篇3:d3d,opengl以及GPU
阿新 • • 發佈：2019-02-17
首先是遊戲程式為什麼需要單獨的運算器。大家如果學過演算法的話，應該都聽聞過時間複雜度這個東西，也就是O(n),O(n^2) 這些，那麼接下來我們大致的估算一下一個遊戲每秒需要運算的n的次數。首先我們將遊戲的演算法分為三種，其一是幾何體級別的演算法，n的次數與之前我們說的幾何體的頂點以及索引數量有關係，其二是光柵化級別的演算法，這一部分的n的次數是所有幾何體的三角面的所包住畫素點數量之和，一般會比幾何體的向量點數量多個好幾倍。其三是螢幕空間的演算法，複雜度就是螢幕畫素點的個數。隨著遊戲質量的逐步提升，第一種演算法，也就是幾何體級別的演算法的n會越來越大，現在的一個大型遊戲描述一個場景的頂點就已經可以達到幾百萬甚至幾千萬的數量級了。然後是光柵化部分，這裡光柵化之後的點一般來說是高於幾何體的點數量的，目前一個場景估計最終光柵化的點也會有個幾百上千萬。最後是螢幕空間的演算法，這個最好估計，對於一個高清螢幕來說n的數量就是1920*1080個點。也就是大概來說是200萬左右，可以看出比前面的都少。因此現在很多演算法的優化
都企圖將光柵化的部分轉移成螢幕空間的部分，像ssao，deferred lighting這些。那麼現在我們說的是運算出一個圖片所需要的n的次數，對於一個遊戲來說，一秒鐘要想流暢執行的話至少得有個30幀才算是靠譜的吧，那麼n的數量還得乘以30。那麼現在的n的數量大家可以想象大概是多少了，大概已經過億了。好，那麼現在我們回頭來看演算法複雜度，當n過億的時候，神馬演算法才能保證他流暢執行呢？很明顯，以當代的運算來說，只能是O(n)的演算法。但是事實上，因為這個當量過大，我們不得不考慮演算法的常數係數的大小，假設我們所有的渲染演算法的常數項加起來有幾十左右(其實一次抗鋸齒估計就得個幾十次，再加上ssao，shadowmap的柔化估計上百次都有可能