我的一般建議:永遠不要修改默認的anchorPoint(0.5f,0.5f),除非你對它的功能有很好的理解,以及它如何幫助你完成任務。在所有其他情況下,修改職位屬性。
特別是如果您執行基於邊界框或半徑的碰撞檢測,修改錨點將會適得其反。
讓我們假設你的矩形精靈形象使用默認的定位點,這是在紋理的中心:
._______.
| |
| |
| * |
| |
| |
°-------°
的*標誌着紋理的anchorPoint。如果你將這個精靈放置在位置(250,100),那麼精靈的anchorPoint將位於座標(250,100)。
比方說,你移動到anchorPoint(0.1F,0.1F):
._______.
| |
. | . |
| |
| |
| * |
°-------°
° °
精靈的位置保持在(250,100)不變。 anchorPoint的位置也不會改變。紋理如何以這一點爲中心進行變化。在通過查看浮點來修改錨點之前,您可以看到之前的圖像位置。實際上,通過修改anchorPoint所做的全部工作就是移動(偏移)節點的紋理相對於節點位置的位置。
在上述情況下,紋理現在位於節點位置的左下角居中。您不能再依靠標出精靈圖像中心的精靈位置。如果您爲遊戲中的每個節點任意修改anchorPoint,則節點的視覺表示與其位置之間不再有任何關聯。因此修改遊戲對象的anchorPoint是一個糟糕的設計。
此外,旋轉或縮放將始終以anchorPoint爲中心。在旋轉或縮放節點時,修改anchorPoint可能會導致不良行爲。
讓我們假設一個奇怪的,最糟糕的情況,但完全有可能的情形,其中anchorPoint不再紋理內:
._______.
| |
| |
| |
* | |
| |
°-------°
這意味着,精靈的位置遠偏移到實際的左圖像正在顯示。這可能導致碰撞檢查差異,特別是上述情況完全無效基於半徑的碰撞檢查。這在發展過程中也是一個令人困惑的情況。
如果您可以確定精靈的位置始終位於其紋理的中心,而不是某些任何點,而您在沒有某些調試繪圖的幫助下甚至無法看到,則您的遊戲將更容易開發。
問題仍然是:
你什麼時候將要修改的錨點?
我只有在下列情況下這樣做,避免它所有其他情況:
- 對齊非動畫紋理與屏幕/窗口邊框或類似
- 向右/左/上/下對齊標籤,按鈕或圖像以對齊修改的圖像(即藝術家更新)而不修改節點位置。
1)很容易解釋。假設你有一個全屏背景圖像。爲了使其覆蓋整個屏幕,你可以做兩件事情之一:
- 變化的位置:(屏幕寬度/ 2,屏幕 高度/ 2)
- 變化anchorPoint爲(0,0 )又名CGPointZero
你可以想象後者更容易做到。如果你永遠不會移動背景,那很好。但是對於滾動背景我不會改變anchorPoint。
2)假設您的菜單系統要求各種按鈕和圖像與屏幕的右邊緣完全對齊。所有按鈕和圖像的寬度都不相同:即玩遊戲,積分,設置,更酷的遊戲!
而不是找出每個圖像/按鈕的個別位置,通過修改anchorPoint到(1.0f,0.5f),然後將圖像/按鈕精確定位在屏幕寬度(和可變屏幕高度):位置=(屏幕寬度,100)。
讓我們假設以下圖像的位置是在(屏幕寬度,屏幕高度/ 2)具有默認anchorPoint(0.5F,0.5F)。你可以看到圖像的右半部分是屏幕區域外:
__________.
|
.___|___.
| | |
| | |
| * |
| | |
| | |
°---|---°
|
----------°
隨着修改anchorPoint(1.0F,0.5F)的圖像可以是與正確的屏幕/窗口邊框整齊右對齊,無論其紋理的寬度如何。位置保持不變:(屏幕寬度,屏幕高度/ 2)。
__________.
|
._______.
| |
| |
| *
| |
| |
°-------°
|
----------°
只是爲了進行比較,如果你想爲右對齊這個圖像,菜單按鈕,或標籤不修改anchorPoint,你就必須按照這個公式來設置其位置:
(screen width - contentSize.width * anchorPoint.x, screen height/2)
該公式仍然非常簡單,但如果節點的contentSize發生變化(這通常是標籤的情況),則會變得雜亂,例如,分數以1位數開頭,但隨着時間的推移會增加爲2,3和4位數。在這種情況下,通過修改anchorPoint來正確對齊節點是合理的,因爲它避免了每次節點的contentSize發生更改時都不得不重新計算位置。
3)有一些藝術家爲我提供了遊戲對象的更新圖像。圖像大小發生了變化,因此它不再適合遊戲的圖形。另一方面,該對象的位置已經通過遊戲測試已經確立,不應該改變以避免重新測試遊戲。
在這種情況下,調整anchorPoint以使新圖像與其他圖形很好地對齊,而不影響遊戲玩法,這是有保證的。這是一個安全的最後修改。不要在製作階段開始這樣做,否則在整個項目的整個生命週期中,最終都會出現anchorPoint-tweaking-hell。不要去那裏!
總結:
修改anchorPoint只有這使得它更容易地對齊與其他節點或屏幕/窗口邊框節點,或微調最終的藝術,而不會影響遊戲的可玩性。
在所有其他情況下,專門用於移動節點。
假設我正在連接兩條小線,就像這樣_和/或用胳膊胳膊做出一種手臂......以便手臂可以四處移動。所以它看起來像_ /。你認爲設置/ to ccp(0.5f,0.0f)的錨點會導致任何問題嗎?我的意思是它看起來好像它的工作原理......但是你對這個主題有什麼意見:) – Gabe
@Gabe:arm示例很有意義,因爲旋轉以anchorPoint爲中心,所以在這種情況下移動anchorPoint可以讓你獲得在肘關節旋轉。對於更復雜的設計,我會使用CCNode對象作爲肘關節,並將下臂添加到肘關節的偏移處。這使您可以旋轉肘關節併爲您提供更大的靈活性。特別是如果每個肢體都應該進行自己的碰撞測試來添加這樣的「關節節點」。 – LearnCocos2D
除了一個方面的評論,除非你有證據表明人們發佈垃圾郵件或對特定問題沒有答案,否則我們寧願不預先保護問題。我們可以保護他們,一旦他們開始成爲問題,但我們不希望不必要地阻止新用戶回答更老的問題。 –