用Unity最不習慣的就是 一切都是gameobject, 連要畫個 mesh也要object.
gameobject.transform. 一堆.transform相關的函數........
根本沒必要..
兩個相同的mesh,用gameobject, 要存兩分mesh，
多個不就更麻煩了? 還有 動態 產生mesh，又要複製go...
又要釋放..... mesh的資料 就是一次載入就好.
找了半天， 終於找到: Graphics.DrawMesh()， 只要寫在Update()就跟以前用c++ 迴圈一樣的寫法了。最主要是想畫很多個相同的mesh.
public static void DrawMesh(Mesh mesh,
Matrix4x4 matrix,
Material material,
int layer,
Camera camera = null,
int submeshIndex = 0,
MaterialPropertyBlock properties = null,
bool castShadows = true,
bool receiveShadows = true,
bool useLightProbes = true);
好用的這個函數就夠了。
(Mesh mesh,
Matrix4x4 matrix,
Material material) 參數這幾個就夠了.
這就很像 一般用 d3d 自己會寫的render含數 會傳的參數。
unity 的 Matrix4x4 函數也很難用， 為何不直接照D3D的 Matrix函數就好?
學3D最重要的就是 Matrix,， 弄懂這個就夠了。
----------------------------------------------------------------
還有在 Update() , 直接把整個logic寫在裡面加上Graphics.DrawMesh().
速度會比事先算好gameboject的位置， 還慢。
所以 只執行一次的 logic, 變成要先算好位置， 存起來， 在Update()的 Graphics.DrawMesh(). 只畫位置。
所以這就是跑 script的缺點。
void Update () {
for (int i = 0; i < m_szRenderWin.Count; i++)
Graphics.DrawMesh(m_szRenderWin[i].mesh, m_szRenderWin[i].matrix/*
Matrix4x4 */, m_Material, 0);
}
citywar圖形怎麼外包?
當我還有印象:紀錄一下citywar圖形怎麼外包。
一.全部圖形費用是4萬台幣。
二.大約外包10位美術人員(這裡面沒有一位見過面)
下面都是一個單位一個外包美術
1.房子A--->會這個的人相當少(所以美術多加強這種大型的建物技術)
2.房子B 樹 紅綠燈 路燈 停車場(這好像有一個團隊)
3.車子 人物x2 sniper
4.手槍 摩托車
5.加油站 (忘了)
6.UI,特效(會特效材質的也很少)
7.全部的人物動作-->會這個的人相當少
8.這最慘，本來天真，以為4000圓全部外包，結果時間到了只拿到完全不能用的圖形。
所以就改用: 只外包單一個模型(像上面)然後我自己組。
9.我也算的話，整個場景是我擺的，斑馬線....其他無聊的修圖bug。
時間可能超過半年 。
當初是想做一個完全商業化的遊戲，之後覺得這沒甚麼必要，可以省掉更多錢。
所以程式要圖的話 多花點時間上網找， 管他有版權沒版權，反正要商業化時在換掉，
可以省掉更多錢(應該可以省掉1半)。
圖形整體看起來沒多大衝突，我是直接抓一個街景內的物件，所以圖型參考是給照片。
圖形覺得應該建 一個 淡水馬偕故居 赤崁樓 這樣比較好。 有地標比較好。
一.全部圖形費用是4萬台幣。
二.大約外包10位美術人員(這裡面沒有一位見過面)
下面都是一個單位一個外包美術
1.房子A--->會這個的人相當少(所以美術多加強這種大型的建物技術)
2.房子B 樹 紅綠燈 路燈 停車場(這好像有一個團隊)
3.車子 人物x2 sniper
4.手槍 摩托車
5.加油站 (忘了)
6.UI,特效(會特效材質的也很少)
7.全部的人物動作-->會這個的人相當少
8.這最慘，本來天真，以為4000圓全部外包，結果時間到了只拿到完全不能用的圖形。
所以就改用: 只外包單一個模型(像上面)然後我自己組。
9.我也算的話，整個場景是我擺的，斑馬線....其他無聊的修圖bug。
時間可能超過半年 。
當初是想做一個完全商業化的遊戲，之後覺得這沒甚麼必要，可以省掉更多錢。
所以程式要圖的話 多花點時間上網找， 管他有版權沒版權，反正要商業化時在換掉，
可以省掉更多錢(應該可以省掉1半)。
圖形整體看起來沒多大衝突，我是直接抓一個街景內的物件，所以圖型參考是給照片。
圖形覺得應該建 一個 淡水馬偕故居 赤崁樓 這樣比較好。 有地標比較好。
程式語言就是最好的邏輯訓練
"邏輯"濫用指數可能是第一名，根本沒幾個人知道"邏輯"是甚麼。
談 邏輯沒多大意義，談甚麼樣的訓練可以培養邏輯？
很多教邏輯的課程 書 都很無聊 。 最接近邏輯的是 數學上的證明題。
缺點是答案都有了，真實的世界是不會先給答案的。
自從電腦出現後，所有的邏輯課程都變的一點意義都沒有了。
因為電腦程式語言就是把邏輯直接實現的 最好的科學。
int array[100]; //有100個隨機整數的數字，從這裡面挑出你想要的數字
1. N>=30 而且 N <= 80. //這樣怎麼寫？
if( N>=30 && N <= 80 ){ Push(N); }// 就這樣而已 跟若P則Q很像，但是更嚴謹
2. N<=30 或者 N >= 80.
if( N>=30 || N <= 80 ){ Push(N); }
3. N<=30 或者 N >= 80 而且是偶數
if( N>=30 || N <= 80 && N%2==0 ){ Push(N); }
我不大確定這個對不對。 不過我通常不會這麼寫。
if( N>=30 || N <= 80 )
{
if( N%2==0 ){ Push(N); }
}
多麼好的邏輯訓練。
談 邏輯沒多大意義，談甚麼樣的訓練可以培養邏輯？
很多教邏輯的課程 書 都很無聊 。 最接近邏輯的是 數學上的證明題。
缺點是答案都有了，真實的世界是不會先給答案的。
自從電腦出現後，所有的邏輯課程都變的一點意義都沒有了。
因為電腦程式語言就是把邏輯直接實現的 最好的科學。
int array[100]; //有100個隨機整數的數字，從這裡面挑出你想要的數字
1. N>=30 而且 N <= 80. //這樣怎麼寫？
if( N>=30 && N <= 80 ){ Push(N); }// 就這樣而已 跟若P則Q很像，但是更嚴謹
2. N<=30 或者 N >= 80.
if( N>=30 || N <= 80 ){ Push(N); }
3. N<=30 或者 N >= 80 而且是偶數
if( N>=30 || N <= 80 && N%2==0 ){ Push(N); }
我不大確定這個對不對。 不過我通常不會這麼寫。
if( N>=30 || N <= 80 )
{
if( N%2==0 ){ Push(N); }
}
多麼好的邏輯訓練。
C++跟JavaScipt
巴別塔（也譯作巴比倫塔，或意譯為通天塔），據《聖經·創世記》第11章記載，當時人類聯合起來興建希望塔頂通天能傳揚己名的高塔。為了阻止人類的計劃，上帝讓人類說不同的語言，使人類相互之間不能溝通，計劃因此失敗，人類自此各散東西。
這說明了目前程式語言混亂的情形。
程式語言就只分兩種，能編譯成機器碼，跟不能編譯成機器碼(script language)。
所以除了c++以外，你看到的幾乎都是script language。
java， c# ，VB也是 script language， 網頁用的也都是script language。
混亂的就是這 script language部分。
其實語言定義的愈嚴格，愈容易學。
C裡面的每個變數宣告，例如 int i; 就會直接表明這個變數佔了多少個byte，寫得很死，型態也清楚。不用懷疑。
javascipt： var i; 你根本不知道這個i是甚麼？ 字串？整數，......通通不曉得，多少個byte?不曉得。
javascript最後導致最佳化很困難。javascript 函數物件很多寫法都很混亂，很多種寫法。
不管是debug跟最佳化，最後就是個大麻煩。沒人會想用javascript寫超過10萬行的程式。
這種因為網頁興起的語言的特性本來就是如此， 簡單 方便入門， 網頁快速看到結果，
寫一行 javascript， 瀏覽器幫你做了幾百行的工作， script language看起來很神奇，
混亂的語言結果就是 巴別塔。
這說明了目前程式語言混亂的情形。
程式語言就只分兩種，能編譯成機器碼，跟不能編譯成機器碼(script language)。
所以除了c++以外，你看到的幾乎都是script language。
java， c# ，VB也是 script language， 網頁用的也都是script language。
混亂的就是這 script language部分。
其實語言定義的愈嚴格，愈容易學。
C裡面的每個變數宣告，例如 int i; 就會直接表明這個變數佔了多少個byte，寫得很死，型態也清楚。不用懷疑。
javascipt： var i; 你根本不知道這個i是甚麼？ 字串？整數，......通通不曉得，多少個byte?不曉得。
javascript最後導致最佳化很困難。javascript 函數物件很多寫法都很混亂，很多種寫法。
不管是debug跟最佳化，最後就是個大麻煩。沒人會想用javascript寫超過10萬行的程式。
這種因為網頁興起的語言的特性本來就是如此， 簡單 方便入門， 網頁快速看到結果，
寫一行 javascript， 瀏覽器幫你做了幾百行的工作， script language看起來很神奇，
混亂的語言結果就是 巴別塔。
接下來目標: 找不到目標
很多簡單的 都寫得差不多了, 剩下的就是很困難的.
更簡單說: 找不到code 改, 真的很難寫.
3D圖形 有很多的問題是發生在 寫出來後, 但是常會出現品質低落,
例如:camera 移動時, 特效的部分 會抖動.
例如: cascaded shadow, 當 camera移動時, 影子的邊緣 會抖動.
SSAO也是 camera移動的時候 會抖動.
還有 最簡單的 bloom, 當camera移動時, 會抖動.
(解決這些問題 花的心血 都比原來的特效高)
nVidia 就寫了很多關於 反鋸齒的文章....., 畫面的穩定性很重要.
MSAA、MLAA、FXAA.....
靜態的時候 會有鋸齒,當 camera移動時 鋸齒的部分就會抖動.
更簡單說: 找不到code 改, 真的很難寫.
3D圖形 有很多的問題是發生在 寫出來後, 但是常會出現品質低落,
例如:camera 移動時, 特效的部分 會抖動.
例如: cascaded shadow, 當 camera移動時, 影子的邊緣 會抖動.
SSAO也是 camera移動的時候 會抖動.
還有 最簡單的 bloom, 當camera移動時, 會抖動.
(解決這些問題 花的心血 都比原來的特效高)
nVidia 就寫了很多關於 反鋸齒的文章....., 畫面的穩定性很重要.
MSAA、MLAA、FXAA.....
靜態的時候 會有鋸齒,當 camera移動時 鋸齒的部分就會抖動.
發佈 citywar techdemo ver2.4 HDR + FBX
檔案下載 27 mb
https://app.box.com/s/v3l1us2rhpu2hnzictx9
增加 HDR + FBX
增加 新的3層 cascaded shadow, 跟簡單的blur
跟上一版相比, 速度少掉20張, memory 減少50mb.
因為 HDR的關係 很多 post process 的東西都怪怪的,
bloom 跟 star bloom 都重新改過, SSAO未改(效果不明顯了)
花大量的時間在整理code, 結果跑出一個怪bug, 又花了一天抓bug.
https://app.box.com/s/v3l1us2rhpu2hnzictx9
增加 HDR + FBX
增加 新的3層 cascaded shadow, 跟簡單的blur
跟上一版相比, 速度少掉20張, memory 減少50mb.
因為 HDR的關係 很多 post process 的東西都怪怪的,
bloom 跟 star bloom 都重新改過, SSAO未改(效果不明顯了)
花大量的時間在整理code, 結果跑出一個怪bug, 又花了一天抓bug.
FBX心得
使用 FBX 差不多了, 把原來使用的.ASE跟.X改成.FBX.
缺點大概就是沒增加什功能, 但還是值得的.
FBX SDK安裝完要1G, 只是一個讀檔案的sdk而已.
而且還有每年更新的 sdk? 不同年份的 .fbx版本
autodesk 看來很有雄心 發展 fbx,想成為標準.
-------------
fbx sdk 用的是很早以前 我在 bcb 6.0 那時 delphi 那種時期的framework
就是繼承 虛擬.......
這種架構 現在都已經落伍了. 改成component 就夠了.
另外就是 tree的node架構, 這算不錯, 第一次看到可以把tree的架構寫的這麼好的.
但是 因為是tree的架構, 所以所有的資訊 都塞在node裡面.
這也不是甚麼大問題
STL的部分 覺得沒甚麼必要 要自己弄一份, 這會讓整個SDK爆增,
整個 fbx sdk的 lib相當龐大, 讓程式complie 跟link ....都會變長.
debug 設定 也麻煩.
我根本不想在引擎裡直接跟 fbx sdk . lib綁在一起.
而是寫個轉檔程式, 轉成自己的格式 在用.
----------
接下來 最大的缺點, 也可以說是優點.
FBX檔案功能相當強大, 如果要深入了解 花的時間會很誇張.
而遊戲只是用到部分的功能, 即使如此 還是要了解其他的部分.
因為沒有FBX的檔案格式, 所以 所有的一切資料都必須靠 SDK的函數來抓取.
api這種東西 沒有完整的sample是沒用的.
也不會有人花時間去一個一個測api 功能.
而且誇張的是, SDK 的sample 跟網路上 找的sample code, 幾乎都不大一樣,
功能都做出來 可是大家寫的都不大一樣, 這就是 fbx sdk神奇的地方.
因為fbx只能靠api抓資料, 而又是tree的方式, 整個資料可用很多種api抓取.
因為api的函數相當多, 表示node A可以抓node B的資料,
node B也可以抓node A的資料.
這就是大家寫出來的 code都不一樣.
---------
只能說 這個時間點改fbx算是比較不錯, 因為網路上的資料變多了,
要是在3,4年前 改用FBX, 我看挫折感會很大.
-------
結論:
1.FBX的未來是 看好的, 畢竟autodesk全力的支援,
2.再來可以不管美工用哪種軟體, 這也是很大的優點. 程式也不用寫個別軟體的plugin
3.畢竟我才花一個用時間而已, 花的時間愈久 就會更熟悉fbx的功能,
fbx這個 寶藏 還有很多可以挖掘的.
缺點大概就是沒增加什功能, 但還是值得的.
FBX SDK安裝完要1G, 只是一個讀檔案的sdk而已.
而且還有每年更新的 sdk? 不同年份的 .fbx版本
autodesk 看來很有雄心 發展 fbx,想成為標準.
-------------
fbx sdk 用的是很早以前 我在 bcb 6.0 那時 delphi 那種時期的framework
就是繼承 虛擬.......
這種架構 現在都已經落伍了. 改成component 就夠了.
另外就是 tree的node架構, 這算不錯, 第一次看到可以把tree的架構寫的這麼好的.
但是 因為是tree的架構, 所以所有的資訊 都塞在node裡面.
這也不是甚麼大問題
STL的部分 覺得沒甚麼必要 要自己弄一份, 這會讓整個SDK爆增,
整個 fbx sdk的 lib相當龐大, 讓程式complie 跟link ....都會變長.
debug 設定 也麻煩.
我根本不想在引擎裡直接跟 fbx sdk . lib綁在一起.
而是寫個轉檔程式, 轉成自己的格式 在用.
----------
接下來 最大的缺點, 也可以說是優點.
FBX檔案功能相當強大, 如果要深入了解 花的時間會很誇張.
而遊戲只是用到部分的功能, 即使如此 還是要了解其他的部分.
因為沒有FBX的檔案格式, 所以 所有的一切資料都必須靠 SDK的函數來抓取.
api這種東西 沒有完整的sample是沒用的.
也不會有人花時間去一個一個測api 功能.
而且誇張的是, SDK 的sample 跟網路上 找的sample code, 幾乎都不大一樣,
功能都做出來 可是大家寫的都不大一樣, 這就是 fbx sdk神奇的地方.
因為fbx只能靠api抓資料, 而又是tree的方式, 整個資料可用很多種api抓取.
因為api的函數相當多, 表示node A可以抓node B的資料,
node B也可以抓node A的資料.
這就是大家寫出來的 code都不一樣.
---------
只能說 這個時間點改fbx算是比較不錯, 因為網路上的資料變多了,
要是在3,4年前 改用FBX, 我看挫折感會很大.
-------
結論:
1.FBX的未來是 看好的, 畢竟autodesk全力的支援,
2.再來可以不管美工用哪種軟體, 這也是很大的優點. 程式也不用寫個別軟體的plugin
3.畢竟我才花一個用時間而已, 花的時間愈久 就會更熟悉fbx的功能,
fbx這個 寶藏 還有很多可以挖掘的.
2014年遊戲程式員必須具備的能力
我都覺得 我快變成改 code專家.
就是把網路上的 source code 加入到自己的code.
2014年遊戲程式員必須具備的能力
1.debug 能力,多寫 code就對了. debug能力不行的 只會加深挫折感.
debug能力 = 時間 + 相關背景知識.
2.閱讀 修改 整合別人 source code的能力.
以現在3D的複雜程度而言, 真正有能力站在第一線研發 寫些新技術的,
大概就是3D卡廠商 遊戲廠商 或是學校教授 在這領域 的前幾名而已.
說得更明白點, 網路上 找不到相關的source code, 你有99.99%的機率 是做不出來的.
給你看paper也沒用, paper寫的太簡略 又寫的太複雜, 不如 code來的清楚.
==========
沒有甚麼好處, 意思是說, 投入1小時 只會有0.1的產出, 簡單說 這是沒有效率的學習方式.
效率是很重要的, 你的壽命有限, 效率不重要, 那要活幾百年 才夠用?
直接去寫套小軟體(小程式) 獲得的幫助 都比 ACM 好太多了.
ACM題目太雜, 一大堆題目 都沒有甚麼相關性,
1.再來 請問一下 那些 acm的code 可以重複使用嗎?
2.ACM能幫你建立甚麼相關的背景知識嗎? 有資料庫的知識? 有網路的背景知識?
有.....圖學的 背景知識?
就是把網路上的 source code 加入到自己的code.
2014年遊戲程式員必須具備的能力
1.debug 能力,多寫 code就對了. debug能力不行的 只會加深挫折感.
debug能力 = 時間 + 相關背景知識.
2.閱讀 修改 整合別人 source code的能力.
以現在3D的複雜程度而言, 真正有能力站在第一線研發 寫些新技術的,
大概就是3D卡廠商 遊戲廠商 或是學校教授 在這領域 的前幾名而已.
說得更明白點, 網路上 找不到相關的source code, 你有99.99%的機率 是做不出來的.
給你看paper也沒用, paper寫的太簡略 又寫的太複雜, 不如 code來的清楚.
==========
沒有甚麼好處, 意思是說, 投入1小時 只會有0.1的產出, 簡單說 這是沒有效率的學習方式.
效率是很重要的, 你的壽命有限, 效率不重要, 那要活幾百年 才夠用?
10年程式debug的技巧
http://pgamerart.blogspot.tw/2011/10/10debug.html
========直接去寫套小軟體(小程式) 獲得的幫助 都比 ACM 好太多了.
ACM題目太雜, 一大堆題目 都沒有甚麼相關性,
1.再來 請問一下 那些 acm的code 可以重複使用嗎?
2.ACM能幫你建立甚麼相關的背景知識嗎? 有資料庫的知識? 有網路的背景知識?
有.....圖學的 背景知識?
關於FBX 無法進入 debug mode的問題
綜合網路上的資訊
簡單創建一個可以執行的 vs2010 可以debug的程式
然後進入Properties 比較 成功的 跟 FBX 的sample 哪裡不一樣
修改fbx sdk sample 改成功的一樣就可
大約改的地方 有2個
1.C/C++ -->Gereral-->Debug Information Format -->Program Database For Edit And Continue (/ZI)
2. C/C++ -->Output Files --> Program Database File Name -->$(IntDir)vc$(PlatformToolsetVersion).pdb
"Generate Debug Info" to "Yes
Optimization" to "Disabled (/Od)"
然後 clear 重新 build
=====
fbx sdk sample 不管 build幾個例子 產生的.pdb大小都一樣 不到1mb
修改之後 .pdb 8mb 就表示正確了
簡單創建一個可以執行的 vs2010 可以debug的程式
然後進入Properties 比較 成功的 跟 FBX 的sample 哪裡不一樣
修改fbx sdk sample 改成功的一樣就可
大約改的地方 有2個
1.C/C++ -->Gereral-->Debug Information Format -->Program Database For Edit And Continue (/ZI)
2. C/C++ -->Output Files --> Program Database File Name -->$(IntDir)vc$(PlatformToolsetVersion).pdb
"Generate Debug Info" to "Yes
Optimization" to "Disabled (/Od)"
然後 clear 重新 build
=====
fbx sdk sample 不管 build幾個例子 產生的.pdb大小都一樣 不到1mb
修改之後 .pdb 8mb 就表示正確了
Citywar 3D Engine Techdemo 2.2 Release
Citywar 3D Engine Techdemo 2.2 Release
包含 BRDF 跟 Occlusion culling
https://app.box.com/s/lx09e86hxbuo9i9owkga(28mb)
使用方明如下: 按F4顯示對話盒.
包含 BRDF 跟 Occlusion culling
https://app.box.com/s/lx09e86hxbuo9i9owkga(28mb)
使用方明如下: 按F4顯示對話盒.
又整理了一些程式碼
shadowmap 的生成更快了, 速度又快了6,7張
空間切割讓 記憶體 更緊密了(大概少了800個new[] )
occlusino culling 的z值計算更正確 能cull更多的物體,(多15個左右物體), 可以速度沒增加
應該是 cpu的極限已經到了.
接下來的目標
接下來的目標:
該寫的特效都寫的差不多了, 反正網路上找不到code的,
那表示 也不用寫了, 因為根本不用幻想寫出來.
想寫植物動來動去的特效, 這似乎編輯器的部分比較多.
3D隨便一個特效 要寫到完整, 你認為要寫多久 ?
我看5~10年以上, 甚至20年.....
所以要知道 甚麼時候要停止.
3D程式目前就是走2,3步, 然後退一步. 寫些新的特效, 然後再把寫過的code整理.
1. 程式碼的整理 是相當重要的. 這也是一直持續在做的. 整理過的 code 威力會更強大.
2. 目前人物有點弱, 因為將來移植到dx11, 對.x file的支援將會沒有.
要用.FBX? 不是很清楚.
比較麻煩的事, 人物需要美工的配合, 才能有比較好的測試.
3.移植到dx11的事前準備?
用了大量D3DXMatrix, 這個要怎麼處理? 用SSE優化? 要怎麼處理?
雖然有XnaMath.h, 微軟的東西就是, 更新速度很快, 而且喜歡把以前的東西全部推翻
然後又要重寫.
4.移植到dx11的準備(搞不好會跳到dx12, 微軟應該會加速dx12的釋出)
g_pd3ddevice9->Clear(), 像這種dx9的移植到dx11都要改過.
為了移植, 又要把這種通通改成 Device::Clear(), 然後在Clear(){ dx11Device->Clear(); }
感覺就是又包一層, 有彈性 但是code的閱讀變困難了.
簡單的說 現在似乎到了要寫強大編輯器的時候, 只是 編輯器這種東西 可大可小.
不是很想寫, 就像不大想寫UI跟Particle, 這都是跟遊戲相關程度很大的.
跟遊戲的類型很有相關性. 簡單說 編輯器長的甚麼樣子 遊戲就會是甚麼樣子.
編輯器會有很多無聊的code, 亂七八糟的屬性設定.
編輯器的code就是那種 寫過一遍後 就不大想去整理 優化的.
========================
code的整理 我認為 這根本是藝術.
整理過後的code 一定要更短, 簡捷, 就是把多餘的脂肪 拿掉.
標準還是那樣: 更容易 閱讀 修改 擴充.
不是用更長的code 去取代更短的code, 結果功能都沒增加.
intel 的 software occlusion culling 我只寫了400行的 code就完成了.
(intel 那裏面的code 根本亂用繼承 亂用到亂七八糟的地步)
布料動畫的code,只寫了 720行就完成了.
該寫的特效都寫的差不多了, 反正網路上找不到code的,
那表示 也不用寫了, 因為根本不用幻想寫出來.
想寫植物動來動去的特效, 這似乎編輯器的部分比較多.
3D隨便一個特效 要寫到完整, 你認為要寫多久 ?
我看5~10年以上, 甚至20年.....
所以要知道 甚麼時候要停止.
3D程式目前就是走2,3步, 然後退一步. 寫些新的特效, 然後再把寫過的code整理.
1. 程式碼的整理 是相當重要的. 這也是一直持續在做的. 整理過的 code 威力會更強大.
2. 目前人物有點弱, 因為將來移植到dx11, 對.x file的支援將會沒有.
要用.FBX? 不是很清楚.
比較麻煩的事, 人物需要美工的配合, 才能有比較好的測試.
3.移植到dx11的事前準備?
用了大量D3DXMatrix, 這個要怎麼處理? 用SSE優化? 要怎麼處理?
雖然有XnaMath.h, 微軟的東西就是, 更新速度很快, 而且喜歡把以前的東西全部推翻
然後又要重寫.
4.移植到dx11的準備(搞不好會跳到dx12, 微軟應該會加速dx12的釋出)
g_pd3ddevice9->Clear(), 像這種dx9的移植到dx11都要改過.
為了移植, 又要把這種通通改成 Device::Clear(), 然後在Clear(){ dx11Device->Clear(); }
感覺就是又包一層, 有彈性 但是code的閱讀變困難了.
簡單的說 現在似乎到了要寫強大編輯器的時候, 只是 編輯器這種東西 可大可小.
不是很想寫, 就像不大想寫UI跟Particle, 這都是跟遊戲相關程度很大的.
跟遊戲的類型很有相關性. 簡單說 編輯器長的甚麼樣子 遊戲就會是甚麼樣子.
編輯器會有很多無聊的code, 亂七八糟的屬性設定.
編輯器的code就是那種 寫過一遍後 就不大想去整理 優化的.
========================
code的整理 我認為 這根本是藝術.
整理過後的code 一定要更短, 簡捷, 就是把多餘的脂肪 拿掉.
標準還是那樣: 更容易 閱讀 修改 擴充.
不是用更長的code 去取代更短的code, 結果功能都沒增加.
intel 的 software occlusion culling 我只寫了400行的 code就完成了.
(intel 那裏面的code 根本亂用繼承 亂用到亂七八糟的地步)
布料動畫的code,只寫了 720行就完成了.
訂閱：
文章 (Atom)