本發(fā)明涉及遠程控制
技術領域：
，特別涉及一種采用虛擬手柄控制游戲的方法。
背景技術：
：虛擬手柄是指利用一個手機(或PAD)APP或者一個連接接在電視盒子上面的USB真實手柄，能玩連接在同一個局域網下面的遠程PC上的游戲，達到像一個真實手柄連接在PC上玩游戲的一種解決方案。現有的連接方案包括采用UDP協議或者TCP協議進行控制信息的傳輸，其中TCP傳輸的特點在于：面向連接、傳輸可靠(保證數據正確性以及數據順序)、用于傳輸大量數據、速度慢，建立連接需要開銷較多(時間，系統(tǒng)資源)。而UDP傳輸的特點在于：面向非連接、傳輸不可靠、用于傳輸少量數據(數據包模式)、速度快?，F有技術關于采用UDP和TCP傳輸數據的方法包括：申請?zhí)枮镃N201410852842.X的題目為《一種基于TCP/UDP混合協議的流媒體無線自適應傳輸方法》的申請，其中涉及TCP/UDP混合協議的流媒體無線自適應傳輸方法，將TCP協議傳輸可靠的特點與UDP協議傳輸開銷小、速度快、效率高特點相結合。但是由于游戲采用定時輪詢獲取手柄按鍵狀態(tài)的特殊性，采用傳統(tǒng)的UDP和TCP相結合的傳輸方法是不合適的。技術實現要素：有鑒于此，本發(fā)明的主要目的在于，提供一種采用虛擬手柄控制游戲的方法，包括步驟：A、虛擬手柄將控制指令分別通過TCP和UDP傳輸通道發(fā)送至虛擬手柄管理器；B、虛擬手柄管理器依據TCP和UDP傳輸通道接收控制指令的次序確定當前控制指令；C、游戲應用讀取并解析所述當前控制指令，將所述控制指令與游戲動作匹配。由上，同時通過TCP和UDP傳輸通道向虛擬手柄管理器發(fā)送控制指令，當UDP正常傳輸不丟包時，保證了虛擬手柄對游戲控制的延時性大大降低；而當UDP丟包時，TCP通道的存在保證了控制指令的完整有效性。可選的，所述步驟B包括：虛擬手柄管理器查詢TCP和UDP任一傳輸通道接收到控制指令后，查詢該控制指令所對應的索引值Index，判斷該控制指令的索引值indexk和前次接收到的控制指令的索引值indexk-1的大小，如果indexk＞indexk-1，則將該控制指令確定為當前控制指令。由上，當通過TCP和UDP任一傳輸通道接收到控制指令后，首先判斷該指令是不是“新”指令，若是新指令，便直接進行后續(xù)操作。由于UDP的實時性較高，保證了控制指令能盡可能快的到達虛擬手柄管理器。UDP會丟包，可由于手柄控制游戲的特殊性，只要最后一個包不丟掉頂多有一次操作時無效的，是可以接受的，最后一個包能到達是通過TCP連接來保證的。使用TCP+UDP雙通道傳輸，如果UDP傳輸通道的第K+1條指令先于TCP傳輸通道的第K條指令，則直接處理第K+1條指令。反之UDP通道接收到第K條指令而丟失第K+1條指令，由于TCP的存在，保證第K+1條指令不會丟失，僅稍晚接收到?？蛇x的，所述索引值Index至少包括控制指令所對應操作的數字編碼以及代表控制指令次序的編號?？蛇x的，步驟B后還包括：步驟B后還包括：虛擬手柄管理器以UDP傳輸通道所接收的當前控制指令為基準，控制TCP傳輸通道把收到的當前控制指令之前的其他控制指令直接丟棄，而不用交給游戲。附圖說明圖1為采用虛擬手柄控制游戲的方法的原理示意圖；圖2為實現虛擬手柄控制游戲的拓撲圖。具體實施方式為克服現有技術存在的缺陷，本發(fā)明提供一種采用虛擬手柄控制游戲的方法。如圖1所示，虛擬手柄的控制方法包括以下步驟：S11：虛擬手柄與虛擬手柄管理器建立通信連接。如圖2所示為實現虛擬手柄控制游戲的拓撲圖，其中，由于虛擬手柄采用手機APP或者連接在電視盒子等智能終端上的USB真實手柄。所述虛擬手柄作為DirectInput(普通游戲手柄)被識別。在進行虛擬手柄的控制前，虛擬手柄管理器首先需要與虛擬手柄建立握手通道，從而實現控制指令的接收。所述虛擬手柄管理器與游戲可統(tǒng)稱為游戲執(zhí)行端。具體的，虛擬手柄啟動后，首先發(fā)送UDP管理器發(fā)送廣播，用于發(fā)現可以連接的虛擬手柄管理器，當所述虛擬手柄管理器的數量多于2個時，需要用戶手動選擇要連接到的虛擬手柄管理器。當被選中的虛擬手柄管理器在其UDP監(jiān)聽端口接收到虛擬手柄所發(fā)出的廣播時，給予應答。虛擬手柄接收到該應答信息后，向虛擬手柄管理器發(fā)送確認建立TCP連接請求，從而二者建立連接。所述TCP通信連接需要虛擬手柄和虛擬手柄管理器之間至少三次對話。另外，所述虛擬手柄還可以向虛擬手柄管理器的UDP發(fā)現端口直接發(fā)送控制指令。需要說明的是，虛擬手柄管理器的UDP發(fā)現端口和接受控制指令是復用的。S12：虛擬手柄通過UDP和TCP兩通道同時輸出控制指令。當虛擬手柄為手機(或PAD)APP實現時，APP獲取用戶觸碰手機(或PAD)屏幕的屬性，所述屬性包括按下、彈起狀態(tài)；按下時間等等。將上述物理操作轉換為數字編碼，分別同時通過步驟S11所建立的UDP和TCP通道輸出上述控制指令。當虛擬手柄為連接在電視盒子等智能終端上的USB真實手柄時，智能終端接收USB真實手柄的鍵值變化，表示鍵值變化的數字編碼同時通過步驟S11所建立的UDP和TCP通道輸出上述控制指令。本步驟中，由于虛擬手柄產生相同的控制指令，故其通過UDP和TCP通道所輸出的控制指令相同。步驟S13：虛擬手柄管理器依據接收控制指令的先后順序確定出將要執(zhí)行的控制指令。虛擬手柄管理器分別為UDP和TCP通道所接收的控制指令分配起始的索引值Index初。用于設定索引值初值，當收到新的索引值時，與Index初對比，大于Index初即認為所接收的控制指令有效。所述索引值包括各條控制指令的數字編碼，索引值Index的數據量依據控制指令的增加而增加。虛擬手柄管理器在接收到控制指令時，判斷當前控制指令的索引值indexk和前次所控制指令的索引值indexk-1的大小，如果indexk＞indexk-1，表示第K次控制指令是當前控制指令，則更新當前控制指令indexk到共享內存中相對應的虛擬手柄的地址中去，否則，丟棄當前控制指令的索引值indexk。其中indexk表示第k條控制指令的的索引值。由于采用UDP傳輸時，其實時性較高，由此可以保證控制指令以最快速度到達虛擬手柄管理器。舉例來說，當虛擬手柄管理器通過UDP端口率先收到第K條控制指令后，便進行指令解析以及游戲動作匹配，具體過程后文詳述。此后，當虛擬手柄管理器通過TCP端口接收到第K-1條控制指令時，便直接被忽略。另一方面，由于UDP傳輸的局限性，其可能會產生虛擬手柄管理器接收時丟失控制指令的情況。例如，UDP通道傳輸時，收到第K條控制指令而丟失第K+1條控制指令，則在下次接收時，判斷UDP通道的K+2條控制指令和TCP通道的K+1條控制指令的先后接收順序，并依照接收順序進行指令解析以及游戲動作匹配。例如，若UDP的第K+2條控制指令先來，則游戲直接執(zhí)行第K+2條控制指令，而如果TCP的第K+1條指令先到，則游戲先執(zhí)行第K+1條控制指令。當UDP通道的K+2條控制指令先接收到，則該控制指令中已包含K+1條控制指令，則直接忽略第K條控制指令而執(zhí)行K+2條控制指令，且不會對游戲造成“不可挽回”的影響。而即便UDP通道的第K條控制指令以后全部丟包時，仍可通過TCP通道保證虛擬手柄所有控制指令均正常到達。需要理解的是，由于手柄的特殊性，上面這種跳過指令的方式對游戲來說會有幾率出現錯誤，但不會造成“不可挽回”的影響。因為經過無論多少次手柄操作后，手柄最終的狀態(tài)一定是所有按鍵都是彈起的。而這個彈起的控制指令，TCP保證了這個指令一定能順利發(fā)送給游戲。相反的，假定是用另外一種不丟包的方案。假定已經收到第K個包。如果本次收到了K+2條指令，那么需要等K+1條指令后，然后分別更新K+1條指令和K+2條指令到共享內存。這么做是沒有意義的，因為更新K+1條指令和K+2條指令到共享內存時間是非常短的(只有幾條CPU指令)，而游戲使用控制命令通常是毫秒級別的定時器，因此游戲取到的肯定也是K+2條指令，也就是說K+1條指令還是被忽略了。然后這么做還有另外一個副作用，由于K+2條指令不能及時被執(zhí)行，導致后面的K+3條指令和/或K+4條指令的時間間隔發(fā)生了變化，反而導致了更多的錯誤。因此，本發(fā)明的方案是肯定優(yōu)于不丟包方案的。即，本實施例中，采用UDP和TCP通道同時傳輸出控制指令，當UDP正常傳輸不丟包時，保證了虛擬手柄對游戲控制的延時性大大降低；而當UDP丟包時，TCP通道的存在保證了控制指令的完整有效性。例如，在步驟S13中如下表1所示分別為虛擬手柄管理器通過TCP和UDP傳輸通道接收到第K～K+5條控制指令的情況。TCP傳輸通道UDP傳輸通道K(第1毫秒收到)K(第0.6毫秒收到)K+1(第2毫秒收到)K+1(第0.9毫秒收到)K+2(預計第4毫秒收到)K+2(丟包)K+3(預計第7毫秒收到)K+3(丟包)K+4(預計第8毫秒收到)K+4(第2.3毫秒收到)K+5(預計第10毫秒收到)K+5(丟包)K+6(結束動作幀，預計第11毫秒收到)K+6(丟包)表1上述實施例中，采用UDP傳輸通道在接收第K+2、K+3、K+5和K+6條指令時均發(fā)生丟包情況。在不采用任何處理的情況下，游戲在第0.6毫秒執(zhí)行第K條控制指令、0.9毫秒執(zhí)行第K+1條、第2.3毫秒執(zhí)行第K+4條、第10毫秒執(zhí)行第K+5條、第11毫秒執(zhí)行第K+6條。S14：解析所確定出的控制指令，將所述控制指令與游戲動作匹配。采用COMHOOK技術，將虛擬手柄(HOOKDirectInput)注入到游戲，且隨游戲啟動。所述HOOK技術用于攔截游戲對DirectInputAPI的函數調用，其中主要HOOK了EnumDevice這個函數。游戲啟動后會枚舉當前連接的虛擬手柄設備，HOOK技術讀取虛擬手柄管理器的共享內存中虛擬手柄數量，并返回給游戲，游戲需要讀取虛擬手柄數據時，HOOK技術將共享內存中的控制指令反饋給游戲，從而實現對于游戲的控制。上述虛擬手柄對于游戲的控制屬于現有技術，不再贅述。以上所述僅為本發(fā)明的較佳實施例而已，并不用以限制本發(fā)明。總之，凡在本發(fā)明的精神和原則之內，所作的任何修改、等同替換、改進等，均應包含在本發(fā)明的保護范圍之內。當前第1頁1 2 3