Citywar 3D Engine: 9月 2014

2014年遊戲程式員必須具備的能力

我都覺得我快變成改 code專家.

就是把網路上的 source code 加入到自己的code.

2014年遊戲程式員必須具備的能力

1.debug 能力,多寫 code就對了. debug能力不行的只會加深挫折感.

debug能力 = 時間 + 相關背景知識.

2.閱讀修改整合別人 source code的能力.

以現在3D的複雜程度而言, 真正有能力站在第一線研發寫些新技術的,

大概就是3D卡廠商遊戲廠商或是學校教授在這領域的前幾名而已.

說得更明白點, 網路上找不到相關的source code, 你有99.99%的機率是做不出來的.

給你看paper也沒用, paper寫的太簡略又寫的太複雜, 不如 code來的清楚.

==========
ptt: 所以練acm都底有啥好處？

沒有甚麼好處, 意思是說, 投入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 就表示正確了

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顯示對話盒.

又整理了一些程式碼

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行就完成了.

BRDF

BRDF 這主要是修改自 Unreal 4的code, 應該說幾乎是直接拿來用.
不過目前只有參數 roughness, 針對 roughness 有不同的光線反映.
還有 image based lighting,主要解決間接光源的問題.

normal map的效果更好了, 而且有一種特殊的金屬光澤.
這花的時間就蠻長的,畢竟資料太少了.

Occlusion culling II

最後還是直接改 intel software occlusion cull 的code.
速度非常不錯.
經過BRDF的計算後, FPS只剩下65張, 經過cull後, 速度提升到 83張.

紅色圈起來的, 可以看到被擋到後 render obj 只剩下 7個obj.
這個寫起來就很有成就感花的時間少效果又不錯