在midp2.0中，把sprite封裝成為了乙個類，在這個sprite類裡面系統自動實現精靈的碰撞：
public final boolean collideswith(tiledlayer t, boolean pixellevel)
public final boolean collideswith(image image, int x, int y, boolean pixellevel)
boolean型的變數pixellevel的作用是用來指定是畫素級碰撞檢測還是矩陣級的，一般來說，可以通過規定矩陣交叉的值來決定碰撞的精確性，通常進行碰撞檢測的矩陣的大小都比實際的的大小要小一些。
運動著的精靈與靜止的事物的碰撞：（這裡的精靈主要指的是主角等比較大的物體）
在碰撞的時候應該將精靈運動的步長考慮進去，否則就可能出現精靈插到了物體裡面去的情況。
初步構思：
在碰撞檢測函式裡面增加乙個判斷，如果當精靈與靜止物體的距離（產生碰撞的兩點之間的距離）小於運動步長dx時就把當然精靈的座標直接改變為到與物體碰撞時的狀態。具體**：
public boolean bcollideswith(int x,int y,byte temprange)
其實這樣的碰撞檢測函式是有缺陷的，在一些情況下面會出現精靈穿過障礙物的情況，因為這個函式的設計在考慮的時候只考慮到了一維的情況，在處於同一條直線上面進行碰撞，這樣的檢測函式已經夠了，甚至可以說判斷碰撞檢測的範圍選的有些大了，但是如果放在了二維下面這樣是不對的，即使加上了y座標的判斷，也會出現漏洞。
即使這樣：
return postionx+range[0]/2<=x&&postionx+range[0]/2+temprange[0]/2>=x&&
postiony <= y &&postiony >= y - temprange[1]
||postionx<=x+temprange[0]/2+range[0]/2&&postionx>x+range[0]/2&&
postiony <= y &&postiony >= y - temprange[1]
||postionx+range[0]/2<=x&&postionx+range[0]/2+temprange[0]/2>=x&&
postiony >= y &&postiony <= y + this.range[1]
||postionx<=x+temprange[0]/2+range[0]/2&&postionx>x+range[0]/2&&
postiony >= y &&postiony <= y + this.range[1]
這個碰撞檢測函式是對矩形區域的四個頂點進行判斷，這裡就只看左下角的點。但x座標在範圍 postionx+range[0]/2<=x&&postionx+range[0]/2+temprange[0]/2>=x就在x座標上面符合碰撞的要求，但是應該指出的是這個範圍在二維下面小了一點。假如從障礙物的上方，且兩個物體的中心處在一條直線上面的時候，就出了問題了。假如postionx=200，x=200,range[0]=6,temprange[0]=56,那麼這是postionx+range[0]/2>x,postionx+range[0]/2= x &&
postionx <= x + temprange[0] / 2 + this.range[0] / 2 &&
postiony >= y &&
postiony <= y + this.range[1]
||postionx <= x && postionx + this.range[0] / 2 + temprange[0] / 2 >= x &&
postiony >= y &&
postiony <= y + this.range[1]
||postionx >= x && postionx <= x + temprange[0] / 2 + this.range[0] / 2 &&
postiony <= y &&
postiony >= y - temprange[1]
||postionx <= x && postionx + this.range[0] / 2 + temprange[0] / 2 >= x &&
postiony <= y &&
postiony >= y - temprange[1]
這個函式在原來的基礎上範圍擴大了range[0]/2，這樣就不會出現上面的漏洞了，而且這個函式是考慮到了的所有的情況，只要當前檢測點處在障礙物的範圍類就會返回true。
下面的問題是，用這個函式進行碰撞檢測就已經足夠了嗎？答案是否定的。
這樣的碰撞檢測至少還存在兩個方面的問題：還是無法處理精靈插到障礙物裡面去的情況，特別是在非**類碰撞時這是肯定不行的，比如二維空間裡面的乙個球去撞乙個物體，撞到以後被**回來。
另外乙個問題就是，有時候物體或者精靈的形狀是不規則的，如果只是用矩形檢測，可能會太粗略，就可能出現沒有碰撞到物體就被判斷為碰撞到的情況。
下面乙個問題乙個問題的解決:
第乙個問題:
對於**類的碰撞就無需考慮這個問題了，因為這樣的碰撞，在碰撞發生以後精靈的狀態就會發生改變，比如子彈擊中目標以後會發生**等等。
其實在前面一維的情況的時候就已經考慮過這個問題了，只是那個時候的解決方法不是很好而且也不能用到二維的情況下。對於這樣的問題，檢測函式不需要進行任何改變，只是在呼叫檢測函式的時候需要作一些變動，已經進行碰撞處理的時候都是判斷當前的檢測是否出於碰撞檢測的範圍類，如果不是就讓精靈繼續往前。其實這樣做就間接的造成了精靈插到障礙物裡面去的現象。例如當然檢測點不在範圍類，但是與檢測範圍邊界的距離小於精靈移動的步長，下乙個狀態的時候精靈的座標就回移動乙個步長的距離，這個時候精靈已經插到了障礙物裡面去了，當前狀態就是當前paint()函式所畫的狀態，所以在螢幕上面表現出來的就是精靈插入到了障礙物裡面去了。
下面進行改進，進行處理的時候我們是判斷精靈的下乙個狀態是否發生了碰撞，如果沒有就繼續前進，如果發生了，就再進行一次判斷，判斷檢測點的座標是否已經處在範圍的裡面，如果是，就調整精靈的座標，使它的座標值在下乙個狀態的時候處於乙個合理的位置，比如前面的碰撞**，就可以讓檢測點處於碰撞範圍的邊界上面。
遊戲中的碰撞檢測
遊戲中的碰撞檢測方式有很多，不同的演算法之間主要是在精度和速度之間權衡。以下幾種方式按照速度排序說明。以2d為例，3d不過是增加了一維罷了，演算法理解上沒太大區別。一 地圖格仔劃分檢測 最簡單的一種檢測，就是把地圖 或者稱為場景，總之是指碰撞發生的範圍 劃成乙個個格仔，類似仙劍奇俠傳這樣。假設地圖有...
遊戲中的碰撞檢測
遊戲中的碰撞檢測方式有很多，不同的演算法之間主要是在精度和速度之間權衡。以下幾種方式按照速度排序說明。以2d為例，3d不過是增加了一維罷了，演算法理解上沒太大區別。一 地圖格仔劃分檢測 最簡單的一種檢測，就是把地圖 或者稱為場景，總之是指碰撞發生的範圍 劃成乙個個格仔，類似仙劍奇俠傳這樣。假設地圖有...
遊戲中的碰撞檢測
遊戲中的碰撞檢測方式有很多，不同的演算法之間主要是在精度和速度之間權衡。以下幾種方式按照速度排序說明。以2d為例，3d不過是增加了一維罷了，演算法理解上沒太大區別。一 地圖格仔劃分檢測 最簡單的一種檢測，就是把地圖 或者稱為場景，總之是指碰撞發生的範圍 劃成乙個個格仔，類似仙劍奇俠傳這樣。假設地圖有...