Is graphical shader system really that good?

每當我們看到什麼的遊戲引擎有著一個可視化的 Shader 系統後都會覺得它分外強勁；
它一般被認為可以令製作流程更順暢，但這概念是否每一處也適用哩？讓我們聽一聽反對的聲音吧。

• Graphical shader systems are bad

• Commenting on graphical shader systems

• Shader Workflow - Why Shader Generators are Bad

綜合各人的要點：

• 把電腦語言可視化不是一種萬靈丹。
  
  
• 用於非實時的 Rendering 還不錯，但用於講求高效率的實時 Rendering 就會帶來問題。
  
  
• 經可視化工具產生的 Shader 一般都比手寫的來得低效。
  
  
• 太容易去讓美術師建造數以千計獨一無二互相無關的 Shader，使後期整理成為惡夢。
  
  
• 削弱美術師和程式設計師之間的溝通。
  

編程花招的謎思

微軟快要推出下一代 Visual Studio 2010，它對於 C++0x 的支持最令我期待。
儘管 C++0x compiler 還未成熟與普及，已有工程師把弄新的語法，創造耀眼花招。
其實我也非常喜歡耍玩語法上的把戲，但我亦知道它會帶來什麼災害。
以下文字引述自花招裡的一篇回覆，也是我心裡想說的：

Interesting acrobatics, but I am a KISS fan.

I prefer not to mandate a C++ black belt (with several Dans on occassion) on coworkers who try to understand and modify my code, so thanks but I'll pass.

Is there anything in the above code that cannot be done in plain C in a way that 90% of the dev population can understand and 80% can modify/extend without a mistake?

Why do architects feel so compelled to save the world by providing infrastructure and plumbing for everything conceivable under the sun?

What about memoization? If I am in such a corner case where caching the results of a function call will *actually* improve performance, what makes you think I would opt for an obscure and totally incomprehensible generic template that I cannot understand or debug, rather than a custom-tailored, totally non-reusable, top-performing, totally understandable and debugable solution?

Don't get me wrong, I am not an anti-STL, do-it-yourself (CMyHashTable, CMyDynamicArray, CMyOS) gangho. I am just a KISS fan (including the rock band). If something can be done in a way that is simpler, easier to understand, debug and extend, then I prefer the simpler way.

I just get so frustrated when people do all this acrobatic stuff in production code just because (a) they can do it (b) it's cool to do it, without thinking back a lil'bit or actually having mastered the 'tools' they are using.

A similar example is 'patternitis'. I have seen countless C++ freshmen reading the GangOf4 Design Patterns book and then creating a total mess in everything, like deciding to implement the Visitor pattern on a problem that required Composite and ended up coding a third pattern alltogether from the same book, still naming the classes CVisitorXYZ (probably they opened the book on the wrong page at some point).

I have met exactly 1 guy (I called him the "Professor") who knew C++ well enough and had the knowledge to apply the patterns where they ought to be applied. His code was a masterpiece, it worked like a breeze, but when he left, none else in the house could figure things out.

So what's the point with these Lambda stuff really? Increase the expression of the language? Are we doing poetry or software? Why should we turn simple code that everyone understands into more and more elegant and concise code that only few can understand and make it work?

I have been coding in C (drivers) and C++ for 15 years and not once was I trapped because I was missing lambda expressions or similar syntactic gizmos.

So what's the point really? Please enlighten me. I don't say that *I* am right and *YOU* are wrong. I am saying that I don't see, I don't understand the positive value that these things bring in that far outweighs the problems they cause by complicating the language.

當然，流行/藝術派與實際派的存在都是有意義的；否則編程世界不是一團糟就是停滯不前。

我認為最好的 Pdf 閱讀器

不知不覺 Adobe Acrobat Reader 已經出到第九代了.
在每一次更新的時候, 大家有沒有想過其實可能更有好的選擇呢?
我有一個好推薦, 它就是 Foxit Reader.

