• <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>
            隨筆 - 5, 文章 - 0, 評(píng)論 - 24, 引用 - 0
            數(shù)據(jù)加載中……

            Ogre在游戲開(kāi)發(fā)中逐幀更新

            最新的Ogre穩(wěn)定版本是1.6.0RC1[shoggoth],在1.6.0版本中OgreFrameListener.h中的類(lèi)FrameListener多出了一個(gè)叫virtual bool frameRenderingQueued( const FrameEvent& evt ) { return true; }的函數(shù)。這個(gè)函數(shù)和virtual bool frameStarted( const FrameEvent& evt ) { return true; }有明顯的區(qū)別。
            在源代碼中對(duì)frameStarted的注釋是:
                    /** Called when a frame is about to begin rendering.
              @remarks
               This event happens before any render targets have begun updating.
                        @return
                            True to go ahead, false to abort rendering and drop
                            out of the rendering loop.
                    */
            大體翻譯是:
            當(dāng)一幀將要開(kāi)始渲染的時(shí)候被調(diào)用。
            這個(gè)事件發(fā)生在所有渲染目標(biāo)已經(jīng)開(kāi)始更新之前。
            而在源代碼中對(duì)frameRenderingQueued的注釋是:
              /** Called after all render targets have had their rendering commands
               issued, but before render windows have been asked to flip their
               buffers over.
              @remarks
               The usefulness of this event comes from the fact that rendering
               commands are queued for the GPU to process. These can take a little
               while to finish, and so while that is happening the CPU can be doing
               useful things. Once the request to 'flip buffers' happens, the thread
               requesting it will block until the GPU is ready, which can waste CPU
               cycles. Therefore, it is often a good idea to use this callback to
               perform per-frame processing. Of course because the frame's rendering
               commands have already been issued, any changes you make will only
               take effect from the next frame, but in most cases that's not noticeable.
              @return
               True to continue rendering, false to drop out of the rendering loop.
              */
            翻譯為:
            在所有渲染目標(biāo)已經(jīng)傳出他們的渲染命令之后,并且在渲染窗口被要求去釋放他們的幀之前。
            這個(gè)事件的用途其實(shí)是為了把GPU處理的渲染命令推入隊(duì)列,這些只花費(fèi)一點(diǎn)功夫去完成,
            而就這一段時(shí)間cpu可以被用來(lái)處理一些有用的事情。一旦釋放幀這個(gè)時(shí)間發(fā)生,這條線(xiàn)程請(qǐng)求將要被
            堵塞直到GPU準(zhǔn)備好了,這可能浪費(fèi)了cpu的渲染時(shí)間,然而,作為回調(diào)函數(shù)去逐幀處理也是一個(gè)好注意。
            當(dāng)然因?yàn)閹匿秩久钜呀?jīng)被放出,任何你做的改變只對(duì)下一幀有效,但是大多數(shù)情況下這不是很明顯的。

            加入了這個(gè)函數(shù)也說(shuō)明了Ogre1.6.0對(duì)gpu重視了。
            在ogre自帶的例子中,幾乎都是用examplelistener來(lái)處理游戲循環(huán)。這明顯不符合比較大點(diǎn)的游戲開(kāi)發(fā)。而如果
            你想要在大型游戲中應(yīng)用這個(gè)游戲循環(huán)。我感覺(jué)首先應(yīng)該有一個(gè)單件的幀監(jiān)聽(tīng)系統(tǒng)通過(guò)游戲主應(yīng)用程序來(lái)初始化。然后就是用設(shè)計(jì)模式中的Bridge的將聲明和執(zhí)行分開(kāi)的功能來(lái)處理這個(gè)方法。
            偽代碼:

            //一個(gè)部件的類(lèi)
            class BrilyfWidgets
            {
                
            bool frameRenderingQueued( const FrameEvent& evt ); 
                
            }
            ;


            //類(lèi)的前向聲明
            class BrilyfApplication;

            class BrilyfListenSystem : public Singleton<BrilyfListenSystem>public FrameListener
            {
                
            bool frameRenderingQueued( const FrameEvent& evt ) 
                
            {
                    
            //一些系統(tǒng)缺省的設(shè)置
                    
                    
            //關(guān)鍵部分
                    BrilyfApplication::getSingletonPtr()->frameRenderQueued( const FrameEvent& evt );
                    BrilyfApplication::getSingletonPtr()
            ->frameEnded( const FrameEvent& evt );
                }

                
            bool frameEnded( const FrameEvent& evt );    
            }
            ;

            //所有的其他一些部件的初始化都要通過(guò)BrilyfApplication,它就是游戲的主管道,控制著所有部件的生命周期,提供了
            //frameRenderingQueued和frameEnded的接口供其他的部件來(lái)填充。
            class BrilyfApplication : public Singleton<BrilyfApplication>
            {
                
            //一些對(duì)于單件初始化的處理
                
                
                
            //對(duì)應(yīng)的事件
                bool frameRenderingQueued( const FrameEvent& evt ) 
                

                    
            for ( int i = 0; i < 16; i++ )
                        BrilyfWidgets.frameRenderingQueued(  );
                }

                
            bool frameEnded( const FrameEvent& evt );

                BrilyfWidgets mWidgets[
            16];
            }
            ;

            posted on 2008-09-24 22:11 brilyf 閱讀(2204) 評(píng)論(2)  編輯 收藏 引用

            評(píng)論

            # re: Ogre在游戲開(kāi)發(fā)中逐幀更新  回復(fù)  更多評(píng)論   

            這是開(kāi)了兩個(gè)線(xiàn)程嗎?
            一個(gè)做DP和flip
            另一個(gè)回調(diào)frameRenderingQueued
            2008-09-25 08:49 | LOGOS

            # re: Ogre在游戲開(kāi)發(fā)中逐幀更新  回復(fù)  更多評(píng)論   

            呵呵,ogre系統(tǒng)好象是這樣的.
            2008-09-25 10:35 | brilyf

            只有注冊(cè)用戶(hù)登錄后才能發(fā)表評(píng)論。
            網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問(wèn)   Chat2DB   管理


            国产精品成人久久久久久久| 久久久噜噜噜久久中文字幕色伊伊| 色诱久久av| WWW婷婷AV久久久影片| 777午夜精品久久av蜜臀| 久久精品亚洲福利| 国产激情久久久久影院小草| 97精品久久天干天天天按摩| 久久青青草原亚洲av无码app| 久久男人AV资源网站| 久久亚洲AV无码西西人体| 91久久婷婷国产综合精品青草 | 久久婷婷色香五月综合激情| 国产福利电影一区二区三区久久久久成人精品综合 | 欧美久久久久久精选9999| 国产精品日韩欧美久久综合| 亚洲精品国产成人99久久| 亚洲国产成人久久综合碰碰动漫3d | 亚洲国产欧美国产综合久久| 亚洲国产另类久久久精品小说| 亚洲综合熟女久久久30p| 人人狠狠综合久久88成人| 国产精品18久久久久久vr| 国产精品日韩深夜福利久久| 久久只这里是精品66| 亚洲午夜无码久久久久| 九九久久99综合一区二区| 久久国产精品二国产精品| 久久久久久久精品成人热色戒| 午夜精品久久久久久久久| 久久国产一区二区| 亚洲国产成人精品无码久久久久久综合| 伊人久久大香线蕉精品不卡| 色综合久久久久无码专区| 国产呻吟久久久久久久92| 久久99久国产麻精品66| 亚洲一本综合久久| 亚洲综合日韩久久成人AV| 狠狠色综合久久久久尤物| 国内高清久久久久久| 成人a毛片久久免费播放|