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

            天地之靈

            Seed Engine中的輸入系統(tǒng)(一)、底層架構(gòu)、歷史

            今天看了叛大的 KlayGE中輸入系統(tǒng)的改進(jìn)系列文章,覺得可以談?wù)凷eed Engine中的輸入系統(tǒng)。
            因?yàn)镾eed Engine誕生之初,就定位為主要面向Android、iOS等移動(dòng)設(shè)備(直到2012年6月才有了Flash平臺(tái)的內(nèi)部版本,才開始正式需求鼠標(biāo)事件),所以Seed的輸入模塊除了對(duì)鍵盤做了簡(jiǎn)單支持(主要是出于調(diào)試目的)外,在很長(zhǎng)的一段時(shí)間內(nèi),鼠標(biāo)事件都是被wrap成為觸摸事件。所有后續(xù)關(guān)于輸入的工作都是針對(duì)觸摸來做的。所以這篇文章主要重點(diǎn)講觸摸這個(gè)方面,尤其是手勢(shì)識(shí)別的做法。
            在Seed發(fā)展至今的期間,面臨了大量復(fù)雜的需求,不斷改進(jìn)完善,目前還有很多不盡善盡美的地方。這篇文章會(huì)回顧一下這個(gè)過程,重點(diǎn)介紹一下當(dāng)前的處理機(jī)制,再展望一下將來期望進(jìn)行的改進(jìn)工作。

            Seed目前總計(jì)支持四種輸入:鍵盤、鼠標(biāo)、觸摸、重力感應(yīng)。
            所有的輸入會(huì)被響應(yīng)的處理模塊封裝成一個(gè)struct,這個(gè)struct的頭四個(gè)字節(jié)表明了觸摸的類型。在單線程模式下,這個(gè)struct會(huì)被直接傳遞給應(yīng)用。在多線程模式下,這個(gè)struct會(huì)在堆上分配,將指針傳遞給邏輯線程。這樣的好處是在邏輯線程忙的時(shí)候,消息處理函數(shù)可以更及時(shí)返回,避免諸如窗口拖動(dòng)卡頓之類的問題。
            這一部分極其簡(jiǎn)單,因?yàn)楹?jiǎn)單,所以不容易出問題。之所以把底層架構(gòu)放在歷史之前談,正是因?yàn)樽詮?011年10月份Seed誕生以來,引擎的這部分代碼幾乎從未變過。
            對(duì)于Lua層來說,這部分的接口一直表現(xiàn)為一個(gè)全局事件,input.key、input.touch等等,參數(shù)struct會(huì)被iLuaWrapper(Seed中一個(gè)神秘組件)包裝成Lua可以直接訪問的數(shù)據(jù),由Lua腳本去做任何上層的處理。

            裸奔時(shí)代

            Seed誕生以后的一段時(shí)間內(nèi),當(dāng)時(shí)的工作重心在完善2D渲染基礎(chǔ)、2D場(chǎng)景管理,2D物理等等較為繁雜的模塊上。因?yàn)闆]有具體項(xiàng)目的負(fù)擔(dān),當(dāng)時(shí)的輸入模塊只以滿足調(diào)試需求、實(shí)現(xiàn)簡(jiǎn)單交互為目的。因此,Seed在2011年10月以前,一直處在輸入裸奔的狀態(tài)。譬如只用鍵盤做操控,那就直接注冊(cè)input.key去監(jiān)聽需要的事件。為了實(shí)現(xiàn)諸如簡(jiǎn)單的按鈕之類的功能,當(dāng)時(shí)產(chǎn)生了一堆垃圾代碼,在事件里直接判定坐標(biāo)等等。當(dāng)然,這樣寫代碼是不可能做出沒有BUG的游戲來的,于是我們?cè)谝粋€(gè)游戲項(xiàng)目的原型階段結(jié)束后不久的時(shí)間,迅速推出了第一套框架。

            山寨時(shí)代

            因?yàn)樾枨缶o迫,做任何游戲至少都少不了做一堆能tap的button出來,所以我們抓緊推出了第一版的input_ex插件。
            input_ex以盡可能簡(jiǎn)單的方式實(shí)現(xiàn)了對(duì)指定對(duì)象的觸摸事件處理。場(chǎng)景中的node可以被注冊(cè)到input_ex中,以接受tap、hold、drag事件。在touchdown的時(shí)候,input_ex會(huì)遍歷所有注冊(cè)的結(jié)點(diǎn)以找到被命中的node,之后的消息都會(huì)派發(fā)給這個(gè)node。
            好吧,至少現(xiàn)在可以創(chuàng)建一堆不同的button了。input_ex的嚴(yán)重不足主要體現(xiàn)在功能上:
                    1、input_ex中的手寫狀態(tài)機(jī),幾乎決定了除了tap、hold、drag以外,每加一個(gè)新的操作種類都是一個(gè)巨大的困難。
                    2、input_ex不能很好的處理多點(diǎn)觸摸。在多點(diǎn)的設(shè)備上各種出問題,以至于后來在某些項(xiàng)目里,強(qiáng)行屏蔽了除了1號(hào)手指(對(duì)應(yīng)安卓里的0號(hào)手指)以外的所有操作。
                    3、消息最開始就確定了對(duì)象,隨后的過程不能改變消息的對(duì)象。譬如一個(gè)scrollview上面有一堆button,那么當(dāng)button截獲了消息的時(shí)候,scrollview就無法處理相應(yīng)的拖拽事件了。
            除此以外,在使用上,每個(gè)節(jié)點(diǎn)存在一個(gè)獨(dú)立的用于處理輸入的對(duì)象,其生命周期需要手動(dòng)管理,錯(cuò)誤的使用會(huì)導(dǎo)致各種問題。初學(xué)者幾乎很難寫出正確的代碼。因?yàn)閷?shí)現(xiàn)復(fù)雜,input_ex本身也在很長(zhǎng)的時(shí)間內(nèi)都存在引用關(guān)系的BUG,導(dǎo)致不需要的資源不能被正確的釋放。總體來說,使用input_ex插件做游戲簡(jiǎn)直是一段不堪回憶的黑歷史。

            山寨時(shí)代之后

            在使用input_ex完成了三四個(gè)界面操作簡(jiǎn)單的小游戲后,我們開始構(gòu)思新的輸入系統(tǒng)。我們理想中的輸入系統(tǒng)應(yīng)該符合如下幾個(gè)條件:
            1、很好的支持多點(diǎn)觸摸。這包含兩方面:第一,必須能夠很好的識(shí)別利用多個(gè)手指的操作,譬如scale, pinch, rotate等。第二,我們認(rèn)為對(duì)于大屏幕的觸屏設(shè)備,能讓多個(gè)玩家在不同的地方互不干擾的進(jìn)行多個(gè)操作也是很有必要的需求,這會(huì)給游戲設(shè)計(jì)師帶來很多新奇的玩法創(chuàng)意。
            2、一定要很方便的加入各種不同的操作識(shí)別。我們希望能夠?qū)崿F(xiàn)很多有創(chuàng)意的小游戲,依靠觸摸的操作來做很多有意思的事情。我們也希望我們的界面能夠交互起來更酷,可以操作控制的地方更多。那么操作一定不能只局限于區(qū)區(qū)數(shù)種,一定要在特定的游戲里就能通過代碼添加大量不同的全新操作才行。
            3、操作對(duì)象的識(shí)別更智能。在scrollview 上面的button做scroll操作時(shí),操作對(duì)象要能正確的變成scrollview。
            4、根據(jù)操作對(duì)象所接受的事件有所不同,以及其父結(jié)點(diǎn)所接受的事件有所不同,對(duì)同一事件的處理可能會(huì)有差別。譬如一個(gè)button接受tap,當(dāng)觸摸并移動(dòng)的時(shí)候,只要沒移開范圍,邏輯應(yīng)等待手指松開時(shí)再判定為tap成功(正如你在windows下按住一個(gè)按鈕然后小范圍拖動(dòng)鼠標(biāo),click并不會(huì)因此而失敗)。但假如這個(gè)button有一個(gè)父結(jié)點(diǎn)甚至是祖先結(jié)點(diǎn)接受drag,那么早在剛開始移動(dòng)的時(shí)候,就應(yīng)該判定為tap取消,事件轉(zhuǎn)為drag事件而派發(fā)給相應(yīng)的祖先結(jié)點(diǎn)。
            5、不會(huì)為了滿足上面的需求,把上層邏輯代碼搞的太麻煩。最理想的情況下,上層邏輯代碼只要選擇好自己所接受的操作種類,然后安心等待事件監(jiān)聽器被調(diào)用就好了。
            而我們不想要:
            1、像安卓那樣復(fù)雜的事件分派機(jī)制,所有的觸摸都被綁在一起依次分派下去,在結(jié)點(diǎn)上依據(jù)類型的不同寫代碼去做對(duì)應(yīng)的操作。必須要有一個(gè)很好的手勢(shì)識(shí)別底層,僅僅把結(jié)點(diǎn)關(guān)心的信息拋給它。
            2、像HTML DOM那樣的事件冒泡機(jī)制。因?yàn)橛|摸處理的復(fù)雜性,在touch down的時(shí)候往往根本不能確定真正用戶想要進(jìn)行何種操作。而如果等操作進(jìn)行完了才給予反饋,那操作過程就很難得到非常及時(shí)的反饋。在上述scrollview和button的例子里,button必須首先獲得事件以立即展現(xiàn)被按下的效果,等到用戶的操作能夠明確為一個(gè)scroll操作之后,再由scrollview來處理后續(xù)的事件。再加上之前所述的期望4,已經(jīng)不是簡(jiǎn)單的對(duì)同一事件的冒泡足以滿足的。
            真的有一套框架能完美的解決我們的需求嗎?下一章起,我會(huì)逐步講解我們?yōu)榇怂龅呐Α?/div>

            posted on 2013-04-12 01:31 天地之靈 閱讀(150) 評(píng)論(0)  編輯 收藏 引用


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


            <2013年11月>
            272829303112
            3456789
            10111213141516
            17181920212223
            24252627282930
            1234567

            導(dǎo)航

            統(tǒng)計(jì)

            • 隨筆 - 7
            • 文章 - 2
            • 評(píng)論 - 11
            • 引用 - 0

            常用鏈接

            留言簿(3)

            隨筆檔案

            文章檔案

            搜索

            •  

            最新評(píng)論

            閱讀排行榜

            評(píng)論排行榜

            久久精品国产第一区二区| 久久天天躁狠狠躁夜夜avapp| 伊人久久国产免费观看视频| 久久精品视屏| 久久精品国产亚洲AV大全| 欧美一级久久久久久久大| 国产精品一区二区久久国产| 精品久久久久久无码人妻蜜桃| 亚洲精品乱码久久久久久中文字幕| 国产精品无码久久四虎| 久久一日本道色综合久久| 久久精品中文字幕一区| 国产亚州精品女人久久久久久| 久久精品青青草原伊人| 久久综合九色综合97_久久久| 国产精品美女久久久久| 国产99精品久久| 色老头网站久久网| 精品久久久久久综合日本| 怡红院日本一道日本久久 | 久久播电影网| 久久精品99久久香蕉国产色戒| 欧美日韩成人精品久久久免费看 | 久久99国产精一区二区三区| 久久精品一区二区影院| 久久天天躁狠狠躁夜夜2020一| 久久久久国产| 综合久久精品色| 国产精品伦理久久久久久| 久久AV高清无码| 久久99久国产麻精品66| 久久久久国产精品麻豆AR影院| 久久亚洲AV成人无码软件 | 亚洲伊人久久综合影院| 天天爽天天爽天天片a久久网| 久久精品免费一区二区| 精品综合久久久久久88小说| 国产精品成人99久久久久| 精品久久久久久无码人妻蜜桃| 熟妇人妻久久中文字幕| 国产精品成人99久久久久 |