Re: [程式] 遊戲程式：平行邏輯的時域切割

看板GameDesign作者 (揪嚕嚕)時間7年前 (2017/03/26 00:34), 編輯推噓10(10推 0噓 17→)
留言27則, 8人參與, 最新討論串1/1
※ 引述《cjcat2266 (CJ Cat)》之銘言： : timeslicing算是我進入業界第一個學到的技巧之一吧 : 非常實用且幾乎每天都會摸到 : 簡單來說就是有必須反覆執行的輕量平行邏輯 : 不用每個frame全部執行，可以分多個frame執行，分擔負擔 : 像是100個NPC不用每個frame都全部執行，每frame處理20個可省下80%決策運算時間 : 反映NPC決策的動畫層，因為與決策層中間透過介面溝通 : 這種幾個frame決策延遲並不會被玩家注意到 : (除非你在做無法容忍延遲的格鬥遊戲，那你是要100個NPC幹嘛啦XD) : 時域切割 同步/非同步 的 資料讀取輸入/儲存輸出，又有四種排列組合 : 本文有精美動畫供參考:) : 那就廢話不多說了(好像已經講了一堆) : 連結在此 http://wp.me/p4mzke-14V : 動畫生成原始碼在此 https://github.com/TheAllenChou/timeslicing : 這是遊戲程式系列文的一部分 http://allenchou.net/game-programming-series/ : 請多指教 :) 不要每個frame都執行，除了cjcat大分享的timeslicing之外 還有使用timer，設定interval時間每隔一段時間處理的方法 這邊想分享一下曾經遇到"失敗"的經驗 首先我們先回到沒有改的狀況 版本1： 每個frame要做的事情都寫在Update裡 版本2： 使用timer 在begin play的時候設定timer，interval可能是5秒，每次作原來Update的事 結果悲劇發生了，如果這個entity被種了10個在同一個場景可能會發生什麼事？ 10個同時睡覺，同時起床，於是每5秒遊戲就會頓一下 (前提是這Update很花時間，不過如果這個Update很快，你根本不會把版本1改掉) 從profiler分析，版本2的average fps會比1好很多， 可是max fps還是跟版本1一樣，遊戲體驗卻比1還要遭。 所以這篇文章除了要說明， 使用timer要小心不要同時觸發之外。 profiling時也要擁有全面以及正確的觀念，average/max 都要同時注意 在尋找改善的標物建議多花一點時間，確定找到的是目前較重瓶頸 時間要花在刀口上~~ 以上就是曾遇到的失敗經驗~~沒踩過雷的人可以趁機知道一下~ -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 122.116.41.55 ※ 文章網址: https://www.ptt.cc/bbs/GameDesign/M.1490459698.A.90E.html
推
03/26 00:50, , 1F
你這是把同樣把全部要做的事情都塞進update裡面吧
03/26 00:50, 1F
→
03/26 00:51, , 2F
這樣有沒有延遲5秒執行沒有差別阿
03/26 00:51, 2F
→
03/26 01:16, , 3F
的確只是單純的把呼叫次數降低而已
03/26 01:16, 3F
推
03/26 09:25, , 4F
在開頭的時候把timer的第一次週期隨機分散
03/26 09:25, 4F
推
03/26 10:03, , 5F
我自己是不太喜歡用timer，因為有不確定因素
03/26 10:03, 5F
→
03/26 10:04, , 6F
因為用frame數來決定是否update的話，控制比較精確
03/26 10:04, 6F
→
03/26 10:06, , 7F
一開始我會推薦最簡單的 (object index + frame#) % n
03/26 10:06, 7F
→
03/26 10:07, , 8F
來決定是否update，不夠的話再看有沒有其他地方可以切
03/26 10:07, 8F
→
03/26 10:08, , 9F
也可以試試看lazy update，有需要的時候才觸發update
03/26 10:08, 9F
→
03/26 10:09, , 10F
下個frame再給結果，太多query的話就排隊timeslice
03/26 10:09, 10F
→
03/26 10:10, , 11F
Uncharted 4的就是用這種request-based lazy update
03/26 10:10, 11F
→
03/26 10:11, , 12F
來算出NPC的最佳移動目的地，NPC有reqeust才開始update
03/26 10:11, 12F
→
03/26 10:11, , 13F
要算的東西太多，就timeslice，過幾個frame再給結果
03/26 10:11, 13F
→
03/26 10:12, , 14F
反正是決定層，慢個0.1秒才反映在動畫層也看不出來
03/26 10:12, 14F
推
03/26 12:13, , 15F
我的方法跟cj是一樣的
03/26 12:13, 15F
→
03/26 12:14, , 16F
用更新率來切step
03/26 12:14, 16F
→
03/26 12:15, , 17F
或者說就是最簡單的一招吧 XD
03/26 12:15, 17F
推
03/26 12:17, , 18F
這樣做是不用另開執行緒
03/26 12:17, 18F
→
03/26 12:17, , 19F
效能不足再開就好
03/26 12:17, 19F
推
03/26 15:07, , 20F
如果平台支援fiber的話，可以在低overhead的狀況達到
03/26 15:07, 20F
→
03/26 15:08, , 21F
多執行緒的效果，一開始開跟CPU core數量一樣的執行緒
03/26 15:08, 21F
→
03/26 15:09, , 22F
然後用core affinity綁定CPU core，再用job system分配
03/26 15:09, 22F
→
03/26 15:09, , 23F
fiber給執行緒處理
03/26 15:09, 23F
推
03/26 15:12, , 24F
範例可以看 http://bit.ly/1eX5mb1
03/26 15:12, 24F
推
03/27 10:55, , 25F
push~
03/27 10:55, 25F
推
03/27 14:40, , 26F
讚
03/27 14:40, 26F
推
03/28 23:25, , 27F
時域切割正夯
03/28 23:25, 27F
‣ 更多 windkey 的文章
文章代碼(AID): #1OrfmoaE (GameDesign)