※ 引述《NDark (溺於黑暗)》之銘言： : 實務面是， : 在遊戲層的各個元件（不管是繪圖，移動，動畫）都要能取得目前FPS的資訊， : 或是當此元件的機制需要這個資訊的時候，必須要從最外層一路傳進去。 最近在做一些基底類別,有一個地方還沒決定. 可以拿出來跟各位討論一下.不知道有沒有我想不周到的地方. 問題如下 遊戲中的物件(Object,或Entity元件)散落在遊戲中的各個角落. 不管用什麼方式把它們串起來,都會有執行的Process. 而這些流程可能就會用到FPS的資訊. 或是這個流程想要知道 "距離上次執行.經過了多少時間?" 目前我這裡考量的有幾種作法,先列出來給各位參考. A. FPS一路傳入式 每個畫格.每個Process都一定要跑到. 然後強迫傳入此畫格經過多少時間(Elapsed Time). 因此實作上就是所有物件基底的類別會有這個成員函式, 所有繼承的類別物件都強迫實作它.如下: virtual GameObject::Main( double _ElapsedTimeSec ) ; 優點: 一條鞭式,撰寫簡單. 缺點: 所有物件都被無可避免的強迫串上一個管理器, 所有物件也被強迫一定要用這樣的方式撰寫.比較沒有彈性. 對於那些物件之中的小物件,或是不希望每個畫格都執行到的流程. 就必須要特別考量兩次執行到底累積了多久時間. B. 獨立的計時器 考量到每個物件不一定每個畫格都要跑到,某些物件譬如說log記錄器,每1秒才跑一次. 每個Process有自己的計時器.跑起來的時候自動會計算與上次差了多久. 實作方式就是有一個Timer物件,會去參照系統時間. AnyObj.MyProcess() { ElapsedTimeSec = TimerObj.getElapsedSec() ; TimerObj.Restart() ; ... 優點: 每個物件只要自己去取得過了多久就好.不用串上統一的管理器.作法彈性. 也不用每個畫格都執行. 缺點: 因為是取得系統時間來計算跟上次差了多久. 所以遊戲沒辦法控制這個時間差. C. 註冊FPS通知器 A與B的混合型.每個會用到FPS的物件. 都去跟一個唯一(singleton)的FPS管理器來註冊自己. 因此這個管理器就就像是有一堆鬧鐘. 每個畫格就對這些鬧鐘累加一次. 每個物件不定時間執行的時候.就去取得自己的鬧鐘.取得經過時間.然後重置鬧鐘. 實作如下 AnyObj::AnyObj() { TimerHandleID = singletonFPSManager().RegisterTimer( this ) ; ... AnyObj.Run() { ElapsedTime = singletonFPSManager().getElapsedTime( TimerHandleID ) ; singletonFPSManager().resetTimer( TimerHandleID ) ; ... 優點: 物件不用串上管理器.作法彈性. 缺點: 物件必須記得要去註冊自己.取得handle id.且保證這個id不會重複. D. 獨立的裝飾型計時器 B的變化型.在取得系統時間前.再包裝一層放大器. 這樣就可以讓遊戲管理器自由調整給每個物件的時間經過 裝飾型計時器實作如下 class DecorateTimer : public SysTimer { double AmplifyValue = ... 優點: 物件改跟裝飾型計時器要資料. 不用串上管理器.作法彈性. 還可以依照不同的物件類型取得放大或原始的經過時間 缺點: 使用時要記得現在是用裝飾過後的Timer. 使用上必須明瞭自己在取得的時間是什麼意義. 以及.要避免有程式設計員不知道有這個裝飾計時器. 還傻傻的跑去拿系統時間.以至於物件之間不同步的情況. -- "May the Balance be with U"(願平衡與你同在) 視窗介面遊戲設計教學，討論，分享。歡迎來信。 視窗程式設計（Windows CLR Form）遊戲架構設計（Game Application Framework） 遊戲工具設計（Game App. Tool Design ） 電腦圖學架構及研究（Computer Graphics） --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 118.167.132.126 ※ 編輯: NDark 來自: 118.167.132.126 (11/06 18:39)