Foxit 的描繪品質和速度與 Acrobat 不分上下, 但記憶體用量和啟動時間就遠勝 Acrobat; 更不用安裝 , 細小可攜 (僅一個 5MB 的可執行檔).

以下的測試是基於網上的一篇文章:

	Adobe Reader 9	Foxit Reader 2.2
啟動須時 (秒)	21	7
記憶體用量	74MB	25MB

縱然 Foxit 缺少某些(許多人都不常用的)功能, 它帶來的眾多好處立即使我把 100 多MB的 Acrobat Reader 從系統中撤除.

程式語言效率大比拼

有天正在尋找腳本語言的時候無意間發現這個名為 The Computer Language Benchmarks Game 的網站.
那裡的 benchmark 數據覆蓋多達 76 種語言加編輯器的組合, 19 個試驗程式(大部分還有提供源始碼).
不過, 儘管那裡提供的資料準確無誤, 它所包含的參考價值仍然有限. 問題在於那些試驗程式都過於細小, 以及只有單一的功能. 在一個複雜的應用程式 (如 3D Game Engine), 有大量不同種類的資料需要處理, 因此記憶體的存取很容易成為瓶頸.
一個好例子就是 Java/.Net. 有數據顯示 Java/.Net 可以快過 C/C++, 不過當你走出試驗程式返回現實, 你會感到 Java/.Net 總是慢半拍的.

其實那網站的第一段就表明了:

Benchmarking programming languages?
How can we benchmark a programming language?
We can't - we benchmark programming language implementations.

How can we benchmark language implementations?
We can't - we measure particular programs!

C++ friend class

有些時候我們會利用 C++ 中的 friend 關鍵字來設定類別的好友.
但可惜一個 friend 宣告只會對一個類別產生作用:

class Texture {
public:
 friend class IResourceLoader;
 uint width() const { return mWidth; }
 uint height() const { return mHeight; }
 private:
 uint mWidth;
 uint mHeight;
};

class IResourceLoader {};

class JpegLoader : public IResourceLoader {
 void load() {
  // ...
  mTexture.mWidth = 128;  // Compiler error!!
 }
};

以上的 Texture 類別有成員 mWidth 和 mHeight, 它們都只應由 IResourceLoader 的實作類別所能更改. 幸好有 Inner class 可以幫到我們:

// Texture.h
class Texture {  
public:  
 friend class IResourceLoader;  
 uint width() const { return mWidth; }  
 uint height() const { return mHeight; }  

 // We declare a templated inner class here (but not defined yet)
 template class PrivateAccessor;

 private:  
 uint mWidth;  
 uint mHeight;  
};

class IResourceLoader {};  

// JpegLoader.cpp
// Define Texture::PrivateAccessor here, access what ever you want
template<>
class Texture::PrivateAccessor {
public:
 static size_t& width(Texture& texture) {
  return texture.mWidth;
 }
 static size_t& height(Texture& texture) {
  return texture.mHeight;
 }
};
typedef Texture::PrivateAccessor Accessor;

void JpegLoader::load() {
 // ...  
 Accessor::width(mTexture) = 128; // Ok! no problem
 Accessor::height(mTexture) = 128;
}

你可能會認為這樣做等同把所有成員變為公開 (public), 事實上這個方案的精神在於迫使程序員清楚自己正在做什麼, 而不是錯誤地更改了變數.

學習, 再學習

經過三年的遊戲引擎開發後, 縱然我從中已學到了許多; 但還要學的更多, 無窮無盡的多.
僅僅 C++ 這令人又愛又恨的東西我已學了十年 (Teach yourself programming in ten years).
那其實是一件好事, 我就是喜歡學習的過程.

華而不實的東西我已做過不少 (如 Exmat ).
現在我正集中焦點學習怎樣去設計簡單清晰的軟件.

而這裡正是用來把這過程記錄下來, 希望大家多多指教.