[電腦圖學] Gamma Correction (II)

由先前的討論，知道螢幕輸出的誤差可因資料處理而修正，在此將更進一步的討論修正方法，並舉一些實例來展示差異，可觀察是否具備前篇文章所描述的狀況。

寄件者 Melbourne - 2010.07.17~2010.07.25

[電腦圖學] Gamma Correction (I)

最近回想起 GDC 2010 有一場由《祕境探險 2》(《Uncharted 2》) 的繪圖工程師以「HDR Lighting」為主題的演說，分享他們如何將一個想法與概念透過繪圖技術達到，演講過程十分精彩。

遊戲中的色調設計，即便對於有經驗的美術總監而言都是十分嚴峻的考驗，但對於新人絕對是最容易被忽略的細節之一。為什麼色調的定義如此重要？因為它屬於最核心的一種設定，引響遊戲風格，控制著玩家對時間、氣候與環境氛圍的感受。因此能明確的定義色調，才能引領著龐大的美術團隊朝正確的目標前進。對於色調的了解真的如此重要嗎！...我想只有痛過一次你才知道。因此我響探討 Gamma Correction 的議題，為什麼要這麼做以及其影響。

寄件者 Melbourne - 2010.07.17~2010.07.25

[C++ 程式設計]嵌入式系統繪圖函式庫， OpenGL ES !!

有設計過 3D 圖形程式的人應該都接觸過 OpenGL (或是DirectX)。而使用過 OpenGL 開發應用程式一定常感到困擾，因為它還是屬於序列式( procedural library)的函式庫，這意味著若我們要使用某些特定功能時，可能同時要透過數個函式並熟知其複雜的相依性，這容易造成程式錯誤又難以分析問題。另外 OpenGL 另一個令人頭痛的問題，就是規格會依不同廠商而產生差異性，除了使用上有許多條件與限制之外，函式與參數的名稱有時變得十分冗長又不直覺。

[C++ 程式設計]Visual Studio 專案精靈

今天介紹 Visual Studio 的「Custom Wizard」，許多人會稱呼他為專案精靈，在此我也以專案精靈稱呼。

撰寫一些程式時，發現建構專案的過程大多步驟都千篇一律但卻又十分繁瑣，每當要建立類似的專案時，前期的準備工作總是令人感到特別痛苦。不過令人慶幸的，專案精靈是一個建立同性質專案的好幫手。舉了例子，我常撰寫簡單的 3D 應用程式，因此我需要用 Win32 視窗程式設計與 OpenGL 等 3D 繪圖 API 來開發程式，但光是一個簡單的視窗開啟與前期的初始化工作就得寫上數百行的程式碼，而往往應用程式大多設定工作又大同小異，因此每要另開一新專案時，總令人感到痛苦萬分。

[C++ 程式設計]加速編譯方法 - 分享函式庫

完整的編譯過程，除了編譯時間(compile time)之外，另一個花費時間的編譯工作就是連結時間(linking time)。linking 的目的是將所有編譯後的目標檔 (*.obj) 組合成可執行的執行檔，因此組合的動作會隨程式的複雜度越高花費越多時間。因此是否曾思考過，那些已經被編譯過的程式以及執行檔可不需重新經過編譯與組合的程序，能有效的被重複利用。

 分享函式庫 (Share Libraries)

使用 share libraries 的方法可避免重複編譯與冗長的連結時間，

[C++ 程式設計]加速編譯方法 - 編譯器設定

編譯器的環境設定也是引響編譯速度的主要原因之一，而環境設定的議題可以從許多的面向討論。

 最佳化設定

首先最佳化的設定，在 Visual Studio 或是 gcc 上都有相似的設定，不同的最佳化程度可能區分成 O1 、 O2 、 O3 等，而隨著最佳化的效果越好，所需要花費的編譯時間也相對越高。通成數字越大表示使用越高級的最佳化，因此在除錯或是想要快速編譯時，可以選擇較低階的最佳化設定，如 O1，或是關閉任何最佳化選項。

[C++ 程式設計]加速編譯方法 - 相依性問題

降低程式相依性

儘可能減少在 header 檔中 include 多餘的 header 檔。因為這樣會提升物件之間的相依性，當我們更動 header 檔 A.h 時，編譯器會找出所有 include "A.h" 的 header 檔，會將他們也當做更動過的檔案，所有更動過的檔案都必須重新被編譯。因此沒有妥善規劃好標頭檔的相依性，將會導致許多的程式都需要被重新編譯，這將會浪費更多的編譯時間。