• <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>

            天行健 君子當(dāng)自強(qiáng)而不息

            Working with Maps and Levels(9)

            Blocking the Path with Barriers

            You know—detecting when your character is walking around the map bumping into walls or standing
            on solid ground. What about objects such as doors blocking your character’s way?
            Because a door is not part of the terrain, I didn’t include a door when I constructed
            the collision detection code. Now is the time to remedy that situation.

            Anything that bars clear passage of a character’s movement is called a barrier.
            Barriers can exist in two states—open (disabled) or closed (enabled). Characters
            are allowed to pass through a barrier when it is open, but they cannot pass through
            when the barrier is closed.

            You can treat barriers much as you do triggers. You can define a barrier similar to
            the way you define a trigger on a map. You can define barriers as spheres, boxes,
            cylinders, and triangles. Barriers can also have an enabled state, with true meaning
            that the barrier is blocking the character’s passage and false meaning that the way
            through the barrier is clear.

            The big difference between barriers and triggers is that barriers can have meshes
            and animation assigned to them. This relieves you of the burden of drawing the
            barrier and gives the job to the barrier engine. All you have to do is assign the
            meshes and animations.

            You start off using barriers with the barrier class declaration,
            which looks very similar to the trigger class declaration. Notice that I also
            define an enum list and structure (sBarrier) used to contain each barrier’s data:

            enum BarrierType
            {
                BARRIER_SPHERE = 0, BARRIER_BOX, BARRIER_CYLINDER, BARRIER_TRIANGLE
            };

            /********************************************************************************************/

            typedef 
            struct sBarrier
            {
                
            long    type;  // BARRIER_SPHERE, BARRIER_BOX, etc.
                long    id;
                
            bool    enabled;

                
            float   x_pos, y_pos, z_pos;
                
            float   x_rot, y_rot, z_rot;

                
            float   x1, y1, z1;
                
            float   x2, y2, z2;
                
            float   x3, z3;

                
            float   radius;

                cObject 
            object;

                sBarrier*   prev;
                sBarrier*   next;

                
            //////////////////////////////////////////////////////////////////////

                sBarrier()  
                { 
                    prev = next = NULL; 
                }

                ~sBarrier() 
                { 
                    delete next; next = NULL;  
                }
            } *sBarrierPtr;

            Here’s where the similarities between the triggers and barrier end. A barrier needs
            a graphical representation (a 3-D mesh), so the code adds a Graphics
            Core cObject object that is used to contain the barrier’s mesh and animation data.

            Getting back to the similarities of the trigger and barrier classes, notice the pointers
            that maintain the linked list as well as the sBarrier structure constructor and
            destructor.

            The similarities between triggers and barrier continue with the declaration of the
            barrier class:

            typedef class cBarrier
            {
            private:
                
            long        m_num_barriers;
                sBarrier*   m_root_barrier;

                
            //////////////////////////////////////////////////////////////////////

            public:
                cBarrier()
                {
                    m_num_barriers = 0;
                    m_root_barrier = NULL;
                }
                
                ~cBarrier()
                {
                    free();
                }

                
            void free()
                {
                    delete m_root_barrier;
                    m_root_barrier = NULL;

                    m_num_barriers = 0;
                }

                
            long get_num_barriers()
                {
                    
            return m_num_barriers;
                }

                sBarrier* get_root_barrier()
                {
                    
            return m_root_barrier;
                }
             

            Shift your focus for a moment to the arguments that the add_barrier function is taking.
            Aside from the position in which to position the barrier (using the x_pos, y_pos,
            and z_pos arguments), the add_barrier function takes the rotational values in which to
            draw the barrier’s mesh (using the x_rot, y_rot, and z_rot arguments that represent the
            X-, Y-, and Z-rotational values, in radians, respectively).

            Notice that the addition of rotational values throughout the barrier class, as well as
            the addition of an extra trio of coordinates that define the mesh’s position in the
            world. As you come upon these additional values, I’ll be sure to point them out.

                sBarrier* add_barrier(long type, long id, bool enabled,
                                      
            float x_pos, float y_pos, float z_pos,
                                      
            float x_rot, float y_rot, float z_rot)
                {
                    
            // allocate a new barrier structure and link in

                    sBarrier* bar = 
            new sBarrier;

                    bar->prev = NULL;
                    bar->next = m_root_barrier;

                    
            if(m_root_barrier)
                        m_root_barrier->prev = bar;

                    m_root_barrier = bar;

                    bar->type    = type;
                    bar->id      = id;
                    bar->enabled = enabled;
                    bar->x_pos   = x_pos;
                    bar->y_pos   = y_pos;
                    bar->z_pos   = z_pos;
                    bar->x_rot   = x_rot;
                    bar->y_rot   = y_rot;
                    bar->z_rot   = z_rot;

                    m_num_barriers++;

                    
            return bar;
                }  

            posted on 2007-12-10 13:50 lovedday 閱讀(185) 評(píng)論(0)  編輯 收藏 引用


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


            公告

            導(dǎo)航

            統(tǒng)計(jì)

            常用鏈接

            隨筆分類(lèi)(178)

            3D游戲編程相關(guān)鏈接

            搜索

            最新評(píng)論

            久久精品中文字幕有码| 精品伊人久久大线蕉色首页| 久久人人爽人人爽人人片AV高清| 久久人妻少妇嫩草AV蜜桃| 久久久不卡国产精品一区二区| 久久男人AV资源网站| 久久久久成人精品无码中文字幕| 色偷偷88888欧美精品久久久 | 久久久久免费看成人影片| 亚洲狠狠综合久久| 久久婷婷午色综合夜啪| 久久这里只精品国产99热| 一级做a爰片久久毛片毛片| 精品国产一区二区三区久久| 久久久久久久久66精品片| 国产精品一久久香蕉国产线看| 亚洲欧美日韩久久精品| 精品久久久久久久久久久久久久久| 亚洲日韩欧美一区久久久久我| 久久免费高清视频| 久久久久一区二区三区| 久久99精品久久久久久久不卡| 久久无码国产专区精品| 久久久一本精品99久久精品88| 99久久精品免费看国产一区二区三区 | 国产亚洲精午夜久久久久久| 一本色综合网久久| 人妻精品久久久久中文字幕69| 久久人人爽人人爽人人片AV不 | 国产成人精品综合久久久久| 精品久久久无码21p发布| 国产人久久人人人人爽| 久久精品国产亚洲一区二区三区| 久久亚洲高清观看| 色偷偷88888欧美精品久久久| 久久精品国产亚洲AV香蕉| 国产91久久综合| 久久国产免费直播| 无码精品久久一区二区三区| 久久天天躁狠狠躁夜夜网站| 伊人久久精品影院|