很多簡單的 都寫得差不多了, 剩下的就是很困難的.
更簡單說: 找不到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行就完成了.
Occlusion culling II
最後還是直接改 intel software occlusion cull 的code.
速度非常不錯.
經過BRDF的計算後, FPS只剩下65張, 經過cull後, 速度提升到 83張.
紅色圈起來的, 可以看到 被擋到後 render obj 只剩下 7個obj.
這個寫起來就很有成就感 花的時間少 效果又不錯
速度非常不錯.
經過BRDF的計算後, FPS只剩下65張, 經過cull後, 速度提升到 83張.
紅色圈起來的, 可以看到 被擋到後 render obj 只剩下 7個obj.
這個寫起來就很有成就感 花的時間少 效果又不錯
Occlusion culling
GPU把所有資料都輸出到 render target, 可惜的是 RT放在顯示卡的RAM.
cpu無取存取, 用GetRenderTargetData()速度很慢, 又要lock,導致效能低落.
沒想到 intel寫了一篇 software rasterizer occlusion culling
直接用cpu算,以為要賣cpu的, 沒想到很多遊戲 真的用cpu算Occlusion culling.
要把我10幾年前寫的software engine 拿出來用, 真是不可思議.
software rasterizer主要3個步驟
1.投影轉換到 screen space
2.切割
3.Fill, 計算z值
cpu無取存取, 用GetRenderTargetData()速度很慢, 又要lock,導致效能低落.
沒想到 intel寫了一篇 software rasterizer occlusion culling
直接用cpu算,以為要賣cpu的, 沒想到很多遊戲 真的用cpu算Occlusion culling.
要把我10幾年前寫的software engine 拿出來用, 真是不可思議.
software rasterizer主要3個步驟
1.投影轉換到 screen space
2.切割
3.Fill, 計算z值
Citywar 3D Engine Techdemo 2.0 Release
Citywar 3D Engine Techdemo 2.0 Release
包含 cloth 動畫 跟 GI, AO.
https://app.box.com/s/tnqhx6v5kvey1k1jczv9 (28mb)
使用方明如下: 按F4顯示對話盒.
包含 cloth 動畫 跟 GI, AO.
https://app.box.com/s/tnqhx6v5kvey1k1jczv9 (28mb)
使用方明如下: 按F4顯示對話盒.
用3ds max Render 出來的GI AO
應該沒有哪款遊戲可以做到即時GI.
GI困難的兩點: GI計算公式, 計算出來的資料要放在哪裡?
計算公式太難了, 弄不出來, 所以想到的方法 就是用 3ds max 幫忙計算.
本來想把資料放在 voxel, 但是資料太過龐大 而且不夠準確.
所以就放在lightmap.
困難點有兩個:
拆UV, 很難拆到完美, 要調整參數, 建模型 就需考慮進去.
D3DXUVAtlasCreate用這個下去算的. 又有接縫的問題.
3ds max的參數 影響很大, 很難設一組參數 然後對每個模型通用.
要針對每個模型去調整光線的亮度.
很多遊戲裡的一些場景亮度 都有過暗的情形發生, 那是因為光線的bounce 不夠多.
如果bounce設多一點 計算速度很慢.
GI困難的兩點: GI計算公式, 計算出來的資料要放在哪裡?
計算公式太難了, 弄不出來, 所以想到的方法 就是用 3ds max 幫忙計算.
本來想把資料放在 voxel, 但是資料太過龐大 而且不夠準確.
所以就放在lightmap.
困難點有兩個:
拆UV, 很難拆到完美, 要調整參數, 建模型 就需考慮進去.
D3DXUVAtlasCreate用這個下去算的. 又有接縫的問題.
3ds max的參數 影響很大, 很難設一組參數 然後對每個模型通用.
要針對每個模型去調整光線的亮度.
很多遊戲裡的一些場景亮度 都有過暗的情形發生, 那是因為光線的bounce 不夠多.
如果bounce設多一點 計算速度很慢.
技術從來都不是重點, 但技術從來都是問題
很多人喜歡把電影 遊戲 歸類成創意類型的....
喜歡說: 技術從來都不是重點, 但是沒技術 甚麼都做不出來啊.
沒技術 所以只能拍搞笑電影, 只能拍校園愛情電影.....
這些, 人家早在50年前的電影就拍過了.
====
app遊戲 我看來這也不是創意問題, 而是行銷問題.
很多認為是創意的問題, 其實都不是創意的問題.
喜歡說: 技術從來都不是重點, 但是沒技術 甚麼都做不出來啊.
沒技術 所以只能拍搞笑電影, 只能拍校園愛情電影.....
這些, 人家早在50年前的電影就拍過了.
====
app遊戲 我看來這也不是創意問題, 而是行銷問題.
很多認為是創意的問題, 其實都不是創意的問題.
3D圖形竟然是平行運算裡最簡單的一種
平行運算 最主要是 資料彼此的相關性.
3D圖形用到的資料竟然全部都是獨立 不相關的.
3D輸入的資料: 點頂, Normal , Tex....這都是頂點相關的, 不同的頂點 當然會有不同的資料.
而且彼此的頂點 不會互相影響, 頂點資料完全獨立.
所以經過 Model x View x Proj 轉換後, 頂點的資料還是一樣不會有任何關連.
那面的資料就只是3個 索引值. i0, i1, i2.
有相關的面重疊的問題, 因為是用z-buffer處理重疊的問題.
天 竟把相關性給解決了.
因為 先劃A面 跟先劃B面 用z-buffer比較 是完全沒有順序關係.
3D圖形竟然是平行運算裡最簡單的一種.
---
平行運算最主要的重點在於資料的相關性. 例如排序....
資料跟資料彼此有關係, 用 gpu算排序 就變得比較複雜.
3D圖形用到的資料竟然全部都是獨立 不相關的.
3D輸入的資料: 點頂, Normal , Tex....這都是頂點相關的, 不同的頂點 當然會有不同的資料.
而且彼此的頂點 不會互相影響, 頂點資料完全獨立.
所以經過 Model x View x Proj 轉換後, 頂點的資料還是一樣不會有任何關連.
那面的資料就只是3個 索引值. i0, i1, i2.
有相關的面重疊的問題, 因為是用z-buffer處理重疊的問題.
天 竟把相關性給解決了.
因為 先劃A面 跟先劃B面 用z-buffer比較 是完全沒有順序關係.
3D圖形竟然是平行運算裡最簡單的一種.
---
平行運算最主要的重點在於資料的相關性. 例如排序....
資料跟資料彼此有關係, 用 gpu算排序 就變得比較複雜.
cloth 布料動畫
經過漫長的努力. Cloth是用cpu算的.
平行運算在 3D愈來愈重要了, 不過目前蠻混亂的.
DirectCompute, amp c++ 只支援 dx11.
CUDA:只支援 nVidia
openCL:要試一下 對顯示卡的支援, 是否跟dx9合併使用.
資料要平行運算 還要特別處理過, 不像在cpu簡單.
應該說 平行運算都是全新的語言了
平行運算在 3D愈來愈重要了, 不過目前蠻混亂的.
DirectCompute, amp c++ 只支援 dx11.
CUDA:只支援 nVidia
openCL:要試一下 對顯示卡的支援, 是否跟dx9合併使用.
資料要平行運算 還要特別處理過, 不像在cpu簡單.
應該說 平行運算都是全新的語言了
citywar techdemo 1.8 發佈
citywar techdemo 1.8
按F4:可出現選擇天氣的參數選項
新增:
1.SSAO
2.Bloom
3.Star Bloom
4. FXAA(反鋸齒)
檔案下載:(30 mb)
https://app.box.com/s/mqsiflfxmbp28jq55leb
現在我的困惱dx9? dx10?
大部分簡單的3D特效都寫得差不多了, 接下來的就是比較困難(非常困難)
再來 dx9的功能對我也不夠使用了.
dx9說穿了 只要把render target 弄熟, 就差不多了.
目前的3D卡有個很大的致命傷.
在 shader code 可以輸入很多資料, 材質 頂點 外部的變數,
但是:輸出 一律只能輸出到 render taget. 理論上 是夠了, 但是十分缺少彈性.
dx10提供的功能:
1.Geometry Shader: 最常用來做particle, 但應該不只這些應用.
dx9就是 vertex shader-->然後pixel shader, 但是 你輸入的有三角形資訊,
就是你是劃三角形, 那怎麼 shader code 裡面都沒有三角形的資訊?
所以: Geometry Shader 就是被公開了.
2.Stream Output: 可以不需要經過 pixel shader, 就可直接把頂點運算過的資料輸出.
這是之前 談到的 輸出的彈性.
3.SV_VertexID: dx10增加蠻多這種東西. 這就是一開始 vertex buffer, index buffer
你自己輸入的資料, 現在也公開 在 shader code可以使用
4. texture array: 彈性.
5.dx9無法將 zbuffer texture在pixel shader 裡面存取, dx10可以了.
===============
即使這些 對我也不是那麼夠.
輸出 沒有辦法指定位置: 就是指定在 render target 的位置.
輸出沒有: 3D座標, 無法voxel.
=====
要移植到dx10, 要多花時間, 又只綁 win7, 雖然ubisoft 已經是dx10了.
也代表 要跟這類的軟體 直接競爭.
也想直接跳到dx11, 可能明年底, 這樣dx10就沒用了. 浪費移植.
=====
結論不打算移值dx10, 但是找一些不需要dx10的特效. 但是還是要看dx10.
因為dx10跟 dx11差距較小.
再來 dx9的功能對我也不夠使用了.
dx9說穿了 只要把render target 弄熟, 就差不多了.
目前的3D卡有個很大的致命傷.
在 shader code 可以輸入很多資料, 材質 頂點 外部的變數,
但是:輸出 一律只能輸出到 render taget. 理論上 是夠了, 但是十分缺少彈性.
dx10提供的功能:
1.Geometry Shader: 最常用來做particle, 但應該不只這些應用.
dx9就是 vertex shader-->然後pixel shader, 但是 你輸入的有三角形資訊,
就是你是劃三角形, 那怎麼 shader code 裡面都沒有三角形的資訊?
所以: Geometry Shader 就是被公開了.
2.Stream Output: 可以不需要經過 pixel shader, 就可直接把頂點運算過的資料輸出.
這是之前 談到的 輸出的彈性.
3.SV_VertexID: dx10增加蠻多這種東西. 這就是一開始 vertex buffer, index buffer
你自己輸入的資料, 現在也公開 在 shader code可以使用
4. texture array: 彈性.
5.dx9無法將 zbuffer texture在pixel shader 裡面存取, dx10可以了.
===============
即使這些 對我也不是那麼夠.
輸出 沒有辦法指定位置: 就是指定在 render target 的位置.
輸出沒有: 3D座標, 無法voxel.
=====
要移植到dx10, 要多花時間, 又只綁 win7, 雖然ubisoft 已經是dx10了.
也代表 要跟這類的軟體 直接競爭.
也想直接跳到dx11, 可能明年底, 這樣dx10就沒用了. 浪費移植.
=====
結論不打算移值dx10, 但是找一些不需要dx10的特效. 但是還是要看dx10.
因為dx10跟 dx11差距較小.
3D程式? 你何去何從?
聽說unreal4 有更便宜的授權, 便宜的 code....
還有便宜的 unity3d, 更是橫掃低階的應用.
那我為何要繼續寫的3D引擎 何去何從?
人生無聊 總要找點事做.
3D的門檻 可以看成是小學 中學 高中 大學 博士.......
重點是你處在哪一個位置?
或者是 unreal4 unity3D處在哪一個位置?
unreal4 unity3D 只是能幫忙降低3D的門檻, 能降低多少門檻? 大學降到高中,
那你要使用unity, 總要有高中程度吧.
一個不會3D程式的程式人員, 即使使用unreal 4, 做出來的東西 一定比我還差.
--->這應該不會有疑問吧.
=========================================
2年前 unity3D出來時 我認為他會像 flash一樣的流行.
但是過了2年後 也還好而已.
為什麼? 3D的門檻 遠超過你的想像, 所以我確定了 unity3d無法像 flash一樣的流行.
unity3D為何都是小遊戲在做? 沒有大遊戲?
那是他的目標訴求.
愈簡單的工具 愈容易使用的工具, 也同樣限制了他的使用範圍. 就是只能做簡單的遊戲.
遊戲不是單純一兩個元件組合起來就可.
是要由很多元件 非常多的功能組在一起.
unity每個元件都做得不錯, 但是一整合起來, 就會 速度超乎想像的慢.
而你將不會知道 bug在哪裡.
這也就是unity大多小遊戲的原因.
==========
我的目標就是 賣自己的3D引擎, 提升遊戲的競爭力.
目前為止 不可能有人跟我花一樣的程式資源,能做到跟我相等的程度了.
=========
3D圖學的方向 簡單說 就是沒有完美的終點.
涉及的領域 又多又廣.
1.相當高程度的程式能力
2.圖學知識.
3.數學 物理 知識.
根本不會有一個人有辦法掌握這麼多的知識.
所以你可以找到自己的立足點.
還有便宜的 unity3d, 更是橫掃低階的應用.
那我為何要繼續寫的3D引擎 何去何從?
人生無聊 總要找點事做.
3D的門檻 可以看成是小學 中學 高中 大學 博士.......
重點是你處在哪一個位置?
或者是 unreal4 unity3D處在哪一個位置?
unreal4 unity3D 只是能幫忙降低3D的門檻, 能降低多少門檻? 大學降到高中,
那你要使用unity, 總要有高中程度吧.
一個不會3D程式的程式人員, 即使使用unreal 4, 做出來的東西 一定比我還差.
--->這應該不會有疑問吧.
=========================================
2年前 unity3D出來時 我認為他會像 flash一樣的流行.
但是過了2年後 也還好而已.
為什麼? 3D的門檻 遠超過你的想像, 所以我確定了 unity3d無法像 flash一樣的流行.
unity3D為何都是小遊戲在做? 沒有大遊戲?
那是他的目標訴求.
愈簡單的工具 愈容易使用的工具, 也同樣限制了他的使用範圍. 就是只能做簡單的遊戲.
遊戲不是單純一兩個元件組合起來就可.
是要由很多元件 非常多的功能組在一起.
unity每個元件都做得不錯, 但是一整合起來, 就會 速度超乎想像的慢.
而你將不會知道 bug在哪裡.
這也就是unity大多小遊戲的原因.
==========
我的目標就是 賣自己的3D引擎, 提升遊戲的競爭力.
目前為止 不可能有人跟我花一樣的程式資源,能做到跟我相等的程度了.
=========
3D圖學的方向 簡單說 就是沒有完美的終點.
涉及的領域 又多又廣.
1.相當高程度的程式能力
2.圖學知識.
3.數學 物理 知識.
根本不會有一個人有辦法掌握這麼多的知識.
所以你可以找到自己的立足點.
這裡難道沒有人覺得 我程式寫得很快嗎?
這裡難道沒有人覺得 我程式寫得很快嗎?
1.因為我早在 dos時代就獨自完成 3D圖形引擎. 意思是我的基礎比你們深.
2.在windows剛出來時 就獨自完成一個簡單的大富翁遊戲, 並且想要拿自己完成的遊戲去賣了.
在10年前 我就開始賣3D程式碼了.
3. 因為我比你們更清楚 軟體開發的成本觀念, 要把力量時間用在對的方向.
所以我根本不會浪費時間 去學習一堆沒甚麼用的軟體技術, 像是 STL, public, vitrual....
我早就知道 這對軟體的開發 根本沒甚麼幫助.
4.簡單的例子 就像上面的 SSAO, 請問一下 你有評估過 要花多長的時間做 SSAO?
要做到甚麼樣的程度嗎?
在你們為SSAO爭吵時 我已經繼續寫下一個特效了.
1.因為我早在 dos時代就獨自完成 3D圖形引擎. 意思是我的基礎比你們深.
2.在windows剛出來時 就獨自完成一個簡單的大富翁遊戲, 並且想要拿自己完成的遊戲去賣了.
在10年前 我就開始賣3D程式碼了.
3. 因為我比你們更清楚 軟體開發的成本觀念, 要把力量時間用在對的方向.
所以我根本不會浪費時間 去學習一堆沒甚麼用的軟體技術, 像是 STL, public, vitrual....
我早就知道 這對軟體的開發 根本沒甚麼幫助.
4.簡單的例子 就像上面的 SSAO, 請問一下 你有評估過 要花多長的時間做 SSAO?
要做到甚麼樣的程度嗎?
在你們為SSAO爭吵時 我已經繼續寫下一個特效了.
軟體開發要有成本觀念
軟體開發要有成本觀念
1.我認為有30%的軟體開發 最終都沒有發行, 然後就結束了.
2.可能有高達9成以上的軟體開發 最後都會延誤.
為什麼? 軟體開發要有成本觀念.
軟體不是可以無限期的一直開發下去, 然後做出完美的軟體.
完美的軟體 根本不存在.
如果你是老闆看到錢一直投下去, 卻不知軟體何時會完成? 我看不頭痛才怪.
以為離你很遠? 那現在很多獨立遊戲的開發者, 那是不是要有成本觀念?
一款獨立小遊戲 可以寫一年? 寫完我看要破產了.
---------------
軟體開發者 可以考慮去接些案子, 對你開發軟體的成本觀念會有幫助的.
一般的案子就是 預算固定, 要寫的功能也是差不多固定.
然後你要評估 能不能接.
請問你怎麼評估?
1.先評估能不能做出來, 你對自己的能力不了解, 會做甚麼 不會做甚麼, 都不知道,
你要怎麼評估? 簽約下去 做不出來 是要賠錢的.
2.評估開發時間,案子是不能一直讓你無限期的做下去的. 時間不只是你的成本 也是發案者的成本. 上市日期....能不間內做出來.
3.上面兩個都有辦法後 最後才能評估利潤.
------------
甚麼是軟體開發的成本觀念?
這個功能 這個軟體要多久做出來, 做出來後 對使用者重不重要? 這就是成本效率觀念.
花大量的時間 做出使用者根本不需要的功能, 這就是浪費.
更簡單的問題: 你花大量的時間去學息一個新技術, 例如 STL, public, vitrual....
請問一下 這對你的軟體開發速度 有幫助嗎?
能更快的把軟體完成嗎?, 如果有幫助 那有多少幫助?
你自己評估一下成本, 就知道, 要不要花時間去學這些垃圾了.
結果只會出乎你的意料.
一點幫助都沒有.
---------
台灣的遊戲會完蛋, 就是完全沒有軟體成本觀念.
沒有哪種能力 無限的增加功能 硬要開發大型 online game, 最後導致延期 開發成本遽增.
最終出來的成品 又不滿意.
亂搞幾次 我看有哪個金主 敢繼續把錢投下去.
FXAA Anti-Aliasing
下載兩張圖 比較.
直接拿 nvidia的code來改, 以後寫程式這麼輕鬆就好.
就是edge blur跟亮度調整. 意思是會變獏糊跟變暗.
nvidia的控制台 就有這個選項. 只是在程式裡控制, 比較容易而已.
差別:nvidia的控制台 劃質比較好, 速度比較慢.
反正隨個人喜好.
======
現在的3D已經複雜到沒有paper寫不出來了.
即使有paper沒code, 還是有99%的機率寫不出來.
要是沒有nvidia或是 microsoft這些廠商,,,,,做這麼多研究, 寫出免費的code讓大家用.
3D遊戲的發展不可能這麼快.
所以就比誰的 shader code閱讀能力, 修改參數, 整合到遊戲的能力.
如果要比較 nvidia或是 microsoft 誰的 code寫的好?
很簡單, 就看你整合誰的code比較容易.
nvidia的sample code簡單 清楚, 很容易整合.
dx sdk的code, 感覺只是寫出來而已, 根本很難用. 很難看的懂到底是在寫甚麼.
如何判斷一個人的程式碼寫的好不好, 就是兩個標準:
容易修改 容易閱讀, 簡單的說 就是容易抄. 甚麼design pattern 也是屁.
簡單的說 就比誰的遊戲先做出來, 誰就搶商機.
遊戲開發超過2年, 失敗的機率只會急速爬升.
直接拿 nvidia的code來改, 以後寫程式這麼輕鬆就好.
就是edge blur跟亮度調整. 意思是會變獏糊跟變暗.
nvidia的控制台 就有這個選項. 只是在程式裡控制, 比較容易而已.
差別:nvidia的控制台 劃質比較好, 速度比較慢.
反正隨個人喜好.
======
現在的3D已經複雜到沒有paper寫不出來了.
即使有paper沒code, 還是有99%的機率寫不出來.
要是沒有nvidia或是 microsoft這些廠商,,,,,做這麼多研究, 寫出免費的code讓大家用.
3D遊戲的發展不可能這麼快.
所以就比誰的 shader code閱讀能力, 修改參數, 整合到遊戲的能力.
如果要比較 nvidia或是 microsoft 誰的 code寫的好?
很簡單, 就看你整合誰的code比較容易.
nvidia的sample code簡單 清楚, 很容易整合.
dx sdk的code, 感覺只是寫出來而已, 根本很難用. 很難看的懂到底是在寫甚麼.
如何判斷一個人的程式碼寫的好不好, 就是兩個標準:
容易修改 容易閱讀, 簡單的說 就是容易抄. 甚麼design pattern 也是屁.
簡單的說 就比誰的遊戲先做出來, 誰就搶商機.
遊戲開發超過2年, 失敗的機率只會急速爬升.
apple搞笑的 goto bug
最近很流行的: if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail; if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) goto fail;apple軟體實力本來就很差, 寫出這種搞笑的bug不用太在意.之前使用Xcode天啊, 這比10年前的 vc++還爛.看一個開發工具很不好用, 看 debug就曉得.在xocde裡面 在 debug模式 竟然 無法看到全域變數的數值?把函數寫在class裡面, 在函數內設中斷點, 竟然進不進去?
我不喜歡用goto, 反而常用 return;上面我會怎麼寫?
if( SSLHashSHA1.update()==ERROR ){ Release(); return FAIL: }if( SSLHashSHA1.final()==ERROR對齊 都好看多了. ========
笨蛋才會用一堆奇怪的goto.
Dijkstra寫的內容也是其一貫的犀利語氣，文中說：「幾年前我就觀察到，一個程序員的品質是其程序中goto語句的密度成反比的」
===========
這就是我反對用 public, virtual, 過多的template.
愈是弱腳的就喜歡用一些奇奇怪怪的語法, 還有甚麼Boost? 連學 都懶的學.
你知道 STL的 vector 在push_back() 會呼叫 ~class() 嗎?
有一個 class A; push_back(A); 會呼叫 ~A() 嗎?
如果你無法100%了解的東西就不用要用.
===============
http://coolshell.cn/articles/11112.html
===============
http://coolshell.cn/articles/11112.html
- if (!p) 和 if (p == NULL)
- if (p) 和 if (p != NULL)
- if (!bflag) 和 if (bflag == false)
- if ( CheckSomthing() ) 和 if ( CheckSomething() == true )
=========
現在我的程度 這種c++等級的bug, 對我已經沒有挑戰性了(當然只對我自己寫的code)
寫3D你才知道甚麼是困難.
3D哪種bug, 是你明知問題就在這裡, 很遺憾 你是無法解決.
Forward Rendering vs. Deferred Rendering
Forward Rendering:就是傳統的render.更簡單的說 是 world space rendering
Deferred Rendering: 這簡單的說就是 screen space rendering
更簡單的說: 類似一張一張很多2D的圖片 然後一直混在一起.
3D的redner原理 world space -> view space ->proj space ->clip space -> [screen space](Deferred Rendering 就是在這裡處理的)
這兩種各有優缺點:
world space rendering優點: 簡單明瞭. 一個一個obj的render.容易入門.
缺點:1.因為資料都是建立在world space, 所以資料量很龐大.
已知的 lightmaping就是 world space render, 需要大量的記憶體來儲存lightmap.
2.如果處理的特效愈多 複雜度就愈高.
優點是:劃質質很穩定, 除了有鋸齒外的問題, 其他幾乎都不是什麼問題.
gpu運算要求較低, memory要求較高.
代表作品 : rage
screen space rendering:
優點:1.所需的資料很少, 最多就是幾個 screen space資料,
memory需求低, 但是很吃gpu的運算能力.
2.能夠簡化 render流程. 能把很複雜的劃面處理 簡化成幾張照片的處理方式.-->這應該是受歡迎的主要原因.
缺點: 入門檻高, 花大量的時間在做 image編碼的過程.
screen space 的數值不容易控制, 要花大量的時間處理閃爍的問題.
代表作品 :crysis
簡單一句話:
screen space rendering 能把複雜的東西變得很簡單, 但是簡單的東西卻變得很複雜.
world space rendering: 簡單的就是簡單 複雜的就是複雜
Deferred Rendering: 這簡單的說就是 screen space rendering
更簡單的說: 類似一張一張很多2D的圖片 然後一直混在一起.
3D的redner原理 world space -> view space ->proj space ->clip space -> [screen space](Deferred Rendering 就是在這裡處理的)
這兩種各有優缺點:
world space rendering優點: 簡單明瞭. 一個一個obj的render.容易入門.
缺點:1.因為資料都是建立在world space, 所以資料量很龐大.
已知的 lightmaping就是 world space render, 需要大量的記憶體來儲存lightmap.
2.如果處理的特效愈多 複雜度就愈高.
優點是:劃質質很穩定, 除了有鋸齒外的問題, 其他幾乎都不是什麼問題.
gpu運算要求較低, memory要求較高.
代表作品 : rage
screen space rendering:
優點:1.所需的資料很少, 最多就是幾個 screen space資料,
memory需求低, 但是很吃gpu的運算能力.
2.能夠簡化 render流程. 能把很複雜的劃面處理 簡化成幾張照片的處理方式.-->這應該是受歡迎的主要原因.
缺點: 入門檻高, 花大量的時間在做 image編碼的過程.
screen space 的數值不容易控制, 要花大量的時間處理閃爍的問題.
代表作品 :crysis
簡單一句話:
screen space rendering 能把複雜的東西變得很簡單, 但是簡單的東西卻變得很複雜.
world space rendering: 簡單的就是簡單 複雜的就是複雜
citywar 3D Engine v1.5 發佈
更新內容
1. 天氣參數減少一個, 但是結果更正確. 新增被太陽照到的顏色參數.(按F4可顯示對話盒)
2.地形混色的normal map 更多樣化.
3.新增光源, soft particle , anim height fog
citywar_techdemo15.zip(30mb)
https://app.box.com/s/a7iuwaqbx7fsvlkoxa4d
說明一下:這個2002年的影子怎麼做出來的
2002年時, 在當時的環境做影子 只有一種方法 : Stencil Shadow Volume.
還有一種就是簡單的把物體只能投影到一個全平面的影子而已.
當時想破了頭,實在是辛苦.
其實原理很簡單, 只是coding能力要很夠.
做法就是上面那張圖.原理就是
單純的平面投影 然後做切割.
把 a投影到所有可能的三角形平面上. a', 當然一定會超過,
做切割就可以了.
就是最後就是產生一大串零碎的三角形. 這些三角形就是影子了.
然後把這些零碎三角形 通通劃出來就可.
當然這些零碎三角形會重疊到 就是重劃, 用各stencil buffer紀錄就可.
然後混色就完成了.
當然樹就先用個事先劃好的樹影, 投影時不只切割三角形 也切割貼圖座標.
3D是屬於技術壟斷的產業
從PS3上的3D遊戲大幅減少就知道 這個發展趨勢.
3D的整個發展, 就是A->B->C->D. 沒有哪個人那麼天才, 可以不經過A,B就會直接跳到C,D的.
更簡單的說 能做出好的3D遊戲的 就是市面上有作品的哪幾家公司.
這些公司早就在3D技術花了10年以上的努力了.
連日本遊戲公司 都跟不上3D技術的發展而淘汰.
GDC一堆發表的文章, 最後一頁 一定就是徵人.
現在3D技術也不是一個人有能力就能做出不錯的產品了.
連id software的 John D. Carmack,也都跟不上3D技術的發展了.
連發表的論文 書籍,甚至都不是一特人能獨自發表新技術, 而是2,3個聯合發表一篇論文.
甚麼都不用講 光是3D卡的硬體廠商, 做多久了, driver 都還一堆問題.
就知道3D技術的挑戰性.
如果你知道3D的最終極目標是甚麼, 就知道3D有多困難.
3D的最終極目標 就是模擬真實世界的畫面, 就知道根本就是不可能的.
有太多限制了, 不只是軟體的演算法而已 硬體gpu運算速度, 記憶體大小, 還有float的精確度.
3D動畫的畫面大概領先 real time有5年以上. 更別說那些3D動畫 看起來還假假的.
----------
3D技術的發展 有一個新興的勢力, 就是歐洲國家, 都可以做出不錯的 3D遊戲.
其實也不用大驚小怪, 如果你知道 Gauss(高斯是哪一國人),
菲涅耳透鏡（英文：Fresnel lens），是由法國物理學家奧古斯丁.
沒錯 你書本上讀到的那些光學 數學公式 竟然活生生的出現在遊戲裡, 就知道為何歐洲在3D興起的原因了.
3D的整個發展, 就是A->B->C->D. 沒有哪個人那麼天才, 可以不經過A,B就會直接跳到C,D的.
更簡單的說 能做出好的3D遊戲的 就是市面上有作品的哪幾家公司.
這些公司早就在3D技術花了10年以上的努力了.
連日本遊戲公司 都跟不上3D技術的發展而淘汰.
GDC一堆發表的文章, 最後一頁 一定就是徵人.
現在3D技術也不是一個人有能力就能做出不錯的產品了.
連id software的 John D. Carmack,也都跟不上3D技術的發展了.
連發表的論文 書籍,甚至都不是一特人能獨自發表新技術, 而是2,3個聯合發表一篇論文.
甚麼都不用講 光是3D卡的硬體廠商, 做多久了, driver 都還一堆問題.
就知道3D技術的挑戰性.
如果你知道3D的最終極目標是甚麼, 就知道3D有多困難.
3D的最終極目標 就是模擬真實世界的畫面, 就知道根本就是不可能的.
有太多限制了, 不只是軟體的演算法而已 硬體gpu運算速度, 記憶體大小, 還有float的精確度.
3D動畫的畫面大概領先 real time有5年以上. 更別說那些3D動畫 看起來還假假的.
----------
3D技術的發展 有一個新興的勢力, 就是歐洲國家, 都可以做出不錯的 3D遊戲.
其實也不用大驚小怪, 如果你知道 Gauss(高斯是哪一國人),
菲涅耳透鏡（英文：Fresnel lens），是由法國物理學家奧古斯丁.
沒錯 你書本上讀到的那些光學 數學公式 竟然活生生的出現在遊戲裡, 就知道為何歐洲在3D興起的原因了.
citywar Engine TechDemo v1.2 發佈
citywar Engine TechDemo v1.2
包含功能:
1.cascade shadow + rain 特效 + 50個人物影子 + culling 速度加快
2.一個編輯 rain特效的介面
3.一個 FPS第一人稱的遊戲方式.
citywar techdemo v1.2 下載(29mb)
https://app.box.com/s/qzqrqmezroja55xbvu94
culling 做了2個加速:
1.1本來是對每個obj做culling, 這數量太大, 全部 464個.
camera cull + cascade shadow cull *2(層) +water reflect + rain reflect
總共 5*464 次.
後改用 用每一個group做culling 476減少到 171. cpu 少掉 5*(464-171)=1465次運算.
雖然不夠精確 但是速度提升15張.
1.2. shadow culling 本來就有做.但是有些obj總是在影子裡 根本不用算.
nObjAlways _InShadow, 這有84個obj. 速度也是提升15張.
包含功能:
1.cascade shadow + rain 特效 + 50個人物影子 + culling 速度加快
2.一個編輯 rain特效的介面
3.一個 FPS第一人稱的遊戲方式.
citywar techdemo v1.2 下載(29mb)
https://app.box.com/s/qzqrqmezroja55xbvu94
culling 做了2個加速:
1.1本來是對每個obj做culling, 這數量太大, 全部 464個.
camera cull + cascade shadow cull *2(層) +water reflect + rain reflect
總共 5*464 次.
後改用 用每一個group做culling 476減少到 171. cpu 少掉 5*(464-171)=1465次運算.
雖然不夠精確 但是速度提升15張.
1.2. shadow culling 本來就有做.但是有些obj總是在影子裡 根本不用算.
nObjAlways _InShadow, 這有84個obj. 速度也是提升15張.
citywarEngine 1.2 Rain Effect
下禮拜會丟出一個執行檔:demo cascade shadow + rain effect
雨的特效就先這樣了. 能參考的資料太少 又太難寫.
每加一個特效 都要跟原來的整合,整理程式的時間就愈長.
接下來會寫 lighting + cull 這資料就比較多了
雨的特效就先這樣了. 能參考的資料太少 又太難寫.
每加一個特效 都要跟原來的整合,整理程式的時間就愈長.
接下來會寫 lighting + cull 這資料就比較多了
如何用簡單的方法解決複雜的問題?
如何用簡單的方法解決複雜的問題?
這不只在程式方面, 很多方面都可以適用.
原則1: 任何的問題都是複雜的問題. (不要認為有簡單的問題)
原則2:任何複雜的問題 都不可能被完美的解決.(該知道到甚麼地步就該適可而已)
原則3:用複雜的方法只會引起更多的問題.
原則4:要花很長時間想出一個簡單的方法解決複雜的問題.(不要太懶了)
很多時候想到的方法 都是複雜的方法, 因為很快就想出來, 結果花大量的時間在 debug,
最後因為方法太過複雜,導致放棄 .
如何用簡單的方法解決複雜的問題?
1.把問題的重點抓出來, 這需要訓練 長時間訓練的結果 才能看出問題的重點.
2.解決重點問題. 代表就解決 80%以上的問題. 其他的細節就可以簡化了.
3.要解決一個複雜的核心問題, 要從各種角度 就是360度 逼近問題.
不要太死腦袋, 一定要怎麼做才可.
廣泛的閱讀 收集資料, 然後逼近核心.
這不只在程式方面, 很多方面都可以適用.
原則1: 任何的問題都是複雜的問題. (不要認為有簡單的問題)
原則2:任何複雜的問題 都不可能被完美的解決.(該知道到甚麼地步就該適可而已)
原則3:用複雜的方法只會引起更多的問題.
原則4:要花很長時間想出一個簡單的方法解決複雜的問題.(不要太懶了)
很多時候想到的方法 都是複雜的方法, 因為很快就想出來, 結果花大量的時間在 debug,
最後因為方法太過複雜,導致放棄 .
如何用簡單的方法解決複雜的問題?
1.把問題的重點抓出來, 這需要訓練 長時間訓練的結果 才能看出問題的重點.
2.解決重點問題. 代表就解決 80%以上的問題. 其他的細節就可以簡化了.
3.要解決一個複雜的核心問題, 要從各種角度 就是360度 逼近問題.
不要太死腦袋, 一定要怎麼做才可.
廣泛的閱讀 收集資料, 然後逼近核心.
訂閱：
文章 (Atom)