• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            月下的博客

              C++博客 :: 首頁 :: 聯系 :: 聚合  :: 管理
              34 Posts :: 0 Stories :: 59 Comments :: 0 Trackbacks

            常用鏈接

            留言簿(5)

            我參與的團隊

            搜索

            •  

            最新評論

            閱讀排行榜

            評論排行榜

             本來是想一周堅持寫一篇博客來記錄下自己學著寫編輯器的進展的,不過總想著寫好一個階段再寫一篇總的能有寫“內涵”的,于是乎拖著拖著一個月又過去了,最近想想自己又不是高手,blog還是該沒事就寫點,不管是腦殘的錯誤還是幼稚的想法都該寫下來。

              4月中,編輯器底層大改;可以說咱的編輯器本來的大部分結構學的是Ogitor,不過實際上程序最下面的結構當時大家沒學Ogitor(最下面的結構指的是Ogitor對于編輯器對象的具體屬性都采用了專門的屬性容器,OgitorProperty<T>,當時就以為ogitor只是為了解耦的),等我們把大部分基本的功能都實現了(地形,光照,實體,地形編輯,草體),回過頭來想加撤銷還原的時候發現不好辦了,(想一想,光以基本變量(bool等原子類型,Ogre::Vector3等基本數據類型)來保存具體編輯器的編輯屬性的話,根本沒辦法撤銷還原)于是我就從底層改起了。
              1.去除過多的單件:
                 這一點是我和兄弟相當贊同的,過多離散的單件往往在方便的同時破壞了整個程序的結構,改之和Ogitor已知,采用基類的ObjectList的方式來管理所有的編輯器對象實例,這樣所有的類都能得到統一管理,查找指定對象只需以它的類型來查找即可,需要單獨更新的對象則加入到UpdateList中,然后在迭代更新列表逐個更新即可,在不用我們自己在主體里來回添加Update語句了。(這主要是為了解耦)但我想了想有個地方還是沒學ogitor,它里面每個編輯器對象都有所有的parentEditor,這樣則形成一種樹形結構,這樣的設計更加緊湊,不過我們暫時覺得沒什么太大必要加,就放棄了(開始對OgitorProperty<T>也是這個想法)。
              2. 屬性注冊:
                屬性部分所有內容,我還沒全看明白。一是由于撤銷還原還沒弄,二是信號那塊我也還沒加(雖然樹形類的代碼是全扒過來了...)。不過就我目前看的部分而言,Ogitor這幫家伙寫得還真棒,利用模板trait來調用對應變量類型函數(第二次見,第一次在STL源碼剖析里,就那塊和開始的部分我能看懂...),光看到這個內容小菜我就興奮不已了。注冊的部分實際不難,好好看看PROPERTY_PTR和SETTER,GETTER這些個宏就能明白,無非是在對應編輯器的工廠map表里先添加定義,然后利用這些個宏為mProperties添加屬性變量,以及變量相關聯的設置其數值的函數。


            調試中犯的一些搞笑錯誤:
              1.前天在重寫BaseObject的GetNode函數(返回編輯器對象所在的場景節點,若是基類則為NULL,只有是NodeObject或其以上的才有值,這里沒學Ogitor的parentnode),發現程序里實際調用的時候就是不調NodeObject::GetNode而是調BaseObject::GetNode(),改了會都對C++產生了疑惑。。。還專門寫了測試來看看究竟調用哪個,結構也應該是NodeObject::GetNode,這問題足足花了我二十分鐘的時間,才發現自己在繼承方法聲明上忘記加const了。。。那一刻的感慨啊。。還是得經常把Effective C++拿出來摸一摸,翻一翻的。。
             
              改著改著,突然在想:當有高手源碼借鑒的時候,作為我這樣的小菜(指的是C++學了1年多,功底自認為不錯,但缺乏實際經驗的人),是改照單全理解了再寫還是邊理解邊按自己修改的較差方法去實現呢?我覺得是后者,因為后者總是需要去修改,而在修改的過程中才是存疑解惑的過程,這個過程中小菜才能明白為何高手如此“麻煩”地繞道偏行。還有,正如tonykee說的,編輯器的確是個無底洞~~要懂得適可而止的。
             
              分享點新聞:
              1.GoogleCode和SVN升級為2G了(具體貌似是1G更新空間,另外1G存儲,這一點沒太明白。。),嫌sourceForge麻煩的有福音咯~~
              2.Ogitor這幫家伙更新的越來越快了,當時還給他們提意見說應該做成簡單material腳本編寫的編輯器,剛說完,人家就回說:已經開始做了順帶一提,Ogitor有中文版了,感謝Coho的翻譯,雖然有些地方還沒翻譯好,不過我空了也會幫幫他們忙的
              3.星際7月27日預售,很期待它的銀河編輯器啊~~

              這兩天完成撤銷還原后再更新吧,希望我寫的亂七八糟的東西對大家有幫助。
               

            posted on 2010-05-06 08:38 月下圓舞曲 閱讀(2074) 評論(4)  編輯 收藏 引用 所屬分類: 開發

            Feedback

            # re: 四月編寫場景編輯器的總結 2010-05-06 08:54 陳梓瀚(vczh)
            其實我覺得M$應該添加一個__override擴展來幫助我們避免一下這些錯誤……  回復  更多評論
              

            # re: 四月編寫場景編輯器的總結 2010-05-06 09:55 空明流轉
            @陳梓瀚(vczh)
            別老是MS,MS的,擴展很麻煩的。你應該去鼓動C++的那幫老學究們考慮一下這個問題。(貌似我看到了Draft的?)  回復  更多評論
              

            # re: 四月編寫場景編輯器的總結 2010-05-06 12:25 小時候可靚了
            @空明流轉
            又看到你啦。。。評論很感人  回復  更多評論
              

            # re: 四月編寫場景編輯器的總結 2010-05-06 12:49 月下圓舞曲
            @空明流轉
            額。。的確擴展相當麻煩的,這種編程規范還是自己記著好。順便問句。。Draft是什么?  回復  更多評論
              

            精品免费久久久久国产一区| 亚洲精品乱码久久久久久蜜桃图片| 人人狠狠综合久久88成人| 色偷偷偷久久伊人大杳蕉| 国产69精品久久久久9999APGF| 中文字幕热久久久久久久| 久久精品国产精品亚洲毛片| 久久精品中文字幕久久| 久久免费香蕉视频| 久久久久亚洲av无码专区喷水| 国产高清美女一级a毛片久久w| 亚洲国产小视频精品久久久三级| 国内精品伊人久久久久777| 久久婷婷久久一区二区三区| 亚洲欧美另类日本久久国产真实乱对白| 久久久国产99久久国产一| 情人伊人久久综合亚洲| 亚洲人成无码www久久久 | 丰满少妇人妻久久久久久| 热久久这里只有精品| 精产国品久久一二三产区区别| 久久免费高清视频| 久久人人爽人人爽人人AV东京热 | 色综合久久久久综合99| 三上悠亚久久精品| 色综合久久天天综线观看| 欧美噜噜久久久XXX| 伊人久久大香线蕉综合5g| 久久黄视频| 国产精品免费久久久久影院| 7777久久亚洲中文字幕| 伊人久久大香线蕉av不卡| 日批日出水久久亚洲精品tv| 亚洲国产精品久久久久| 国产成人精品白浆久久69| 性欧美大战久久久久久久久| 色妞色综合久久夜夜| 综合久久久久久中文字幕亚洲国产国产综合一区首 | 久久99精品久久久久久野外| 久久国产成人精品麻豆| 国产精品久久网|