I'm trying to grasp the conversion thing in SpriteKit but despite having read the documentation and several posts on SO I can't seem to get it right. As far as I understand there are two coordinate systems that work independently of one another, one for the scene and one for the view, which is why I simply can't use the things like UIScreen.main.bounds.maxX to determine screen corners that the node can relate to. Am I getting this right?
Anyway, here's my attempt at converting coordinates:
let mySquare = SKShapeNode(rectOf: CGSize(width: 50, height: 50))
mySquare.fillColor = SKColor.blue
mySquare.lineWidth = 1
let myPoint = CGPoint(x: 200, y: 0)
let newPosition = mySquare.convert(myPoint, from: self)
mySquare.position = newPosition
print(newPosition)
self.addChild(mySquare)
The print returns the exact same position as went in so obviously I'm not doing this right, but I have tried a number of different constellations but with pretty much no result; the coordinates remain the same. I have also tried let myPoint = CGPoint(x: UIScreen.main.bounds.maxX, y: UIScreen.main.bounds.maxY) but same there; no conversion.
What am I missing? In my head I read the conversion above as "convert myPoint from the view coordinate system and use it for my node mySquare.
There are lots of coordinate systems floating around, and so lots of potential sources of confusion:
Scene coordinates: that's your game's world, and what you usually think about when imagining coordinates and how to position things overall.
Node: Nodes have their own coordinate system. Once you start building a hierarchy, that matters. Imagine, e.g., an on-screen joystick that has a background showing a graphic of movement directions and a central "knob" that the player can manipulate. You might represent the joystick as a node with two children. One child is a sprite for the background, and the other is a sprite for the knob. The background sprite would naturally be at position (0,0), meaning the center of the overall joystick. The knob would move around, with (0,0) meaning centered and maybe (0,100) meaning up a bit. The overall joystick might sit at (200,300) in the scene. Then the background sprite would show up at (200,300) in the scene and the knob, when up, would be at (200,300)+(0,100) = (200,400) in the scene. The convert(from:) and convert(to:) are for converting within the node hierarchy. You could ask where the knob is in the overall scene's coordinates by knob.convert(.zero, to: scene) or joystick.convert(knob.position, to: scene). You very rarely need to do that sort of conversion.
View coordinates: The view is a window on the scene, i.e., what's actually being shown. If you've got a full screen game, the view is basically determined by the screen size in points. How view coordinates map to scene coordinates determines what part of the scene you actually see. If you need to go between view coordinates and scene coordinates, you use the scene's convertPoint(fromView:) and convertPoint(toView:) methods.
If you don't do anything special and have the scene size the same as the view size, then the scene-view mapping will have (0,0) in the scene at the lower left corner of the view. Another common convention is to have (0,0) in the scene at the center of the screen by setting the scene's anchorPoint to (0.5,0.5). Or perhaps you've designed the scene so that the world is 2000x2000 in size and there will be a nontrivial scaling and possible letter-boxing or cropping involved (depending on the setting of the scene's scaleMode). Or if your game has a camera node and, e.g., the camera is set to follow the player around, then the view-to-scene mapping will be changing as the player moves.
In your code, calling mySquare.convert(from:) doesn't really even make sense since the square hasn't been added to the scene at the time you're doing the "conversion".
Anyway, if you really want to do something like "put a square in the top-left corner of the screen", then you can take the point in the view's frame and convert it to scene coordinates and set the square's position to that.
override func didMove(to view: SKView) {
...
mySquare.position = convertPoint(fromView: CGPoint(x: view.frame.minX, y: view.frame.minY))
addChild(mySquare)
...
}
Edit: I would encourage you though to think mostly in terms of the overall scene, after some initial consideration of how the game should map to devices with screens of different sizes and aspect ratios. Once you're thinking in terms of the scene, then the scene's frame (rather than the view's frame) becomes the most natural reference when you're imagining "at the left edge" or "near the bottom right".
Related
I am making this basic space shooting game but I can't get the x-coordinates of enemies right. Sometimes, they go out of the screen - or remain half inside at the edges. How can I fix this permanently regardless of which iPhone the app runs on?
here is the code for my positioning: (note that egg is name of my enemy. it is function I made for calling it every single time)
func egg() {
var egg = SKSpriteNode(imageNamed: list[Int(arc4random_uniform(6))])
var min = self.size.width / 8
var max = self.size.width
var point = UInt32(max - min)
egg.position = CGPoint(x: CGFloat(arc4random_uniform(point)), y: self.size.height)
let action = SKAction.moveToY(-100, duration: 2)
let actionDone = SKAction.removeFromParent()
egg.runAction(SKAction.sequence([action, actionDone]))
}
There are several places where things can be going sideways.
• First, it looks like you're assuming the location of your scene's anchorPoint is at (0,0). If it's not (the default .sks file now has an anchorPoint at (0.5,0.5), for instance), that could explain why your enemies never show up. The first thing I would do is double-check the anchorPoint of my scene.
• If you're adding these eggs to some other node besides the scene itself, then those eggs will "inherit" whatever translation, rotation, and scale that their parent node has. In other words, if you add an egg at (20,20) to a node at (30,30), it will appear at (50,50). Make sure the "context" of the eggs is what you expect.
• Your "min" and "max" values seem a little odd. The "min" looks like it is intended to be "indented" by 1/8th of the screen size on the left, but you aren't indenting it on the right. Maybe that's what you intend, but if you intend them to have symmetrical behavior, then you'll want to back "max" off by an eighth, too. Also, you're not adding that eighth back into the x value when you're determining the position, so this could stick an egg at x=0. This would explain why your sprites are sometimes "half inside at the edge".
• The size of your scene is not necessarily the screen dimensions. This depends heavily on the "scaleMode" of your SKScene. Check the documentation for more information on this, but briefly, the scaleMode tells SpriteKit how to render a scene that doesn't match its view in size or aspect ratio. Does it stretch? Does it crop? Does it letterbox? If you run a square 400x400 scene on a 1024x768 screen device, it has to have some way of knowing what you mean. Does it draw that 400x400 in the middle of the screen and let stuff be seen "outside" that rect? Or does it scale it up to fill the screen, cropping off the top and bottom? Or does it scale it up to FIT the screen, allowing space above and below that is technically outside the scene's size? Or does it scale it up and squash the scene to fit exactly? If your scene isn't matching up exactly with your device's screen, this could explain why things are not playing nice and staying within visible bounds.
I am able to add twenty small spheres of, say, radius 0.5 to my scene.
However, when I attempt to only add one sphere, no matter what radius I specify, the sphere appears with the default radius of 1.0.
Here is the code that I'm using to add just one sphere. I merely put this code inside a for loop to add twenty spheres -- which works just fine.
func drawSpheres() {
var x:Float = 0.0
var radius:CGFloat = 0.5
let sphereGeometry = SCNSphere(radius: radius)
let sphereNode = SCNNode(geometry: sphereGeometry)
sphereNode.position = SCNVector3(x: x, y: 0.0, z: 0.0)
self.rootNode.addChildNode(sphereNode)
}
Am I missing something obvious?
The problem that you are seeing is just Scene Kit trying to be smart. Everything is actually working as expected.
To be able to render your scene, Scene Kit needs a camera to be the point of view. If your scene contains a camera, that will automatically be made the point of view. But if your scene doesn't have a camera in it, Scene Kit has to create its own (or fail to render all together, which would be less preferable). When Scene Kit creates its own "default" point of view, it tries to adapt to the content of the scene so that it fills the view as best as possible (a slight simplification).
This can be a nice little convenience, but in your case it means that when you make your sphere larger, Scene Kit adapts its point of view so that the sphere still covers the entire view. If there is only one sphere in the scene, this means that you can't see any difference in the radius of the sphere because it will always cover the entire view.
If you add your own camera to the scene and configure it to your liking, you will be able to see the difference when changing the radius of the sphere.
This seems to be a major oversight by Apple, but since SKPhysicsJoints have their anchor points set in Scene coordinates, this makes doing any kind of scrolling game impossible.
To simulate a camera in SpriteKit you create a WorldNode which contains all of the gameplay elements, and then pan that around the scene. Unfortunately, doing this causes the Scene coordinates of every object in the game to change on every frame as you pan the world around. In turn, this breaks the joint anchor points, and things go berserk.
There isn't even a way to change the joint's anchor point, so I don't even have a way of just updating the coordinate every frame. It would seem that using SKPhysicsJoint in a scrolling game is not an option.
Does anyone know of a way around this?
Ok, I think I figured out what was going on, and I was totally incorrect in my original assumption. The reason my anchor points looked incorrect is because the [convertPoint toNode] call was returning me Scene coordinates that were incorrect. After several hours I realized it was off by exactly half the screen dimensions. My Scene has an anchorPoint of (0.5, 0.5), but this screws up the conversion values. So, if I simply offset the point by width/2, height/2 it's correct:
GPoint pt = CGPointMake(anchorWorldX, anchorWorldY);
pt = [gGameScene convertPoint:pt fromNode:gGameWorld]; // convert to scene coords, but it's WRONG
pt.x += scene.size.width * scene.anchorPoint.x; // this properly adjusts the value to be correct
pt.y += scene.size.height * scene.anchorPoint.y;
SKPhysicsJointPin* pin =[SKPhysicsJointPin jointWithBodyA:hinge.physicsBody bodyB:door.physicsBody anchor:pt];
What are the coordinates for the bottom of the screen... or how can I create a "floor" at the bottom of the screen in spritekit?
Sorry, but I don't understand screen coordinates that well in spritekit.
You need to understand the Sprite Kit coordinate system as explained in Apple's Documentation here.
Here's how you create a floor at the bottom of the screen in SpriteKit:
SKNode *floor = [SKNode node];
node.physicsBody = [SKPhysicsBody bodyWithEdgeLoopFromRect:CGRectMake(CGRectGetMidX(self.frame),1.0 , CGRectGetWidth(self.frame), 1)];
[self addChild: floor];
You need some universal approach to get coordinates of corners on the screen.
Using code from that answer you can get CGRect with necessary information.
Example:
let screenRect = getVisibleScreen(
sceneRect: self.scene!.frame,
viewRect: self.view!.frame )
And then you can use it:
screenRect.minX
screenRect.maxX
screenRect.minY
screenRect.maxY
screenRect.width
screenRect.height
This is more then enough to calculate coordinates of "floor" or any other relative positions.
The location of the bottom of the screen will depend on what coordinate system you are using for your scene.
Out of the box, the bottom of the screen will be at y coordinate zero, but there are a few things that can happen that will affect that.
For instance, if you are using the scene editor in xCode, and your scene's anchorPoint property is something other than y=0, then the "origin" of your scene will not be at the bottom of the screen. In the recent xCode beta, they changed the default behavior to have the scene's origin at the center of the scene instead of the lower left corner, so that would explain why you might be seeing things in the center of the screen when you expect them to be at the bottom.
Also, the "bottom of the screen" will be relative to whatever parenting structure you have in your scene. For instance, if you place a background sprite in your scene, and want to attach a floor sprite to that which is at the bottom of the screen, you'll have to do some computing to figure out where to place it because you are going to inherit the translation and rotation of the floor's parent node (and any parents that node has).
To keep things simple, you can just place everything directly on the stage and manage their z-order manually. This will let you, basically, use the same coordinate system for everything. This is often fine; as long as you're not trying to do anything complex with your sprites, you don't need a complicated "tree" of nodes.
But even with this approach, the metrics of your scene are going to have to be handled dynamically. The width and height of your scene are going to depend on how you approach displaying your scene on different devices with different sizes. For instance, the top right of an iPhone 4 is going to be in a different place than the top right of an iPad Pro. A full discussion of how to deal with that is beyond the scope of your question, but generally, you'll probably want to use a "reference width" or a "reference height" for your scene, use .AspectFit or .AspectFill for the scaleMode, and set your scene's size accordingly. (I.e., inspect the view's frame to get the actual aspect ratio of your scene and set your scene size to match your reference metric on one axis and scale the other axis to match the device's aspect ratio.) This will let you use the same metrics for all devices (although one of your two axes will be fluid).
I am developing an iPhone application that uses Cocos3d. I have drawn a scene in the XZ plane ( y = 0 ). Now, I want to rotate the scene around a specified point in the XZ plane, whenever the user touches the screen with two fingers; the rotation point will be the center of the two touch points.
I started by projecting the two touch points to the 3D scene, by finding the intersecting between the CC3Ray (issued from the camera and passing by the touch point) and the XZ plane.
Now that I have the two points in the XZ plane, I can calculate the rotation point (that will be the middle point between these two points).
In order to rotate the scene around this point, I have added it to a parent node. Now all I have to do is to translate it by the negation of the coordinates of the middle point, rotate its parent by the angle, and translate it back by the coordinates of middle point.
Here is the code that I am using (in the ccTouchesMoved method):
// Assuming that the root is a CC3Node and it is the scene that I need to rotate
// and middle refers to the center of rotation
[root translateBy:cc3v(-middle.x, 0, -middle.z)];
[root.parent rotateByAngle:30 aroundAxis:cc3v(0, 1, 0)];
[root translateBy:cc3v(middle.x, 0, middle.z)];
However, I am not able to rotate the scene around the middle point.
Can anyone help me to resolve this problem?
Thank you!
Edit:
I also tried to add these lines of codes in the ccTouchesBegan method:
[root translateBy:CC3VectorNegate(middle)];
[self.cc3Scene.activeCamera translateBy:CC3VectorNegate(middle)];
And in the ccTouchesMoved:
[root rotateByAngle:angle aroundAxis:cc3v(0, 1, 0)];
It works only for the first time the user touches the screen, and then, whenever he/she touches it again, a unwanted translation is happening!
I think the problem is with the ccTouchesBegan method.
On any one node, rotation, translation, and scale transforms are independent of each other. They are each applied to the rest pose of the node, and are not accummulative with each other. This is so that interaction appears natural and expected by the developer controlling the node. In other words, during gameplay, rotating a character after it has been moved, rotates the character in place, not around a translated location. Similarly, translating a node translates it regardless of how the node has previously been rotated.
This is different control than taking a single matrix and accumulating transforms into it, which is how the matrix-based rotate-around-a-distant-point technique works.
However, you can effectively rotate a node around a location that is not its origin by:
Transforming the local rotation location to the global coordinate space.
Rotating the node as normal.
Transforming the (now rotated) local rotation location to the global coordinate space.
Align the rotation locations found in steps 1 & 3 by translating the node by the difference between the two locations.
You can perform steps 1 & 3 using the node's globalTransformMatrix. Code for the steps above is as follows:
CC3Vector gblRotLocBefore = [aNode.globalTransformMatrix transformLocation: rotationLoc];
[aNode rotateByAngle: angle aroundAxis: kCC3VectorUnitYPositive];
CC3Vector gblRotLocAfter = [aNode.globalTransformMatrix transformLocation: rotationLoc];
[aNode translateBy: CC3VectorDifference(gblRotLocBefore, gblRotLocAfter)];
Using this technique, you do not need to involve the node's parent.