L：為什麼塌洗會來啊？
A：塌洗？誰是塌洗？
L：就是那個XXX啊(為尊重當事人隱私，加上馬賽克處理)
A：喔，原來那念做塌洗啊？我以為是催洗
A：塌洗？誰是塌洗？
L：就是那個XXX啊(為尊重當事人隱私，加上馬賽克處理)
A：喔，原來那念做塌洗啊？我以為是催洗
- 1月 31 週日 201001:42
某日的閒聊
- 12月 05 週六 200922:05
Radial Blur
Radial Blur是一種動態模糊技術，通常用在賽車遊戲與FPS等。在賽車遊戲中能夠給於速度感，就像時感賽車中使用氮氣噴射一樣
FPS中通常是在玩家被打中時或是快死亡的畫面表現。
接下來將說明如何做出這樣的效果
- 7月 22 週三 200923:15
為什麼Normal要乘上經過Inverse和Transpose之後的World Matrix
normal為什麼必須要乘上world matrix的inverse和transpose之後的矩陣，而不是直接乘上world matrix。其實我以前也搞不懂，為什麼有些Shader上是將World Matrix定義為invtransposeWorldMatrix(大致上是這樣定義)而有些卻是直接定義為WorldMatrix(大致上是這樣定義)。在看了Real-Time Rendering之後了解到真正的用意是什麼，將說明如下
這張圖的左邊是一個三角形物體，在這個斜邊上的Normal垂直於斜邊。但是在經過non-uniform scale之後就會像右圖一樣因為縮放的關係像上延伸，因此斜邊上的Normal已經沒有跟斜編成垂直的。怎麼樣，很可怕是吧，如果這時候利用這個normal來做各種計算，所得到的結果都將是錯誤的。
那要怎麼避免呢，首先我們來了解一下什麼是non-uniform scale。照字面上的意思就是非相等的縮放，也就是在3D空間中(或是2D)，每個軸向的縮放值是不一樣的。相對的uniform scale就是個軸向縮放值相等。所以我們知道，只有在non-uniform的狀況下會有這樣的情形發生，所以通常在很多引擎的設計上，會捨棄non-uniform scale，來統一shader的normal計算方式，或是針對各種不同狀況來決定是要執行的shader。
- 5月 10 週日 200921:56
Prince of Persia - 波斯王子 for XBOX 360
玩過波斯王子系列的人都知道
豐富流暢的動作冒險一直是它賣點
對我來說，一個能經過20年歷史仍歷久不衰的老字號遊戲
不斷的創新進步應該是它最主要的一個原因
- 4月 16 週四 200921:46
節省記憶體的好方法 --- Normal Map的壓縮
因為最近專案逐漸進入收尾的階段，
效能便成首要解決的目標，
所以 不管是效率太慢還是佔太多記憶體的壞蛋，
都要一一挑出來解決掉，
效能便成首要解決的目標，
所以 不管是效率太慢還是佔太多記憶體的壞蛋，
都要一一挑出來解決掉，
- 4月 03 週五 200900:28
提升效能的方法(一)
做次世代的遊戲真是難阿！要畫面好看又要能跑的順，真恨不得自己改主機，把記憶體加大，把CPU和GPU變快。這當然是辦不到的事，只好想破腦筋來試試各種方法來加快減少系統的負擔。
其實不管做什麼樣平台的遊戲，一個畫面最多可以畫多少個東西往往是最難評估與測試的。這要考慮到面數，貼圖數量、還有Pixel Field Rate等等的瓶頸所在。既然是開發次世代遊戲，畫面當然不能太差，因此貼圖、面數等等往往都是高標準，再者為了表現場景的壯闊與美感，場景上的物件數量與複雜度都是很可怕的數據。更何況在加上特效與AI等等，這都是效能的瓶頸所在。
遊戲之所以是遊戲，就是要跑的動，讓玩家能夠順暢的遊玩。畫面再漂亮，Gameplay設計的在怎麼好，FPS不到30甚至只有10，只會讓玩家想折片罷了。當然，要讓遊戲跑的動，絕對不是企劃修改規則或是美術把model做的很Low(當然如果資料有問題也是要修改)就可以跑的動。曾經聽過有人一個畫面2萬面FPS還不到10，而且還是用9600來開發，可見效能不彰程式佔了很大的因素。畢竟寫不好的Code，再怎麼優化資料結果並不能改善許多。
要提申效能沒有不二法門，往往在於經驗與不斷的修改與測試，以程式人員來說：
1. 首先就是要最佳化自己的程式碼，能夠預先計算好的資料，就不要在每個Frame都計算或是在每個迴圈裡都做相同的計算等等。
2. 盡量使用硬體加速的指令集。比如說向量的運算，以Dot來講是X1 * X2 + Y1 * Y2 + Z1 * Z2。看似很簡單的運算，卻需要CPU幾十個指令的價格，如果真的只有處理一次那都無所謂。但是遊戲中對向量的計算是很頻繁的，這樣的計算往往每個Frame要做幾百幾千次，這樣看起來就不便宜了。如果能用硬體加速的指令集，將三次乘法和兩次加法用一個指令來取代，哇！是不是快很多ㄚ。
3. 提供更多的技術支援給其他部門。
4. 不斷的進修，提升自己的專業能力。
以美術來說：
1. 所做的資料要以能放進遊戲中執行為主，實際去看問題所在，並與程式和企劃討論修改方向。
2. 製作的檔案要符合規定，面數，頂點數，貼圖格式，記憶體大小，Bone的數量等等都要依據程式給的規範來製作。
3. 製作模型時要在前製時期就做好彈性，避免修改過多，也不要害怕修改。畢竟玩家不是美術，對於美感的呈現見仁見智，不需要位了堅持而降低了遊戲本質。
其實不管做什麼樣平台的遊戲，一個畫面最多可以畫多少個東西往往是最難評估與測試的。這要考慮到面數，貼圖數量、還有Pixel Field Rate等等的瓶頸所在。既然是開發次世代遊戲，畫面當然不能太差，因此貼圖、面數等等往往都是高標準，再者為了表現場景的壯闊與美感，場景上的物件數量與複雜度都是很可怕的數據。更何況在加上特效與AI等等，這都是效能的瓶頸所在。
遊戲之所以是遊戲，就是要跑的動，讓玩家能夠順暢的遊玩。畫面再漂亮，Gameplay設計的在怎麼好，FPS不到30甚至只有10，只會讓玩家想折片罷了。當然，要讓遊戲跑的動，絕對不是企劃修改規則或是美術把model做的很Low(當然如果資料有問題也是要修改)就可以跑的動。曾經聽過有人一個畫面2萬面FPS還不到10，而且還是用9600來開發，可見效能不彰程式佔了很大的因素。畢竟寫不好的Code，再怎麼優化資料結果並不能改善許多。
要提申效能沒有不二法門，往往在於經驗與不斷的修改與測試，以程式人員來說：
1. 首先就是要最佳化自己的程式碼，能夠預先計算好的資料，就不要在每個Frame都計算或是在每個迴圈裡都做相同的計算等等。
2. 盡量使用硬體加速的指令集。比如說向量的運算，以Dot來講是X1 * X2 + Y1 * Y2 + Z1 * Z2。看似很簡單的運算，卻需要CPU幾十個指令的價格，如果真的只有處理一次那都無所謂。但是遊戲中對向量的計算是很頻繁的，這樣的計算往往每個Frame要做幾百幾千次，這樣看起來就不便宜了。如果能用硬體加速的指令集，將三次乘法和兩次加法用一個指令來取代，哇！是不是快很多ㄚ。
3. 提供更多的技術支援給其他部門。
4. 不斷的進修，提升自己的專業能力。
以美術來說：
1. 所做的資料要以能放進遊戲中執行為主，實際去看問題所在，並與程式和企劃討論修改方向。
2. 製作的檔案要符合規定，面數，頂點數，貼圖格式，記憶體大小，Bone的數量等等都要依據程式給的規範來製作。
3. 製作模型時要在前製時期就做好彈性，避免修改過多，也不要害怕修改。畢竟玩家不是美術，對於美感的呈現見仁見智，不需要位了堅持而降低了遊戲本質。
- 3月 26 週四 200900:16
惡靈古堡5
Biohazard(惡靈古堡)，想必是許多玩家最愛的遊戲之ㄧ
在Biohazard出來之前的恐怖驚悚遊戲，大部分都是解謎或是圖片居多像是D之食桌或是弟切草等
Bioharzard開創了恐怖驚悚遊戲的另一個境界，讓玩家知到恐怖遊戲也可以這樣玩
早期的Bio系列(0~3代與聖女密碼)解謎的成分很多，比如要輸入密碼和調配解藥等等。四代之後就把動作要素加重，玩家可以對許多的場景原件做互動，面對的敵人也不再是死板板的殭屍，而是有智慧的人類，只是被病毒給感染了。
- 3月 21 週六 200912:25
新書上架----大話設計模式
程式設計高手為了程式碼的再利用性與延展性
會把程式設計成許多彈性很高的小系統
看過設計模式的程式往往會功力大增，就像練過九陽神功一樣
內功渾厚並且充滿正氣
以下介紹一本關於設計模式的新書，希望可以讓各位Programer的功力更上一層樓
- 2月 14 週六 200923:17
快打旋風
快打旋風(Street Fighter)在玩家引頸期盼之下，歷經了10年之久
卡普空(CAPCON)終於推出了最新的快打旋風4家用版
雖然早在去年就已經有大型機台在市面上可以玩
但是在台灣實在是少的可憐，就連萬年的湯姆熊都沒有
更何況我們這種上班族更是沒有時間去玩樂阿
感謝卡普空的移植
讓我又可以開始快打旋風的日子了
說到了快打旋風，一定要好好的來介紹一下
- 2月 12 週四 200923:36
Gears of War - 戰爭機器
由於之前的心得被人說拖垮了BLOG文章水平
這次就來寫一些有點技術性的東西好了
第三人稱射擊遊戲有個很難避免的現象：穿牆
程式研究 (6)