I get feedback from my users, that "from time to time" my Game-App has a bug were the ship gets completely uncontrollable. After investigating into this, it looks like the attitude, reported by CoreMotion drift away very fast (below a second) and it does that suddenly. You can play for up to five minutes, then it happens suddenly that the ship moves to one of the screen borders and does not move away from that point any more.
My question: Has anybody made the same experience with CoreMotion attitude and what are your ways or ideas to get control over this sudden, massive drifts?
The code I'm using to get the attitude in the update() of SpriteKit is:
if let motion = motionManager.deviceMotion {
let x = CGFloat(motion.attitude.yaw - basePosition.x)
let y = CGFloat(motion.attitude.roll - basePosition.y)
ship.physicsBody?.applyImpulse(CGVectorMake(X_SENSITITVITY * x, Y_SENSITITVITY * y))
}
where basePosition, X_SENSITITVITY, Y_SENSITITVITY are constant values in the game.
motionManager is defined by private var motionManager = CMMotionManager() at the top of the class.
As far as I understand the documentation, deviceMotion uses a combination of gravity and attitude measure to minimise the long term drift somehow.
Maybe also important to notice: When the Game runs in a silent environment without the vibrations of cars etc, it works perfectly fine.
I would like to have people to play my game whenever they need a rest - like on long train rides or flights - or kids in the backseat of the car.
I figured out the same drift problem. I compared the CMDeviceMotion's attitude with the CLLocation's magneticHeading. Therefor, I walked 10 times around a small table and put the device after every round on the exact same place.
I figured out, that the DeviceMotion's attitude drifts around 30 degrees every round. Thus, after 10 rounds the attitude is around 300 degrees off.
According to Apple's WWDC 2012 talk "Session 524: Understanding core motion" the used sensor fusion depends on the specified reference frame. Phil Adam mentions, that the sensor fusion algorithm also uses the magnetometer if the xArbitraryCorrected reference frame is specified. I did the same test with xArbitrary, xArbitraryCorrected and xMagneticNorth, but there is no difference. The compass's uncertainty is around 2 - 3 degree (with a heading filter of 1.0 degree).
Maybe it's a bug, I don't know. But I expected at least a difference between xArbitrary and xArbitraryCorrected.
ok, I've found a way to handle this. And as I see a number of views on this question there might be some interest in the answer and some people dealing with the same issue.
From my understanding, there're two things you can rely on:
The change of devices in motion. Specifically CMDeviceMotion.rotationRate
The attitude of a device towards earth. Specifically CMDeviceMotion.gravity
It looks like the first uses changes in current position by reading some kind of current forces. This is a current value and there's no need to sum up the values - and therefore no errors are summed up.
The second one (gravity) measures the current forces against earth. Again: current values, no sum up, no sum up of errors, no drift.
Anything else, especially CMDeviceMotion.attitude, takes measures and adds them up. Leading to adding up the small errors in each measure, leading to a drift in the result.
I've tried to use rotation rate and calculate the attitude myself by adding up. Well, Apple is not perfect in doing that, but way better then any of my solutions :-)
Talk is cheap. Where's the code? Here it is. This method is called during update() in SpriteKit (for every frame)
private func update(ship: SKSpriteNode) {
// Orientation can be landscape left or right
let orientation = UIApplication.sharedApplication().statusBarOrientation == UIInterfaceOrientation.LandscapeLeft ? -1.0 : 1.0
// Get rotation rate
let x = orientation*motionManager.deviceMotion.rotationRate.x
let y = orientation*motionManager.deviceMotion.rotationRate.y
// If user tilts device very slow it does not affect the ship
let xf = CGFloat(abs(x) >= X_RESPONSIVNESS ? X_SENSITITVITY*x : 0.0)
let yf = CGFloat(abs(y) >= Y_RESPONSIVNESS ? Y_SENSITITVITY*y : 0.0)
// Apply as impulse
ship.physicsBody?.applyImpulse(CGVectorMake(xf, yf))
}
As my game is more about "how does the user tilt the device to let me know where you want the ship go to" I simply used rotationRate to measure this and apply it as impulse. As an add-on you can rotate the device which means that what was a rotation towards the top of the screen is actually a rotation to the bottom after rotation. So I have to invert the impulse when the device is rotated.
You can now play the game in any direction. Landscape left, Landscape right, overhead, in a vibrating environment like cars or trains. It works like a charm. I'm even looking forward to a 2.5 hours flight next Saturday...
Related
I built a complete structure as a node (with its child nodes) and the user will walk through it using ARKit.
At some point, if the user cannot continue because of some real obstacle in the real world, I added a "pause" button which should freeze whatever the user currently sees in front of the camera, the user could then move freely to some other open space and when the user will release the pause button he/she will be able to resume where they left off (only someplace else in the real world).
A while ago I asked about it in the Apple Developer forum and an Apple Frameworks Engineer gave the following reply:
For "freezing" the scene, you could transform the anchor's position (in world coordinates) to camera coordinates, and then anchor your content to the camera. This will give you the effect that the scene is "frozen", i.e., does not move relative to the camera.
I'm currently not using an anchor because I don't necessarily need to find a flat surface. Rather, my node is placed at a certain position relative to where we start at (0,0,0).
My question is how do I exactly do what the Apple engineer told me to do?
I have the following code which I'm still stuck with. When I add the node to the camera (pointOfView, last line of the code below), it does freeze in place, but I can't get it to freeze in the same position and orientation as it was before it was frozen.
#IBAction func pauseButtonClicked(_ sender: UIButton) {
let currentPosition = sceneView.pointOfView?.position
let currentEulerAngles = sceneView.pointOfView?.eulerAngles
var internalNodeTraversal = lastNodeRootPosition - currentPosition! // for now, lastNodeRootPosition is (0,0,0)
internalNodeTraversal.y = lastNodeRootPosition.y + 20 // just so it’s positioned a little higher in front of the camera
myNode?.removeFromParentNode() // remove the node from the Real World view. Looks like this line has no effect and just adding the node as a child to the camera (pointOfView) is enough, but it feels more right to do this anyway.
myNode?.position = internalNodeTraversal // the whole node is moved respectively in the opposite direction from the root to where I’m standing to reposition the camera in my current position inside the node
// myNode?.eulerAngles = (currentEulerAngles! * -1) — this code put the whole node in weird positions so I removed it
myNode?.eulerAngles.y = currentEulerAngles!.y * -1 // opposite orientation of the node so the camera will be oriented in the same direction
myNode?.eulerAngles.x = 0.3 // just tilting it up a little bit to have a better view, more similar to the view as before it was locked to the camera
// I don’t think I need to change the eulerAngles.z
myNode!.convertPosition(internalNodeTraversal, to: sceneView.pointOfView) // I’m not sure I wrote this correctly. Also, this line doesn’t seem tp change anything
sceneView.pointOfView?.addChildNode(myNode!) // attaching the node to the camera so it will remain stuck while the user moves around until the button is released
}
So I first calculate where in the node I'm currently standing and then I change the position of the node in the opposite direction so that the camera will now be in that position. That seems to be correct.
Now I need to change the orientation of the node so that it will point in the right direction and here things get funky. I've been trying so many things for days now.
I use the eulerAngles for the orientation. If I set the whole vector multiplied by -1, it would show weird orientations. I ended up only using the eulerAngles.y which is the left/right orientation and I hardcoded the x orientation (up/down).
Ultimately what I have in the code above is the closest that I was able to get. If I'm pointing straight, the freeze will be correct. If I turn just a little bit, the freeze will be pretty close as well. Almost the same as what the user saw before the freeze. But the more I turn, the more the frozen image is off and more slanted. At some point (say I turn 50 or 60 degrees to the side) the whole node is off the camera and cannot be seen.
Somehow I have a feeling that there must be an easier and more correct way to achieve the above.
The Apple engineer wrote to "transform the anchor's position (in world coordinates) to camera coordinates". For that reason I added the "convertPosition" function in my code, but a) I'm not sure I used it correctly and b) it doesn't seem to change anything in my code if I have that line or not.
What am I doing wrong?
Any help would be very much appreciated.
Thanks!
I found the solution!
Actually, the problem I had was not even described as I didn't think it was relevant. I built the AR nodes 2 meters in front of the origin (-2 for the z-coordinate) while the center of my node was still at the origin. So when I changed the rotation or eulerAngles, it rotated around the origin so my nodes moved in a large curve and in fact also changed their position as a result.
The solution was to use a simdPivot. Instead of changing the position and rotation of the node itself, I created a translation matrix and a rotation matrix which was at the point of the camera (where the user is standing) and I then multiplied both matrices. Now when I added the node as a child of the camera (pointOfView) this would freeze the image and in effect show exactly what the user was seeing before it was frozen as the position is the same and the rotation is exactly around the user's standing position.
I'm fairly new to swift, and have been working on a game for fun, and i'm running into something I can't quite get my head around.
When the run button is pressed, the character moves forward with the following function
func move(dt: CGFloat) {
position.x += moveRate * dt
}
And when the jump button is pressed, the character jumps with the following function
func jump() {
physicsBody?.applyImpulse(CGVector(dx: 0, dy: jumpRate))
run(jumpAnimation!)
}
both work fine, but consider this senario. The player is running, and then they jump while still moving. While in the air, the player releases the move button and the player's x position stops dead. This obviously feels very unnatural, and i would like the player's x position to ease out.
Now i have also played with moving the character with physicsBody?.applyForce(CGVector(dx: 1000, dy: 0)) which would give that effect, but he seems to just gain more and more speed and you don't get a constant rate or "max speed" so to speak.
Could anybody share some insight with me? I'd love to learn anything I can about spritekit and game development in general. Thanks!
You should try to set the velocity instead of setting the X position. When setting the position you bypass all the physics behaviors.
You should also try to set it only when you actually press a button.
func move(dt: CGFloat) {
if Math.abs(moveRate) > 0.1 { // If player initiates movement. You can increase the value 0.1 if you want to filter move values
velocity = CGVector(dx: moveRate, dy: veloxity.dy)
}
}
It your character moves indefinitely like in space, linearDamping will be useful. it's used to simulate air friction, so values closer to 1 means more friction and values closer to 0 means less friction.
linearDamping = 0.85
Also, this way, moveRate isn't dt dependent but it should be lowered.
Try it, I haven't tested it yet, but that's basically how I would do it.
There are two schools of thought on platformer game "physics".
Don't use physics, do everything with positional incrementation.
Do everything with physics, since positional changes mess up physics
Since you're using physics for jumping, and physics jumping is fun:
There are three ways to create movement in a physics system:
Set the velocity as and when required. This is what Crazyrems is suggesting
Apply impulses as needed to increase and decrease rates of movement
Apply forces over time that increase or decrease rates of movement
Use fields to induce motion (too complex for this, and messy, but fun)
What you're attempting, with your physicsBody?.applyForce(CGVector(dx: 1000, dy: 0)) is the application of force over time. Number 3 in the list above. The longer you continue applying this force the faster the character moves.
Each of these techniques can be made to work, but they all need compensation for their various limitations and methodologies of simulation.
In the case of your approach, you need monitor speed and to set a maximum speed. Having reached maximum speed, if the player is still holding the button, only provide enough force to maintain speed (assuming you're using some form of constant resistance to slow the character).
Monitoring speed combined with force-over-time creates interesting acceleration trait possibilities - like very strong initial acceleration and then taper off acceleration as the player nears their maximum speed.
Slowing down when the player releases the button is the next focus. In all these approaches you need something that slows the player. This can be the application of opposing forces, or the use of friction or damping, as provided by the physics engine.
I am working on a small education demo which should measure height and width of the object using iOS camera.
EDIT:
I have a new theory to measure the width of an object.
In above image, if i can get Angle α and Angle ß, i can get width of the unknown side by using trigonometry formulas. I have the values of b1 and b2 already.
OLD:
Right now, i am focusing on measuring length only.
As per my knowledge it should be 3 step process.
User snaps one end of the object.
User snaps other end of the object.
User snaps center of the object. (Suggest me a better way for these please)
I get the approximate measurements using above process, but for the 3rd step, in which user snaps the center of the object. I want to show pointer location on screen (as camera overlay) to help user determine the center of the object.
This is how i am doing it right now.
How can i draw pointer location for 3rd step?
Note: Please suggest alternative/best way to make it possible. I would love another suggestions. Thanks.!!
First of all I must appreciate your work you have done till now. Another good thing is the way of explaining, salute!!!!!
After reading of your question, I feel that you dont need code, you can do it. I think you need direction only.
As per your explanation, you want to record angle of rotation of the device.
If you want to measure angle of rotation, you have to use compas readings. But compas readings will change if user tild the device. So you have to use accelerometer to measure tilding of device.
In short you have to make some combination and equation of both compas and accelerometer readings. Use compas to measure angle and use accelerometer to measure tilding of device.
If you want further information to implement it, you can ask me.
Hope this will help you....
I am working on a iOS Game Application (Race) which requires the background to have transition coming forward.
For the above requirement I have written a code where I have to make people feel as if the objects were coming from a far distance to nearby.
Hence I am using transition to do so where I increase their y position and scaling (both xScale and yScale). While doing so, the problem I am facing is when the objects seem to come closer with their size increasing (using scaling), the distance between the objects decreases from their actual distance because of scaling and it does not perfectly look as if the objects were coming from far behind.
Please let me know what is the best way to achieve what I trying to do or else if there is any available sample code having the functionality of car/bike racing.
transition.to ( object,{ time=500, alpha=1,x = (destination x coor),y = (destination y coor),width =(to scale x),height =( to scale y), onComplete=saltCellarOnComplete} )
I have tried many different techniques of applying a realistic looking gravity feature in my game but have had no luck so far. I plan on offering a 100 point bounty on this for someone who can show me or (share) some code that applies gravity to a CCSprite in Cocos2D.
What I have done so far has just been ugly or unrealistic and I have asked in many different places on what the best approach is but I just have not found any good looking gravity techniques yet.
Anyway, can anyone offer some tips/ideas or their approach only applying gravity to a CCSprite in Cocos2D without using a physics engine?
Thanks!
A effective approach without having to explicitly use any physics engine is to step the velocity and position of your sprite manually in your update loop. This is essentially Euler Integration.
// define your gravity value
#define GRAVITY -0.1
// define a velocity variable in the header of your Game class/CCSprite Subclass (neater)
float velocity_y;
-(void) update: (ccTime) dt
{
// Step the y-velocity by your acceleration value (gravity value in this case)
velocity_y += GRAVITY *dt; // drop the dt if you don't want to use it
// Step the position values and update the sprite position accordingly
sprite.position.y += velocity_y* dt; // same here
}
In the code snippet above, I defined a velocity_y variable to keep track of my sprite's current velocity along the y-direction. Remember to initialize this value to 0 in your init method.
Next comes the crux of Euler. At every time step:
Advance your velocity by your acceleration (which is your gravity) multiplied by dt to find your new velocity.
Advance your position by your newly computed velocity value multiplied by dt to find your new position.
You can experiment whether using delta-time or not (see LearnCocos2D's excellent comment on the cons of using it) works for your game. While multiplying by delta-time allows your object motion to more accurately take into account varying framerates, as LearnCocos2d pointed out, it might be wise to avoid using it in a real-time game where system interrupts (new mail, low battery, ads pop-out) can occur and subsequently cause the game simulation to jump forward in an attempt to make up.
So if you are dropping the dt, remember to tweak (scale down) your GRAVITY value accordingly to retain the right feel, since this value is no longer multiplied by the value of delta-time (which is ~ 1/60).
Aditional Tip: To apply an impulse to move the sprite (say via a swipe), you can affect the velocities directly by changing the values of velocity_x (if you have this) and velocity_y.
I have used this approach in my games, and it works very well. hope it helps.
This isn't trivial matter, you should try to see other posts. I'm sure other poeple already had this issue. Try to look at :
How to simulate a gravity for one sprite in cocos2d without a physics engine?
Cocos2D Gravity?
Or try our good friend google :
http://www.gamedev.net/page/resources/ -> got to Math and Physics and then A Verlet based approach for 2D game physics
http://www.rodedev.com/tutorials/gamephysics/
In any case here are some tips :
Step 1, calculate the effective direction vectors
Step 2, calculate velocity
Step 3, project this velocity onto the two effective directions.
Step 4, generate an equal and opposite force for the two direction and call this the “response force”.