Anchor points and TouchesMoved explanation?

Question

I am using the newest Xcode with Swift and SpriteKit.

In my GameviewController in viewDidLoad() I set the scene Anchor point to the middle.

scene.anchorPoint = CGPoint(x: 0.5, y: 0.5)

And I slapped a chessboard down in the center for all the devices.

Then for the individual squares I set the anchor point at 0,0. This makes setting up the squares programatically a snap! I wont go into a boring math explanation. But by centering the board and then dividing an individual squaresize by 8 you can quickly set up all the squares universally. It works.

A1.anchorPoint = CGPoint(x: 0,y: 0)

So I did all this.

And set up the touch etc... but the when I picked up a chess piece and dropped it on a square, it was off by a small amount. The piece wouldn't drop on the left of the square and had an extended area on the right.

And this is what I don't understand.

And if anyone actually read all this, thanks. I am boring myself here... LOL.

But after two days of thinking, cursing Apple and it 'faulty' Xcode, and 'faulty' Swift, and broken touch on its iPads, I realized all I had to do was reset the anchorpoint to (x: 0.5, y: 0.5) in Touches Moved. After I moved the piece, I had to then change its anchor point it mid flight.

Now it drops directly into the square as it should.

But why?

Why would changing the ANCHOR POINT of a sprite during 'mid-pan' affect where the touches ended calculates its drop?

I just want to know.... If anyone read all this again thanks. I am so happy I figured it out. I was about to scrap the whole chess game, and all its subsequent sequels, and all my dreams were lost... LOL. But anyway, best of luck. And if anyone has an answer do tell.

SpriteKit

1.2k

Posted by

pianosmooth

Reply

Add a Comment

Answer 1

With this explanation, the behavior seems explicable: it was doing exactly what you asked it to do.

Changing the anchor point of a scene is basically changing the coordinate system, like changing the bounds origin for a view.

Changing the anchor point of a SKSpriteNode is nothing like changing the anchor point of a scene. Instead, it has the effect of moving the pixels belonging to the sprite's text up and to the right, by half the size of the texture, relative to the (x, y) position of the node. That means, when you pick the node up, its texture will not be squarely under your finger tip — unless you do extra work during the touch tracking to adjust its position to put the pixels back where they really ought to be. That's doable, but it tends to a brain teaser to figure out exactly what to offset and by how much (…"after two days of thinking, cursing Apple and it 'faulty' Xcode"…).

Given that a chessboard and pieces have a prior expectation of appearance (pieces centered in the squares), it would probably have been a better choice not to set the sprite node anchor points to (0, 0) — for either the squares or the pieces — but rather to deal with the less-puzzling complexity of offsetting the positions of the squares when you first created them. "[Y]ou can quickly set up all the squares universally" is good, but the consequences might not have been worth the benefit.

Posted by

QuinceyMorris

Add a Comment

Answer 2

With this explanation, the behavior seems explicable: it was doing exactly what you asked it to do.

Changing the anchor point of a scene is basically changing the coordinate system, like changing the bounds origin for a view.

Changing the anchor point of a SKSpriteNode is nothing like changing the anchor point of a scene. Instead, it has the effect of moving the pixels belonging to the sprite's text up and to the right, by half the size of the texture, relative to the (x, y) position of the node. That means, when you pick the node up, its texture will not be squarely under your finger tip — unless you do extra work during the touch tracking to adjust its position to put the pixels back where they really ought to be. That's doable, but it tends to a brain teaser to figure out exactly what to offset and by how much (…"after two days of thinking, cursing Apple and it 'faulty' Xcode"…).

Given that a chessboard and pieces have a prior expectation of appearance (pieces centered in the squares), it would probably have been a better choice not to set the sprite node anchor points to (0, 0) — for either the squares or the pieces — but rather to deal with the less-puzzling complexity of offsetting the positions of the squares when you first created them. "[Y]ou can quickly set up all the squares universally" is good, but the consequences might not have been worth the benefit.

Posted by

QuinceyMorris

Add a Comment

Answer 3

Actually, I found this 'nerdy interesting'

But for an even number of squares (chess board has eight ) it is beneficial to have the chessboard graphic set at anchor point 0.5 0.5 and the squares at 0.0 0.0 and then change the anchor point to 0.5 0.5 before touches ended.

And for an odd number of squares -- say a sudoku board (9 squares) you should keep the anchor point at 0.5 when setting up both the grid and the squares.

Universally, you can do this amazingly fast. 30 minutes to set up a completely touchable universal any size grid.

This lends itself to lots of different puzzle games.

Setting up a universal touchable grid, where each square can be touched and recgonized, is one of the more tedious and important things to do programatically. And by adjusting the anchor points you can quickly do 'even grids' 4 x 4 8 x 8 etc. And by keeping the anchor point set in the middle 0.5 you can do all the odd ones 3 x 3 9 x 9 etc.

Posted by

pianosmooth

Add a Comment

Anchor points and TouchesMoved explanation?

Accepted Reply

Replies