I am creating a 2D game. The view is from directly above my character, with him being stationary in the middle of the screen and the world moving (and rotating) around him. I do this by calling D3DXMatrixTransformation2D and putting in the (constant) position of my character and the rotation of him.
That works pretty well for my character and the background. For the bullets and enemies, even though it works, it's not what I want. I want the enemies to rotate on their own axis along with the overall axis of my character. Currently, when I rotate 180 degrees, the enemy is upside down, in the same manner as the background. That's ok, but I want him the ability to turn around to shoot me (that, or rotate the same degree so that we are always facing up; I haven't decided yet, but I believe it's the same problem).
The bullets are the same story. My first bullet design was a long skinny energy type beam. No matter in which direction I shot it, it would always face "north", even though it was heading in a different (correct) direction. I sidestepped this problem for now by creating a round bullet, but it doesn't solve the real problem.
So is there anyway to call D3DXMatrixTransformation2D twice? I've tried doing that with one matrix and one SetTransform() call, two matricies and two SetTransform() calls, and with one matrix and two SetTransform() calls, but it either doesn't change anything, or it makes the bullet/enemy texture the rotation center and doesn't recognize my rotation. I can provide some code if needed, but there's nothing much to the code that's giving me this problem. Thank you!
EDIT: Here's the code I have now, but it seems to work the same way as before:
D3DXVECTOR2* center = new D3DXVECTOR2(position.x,position.y);
D3DXMatrixTransformation2D(&mat,NULL,0.0,NULL, center, this->rotation,NULL);
sprite->SetTransform(&this->mat);
D3DXMatrixTransformation2D(&this->mat, NULL, NULL, NULL, &this->spriteCenter, *player::getInstance()->getRotation(), NULL);
sprite->SetTransform(&this->mat);
sprite->Draw(bullet, NULL, NULL, &this->position, 0xFFFFFFFF);
The "position" variable is a D3DXVECTOR3 variable that is the screen posiiton of the current bullet object. The "this->rotation" is the rotation of the bullet. The spriteCenter variable is the position of the center of the player texture, which is (408, 316, 0).
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.
Note: I have tried this answer: Gap between SKSpriteNodes in SpriteKit collision detection
I am getting gaps in between my SKSpriteNodes, after 5 minutes of letting my game run. Here is my code to make the node:
let tileNode = SKSpriteNode(imageNamed: "world1Tile\(tileNumber).png")
tileNode.position.x = x
tileNode.position.y = y
tileNode.size.width = 128
tileNode.size.height = 128
tileNode.zPosition = 10
tileNode.physicsBody = SKPhysicsBody(rectangleOf: tileNode.size)
tileNode.physicsBody!.isDynamic = false
tileNode.physicsBody!.restitution = 0
tileNode.physicsBody!.allowsRotation = false
tileNode.name = "Tile"
row.append(tileNode)
When I remove the physics body, it is running fine. Here is are some images to show you what I mean:
This image has a physics body, and was taken after immediately after running the app.
This image was taken 5 minutes after running the app.
Why is this happening? I assume it has something to do with the physics body, because my app looks exactly like the first picture, even an hour after running the app if there is no physics body. What physics body property should I change to stop this from happening? Any help would be appreciated.
I had a similar issue not too long ago, where gaps were appearing between nodes that were tiled (although I didn't use physics). Based on this answer, I found that if you want perfect alignment between nodes, it is best to ensure that the positions of nodes as well as the nodes' width and height are whole numbers.
I would suggest to round-off the x and y values of the position of tileNode and see if it will make any difference .
I'm guessing there is no gap. you probably have 'showPhysics' to true in your gameviewcontroller, and the line appears as a gap to me.
compare position with and without the pb to verify.
I had similar problem where gaps between sprites started appearing after around 5 minutes of scrolling with constant speed (game with infinite scroll). I did not use physics and I even had all positions, widths, heights rounded to integer value. I was scrolling the camera and adding new sprites one right after another and everything was working fine except after around 5 minutes of that infinite scrolling gaps begin to appear just as in your case. I spent some time in looking for a solution and it turned out that the problem was that when positions of my objects were becoming big that is in my case X position in the scene was around 150000 then those gaps started to appear and also I noticed that this problem occurred only on devices which had to scale the scene. I was using aspect fill with default scene size for iPhone 6 resolution and those gaps only appeared on iPhone 5 but on iPhone 6 I did not notice them. I was able to fix that issue by subtracting some constant value from X position of all objects (including camera position) from time to time so that everything on the scene relatively did not change position to the camera and look the same but actually absolute positions were changed to keep them low. I guess that larger position values like 150000 and scene scaling cause some floating point rounding issue in SpriteKit and that is why gaps are then becoming visible.
So based on my experience if you have similar gaps I recommend using integer values for all positions, widths, heights and additionally keep values of objects positions of all objects low.
For future reference in case someone is still searching for this, here are my experiences:
If tiles have PhysicsBodies, they are prone to making gaps. A solution for me was making a blank SKNode as a child of the tile, and assigning the PhysicsBody to that.
If possible, make sure bit masks are set in a way that tiles can't collide with each other.
As stated in a previous answer, make sure all measurements are integers and rounded in a way that doesn't leave a one unit gap between them.
A related problem is also SpriteKit's PhysicsBody drifting. There are some threads about this (e.g. https://forums.developer.apple.com/thread/27057 ), and it seems to be abug. In my case, the problem was a combination of PhysicsBodies causing random small gaps, and the drifting making some of them larger. The steps above removed the small gaps. Unfortunately the only workaround for the drifting problem in my case was to only generate PhysicsBodies for nodes that are within a certain distance from the player and destroying them after they are left behind.
For future reference for anyone who needs, I found an different answer specific to my problem. As JohnV said, I may need to round of values when setting the position, but when running the code, I found out that I also need to do that when running SKActions.
I'm currently working on a XNA project where I need to create a Picture in picture Overlay to displaying a 3D scene from multiple angles. currently I'm trying to use 2 viewports to do this. The main one fills whole screen and is working as desired. The second is placed in one of the corners of the first (overlapping that corner) and is less than a 5th of the size as the first. apart from the size and placement of the viewports the only thing really difference between the 2 is the placement of their cameras with-in the scene.
As long as the second viewport is drawn second and there are no objects close to the camera of the first viewport in the overlapping corner this actually works greate. However if there is an object close to the camera and in the corner of the first viewport objects seem to experience occlusion culling as a result of the first viewport's object. The occluding object of the first viewport is not shown in the second viewports space though.
My question is how would one prevent the "cross viewport culling" from happening? I've searched all over and the closes threads I could find suggest drawing the second viewport to a RenderTarget2D and using a SpriteBatch to display the resulting texture. Though doing so does fix the occlusion issue it does mayhem on the z ordering, CCW culling, and my water effects all of which I've never had issue with using the default render target.
This issue, at least in my case, Seems to have been resolved by simply clearing the depth buffer between drawing the 2 Viewports. I did this by adding the following line between the function calls that draws the individual Viewports
GraphicsDevice.Clear(ClearOptions.DepthBuffer, Color.Black, 1, 0);
I ran in to this solution while trying to use the Stencil buffer to prevent the Main viewport from drawing under the second, but everything I did before this discovery did not really have a noticeable effect. After I removed all the Stencil code and it looks like I'm getting the desired effect. Sorry but I can't really explain how or why this works without messing up the first Viewport cause I have no clue myself.
i'm creating simple iOS game with Cocos2D and Box2D. In my game user has to create full word by shooting to squares with letters. If shooted letter is correct the square should explode, otherwise the square should fall down. I have created simple contact listener and I can detect collision between bullet and square but the problem is how to avoid collision force when letter is incorrect? I that situation (incorrect letter) i want square to simply fall down without applying collision force to the square.
Maybe I can delete the square and create new one at the position of deleted, but i think it's not the best idea :)
One suggestion I would make would be on collision, if the letter is incorrect, set the bodies x and z velocities to 0. This way when they collide with incorrect squares they will simply fall.
Another thing you could do would be to set the target square's body as fixed ( or rigid, I can't remember what it's called in Box2d off the top of my head). So even if an incorrect letter collides with it, it will not budge but the letter will bounce off it. And it the letter is correct, you can explode it as normal.
The solution I would advice is to set the velocity of the bullet to 0 in both directions in the PreSolve callback of the contact listener. Obviously you do a check in the PreSolve function. This way as the function is called PreSolve, the collision calculation have not happened yet. so setting velocity to 0 will make the bullet to have no effect on the square in terms of force.
I've been suffering from an issue regarding the implementation of orienting characters in a game I'm implementing using Ogre3D and Bullet physics.
What I have: A Direction Vector that the character is moving in, along with its current orientation.
What I need: To set the orientation of the character to face the way it is moving.
I have a snippet of code that sort of does what I want:
btTransform src = body->getCenterOfMassTransform();
btVector3 up = BtOgre::Convert::toBullet(Ogre::Vector3::UNIT_X);
btVector3 normDirection = mDirection.normalized();
btScalar angle = acos(up.dot(normDirection));
btVector3 axis = up.cross(normDirection);
src.setRotation(btQuaternion(axis, angle));
body->setCenterOfMassTransform(src);
Where 'body' is the rigidbody I'm trying to orient.
This snippet has a couple of problems however:
1) When changing direction, it tends to 'jitter' i.e. it rapidly faces one way, then the opposite for a second or so before correcting itself to the orientation it is supposed to be at.
2) Most times that the code is run I get an assertion error from Bullet's btQuaternion on
assert(d != btScalar(0.0));
Can anyone help?
Thanks!
I think you shouldn't use functions like 'acos' for such things, as it may cause some inconsistencies in border-cases as the 180 vs 0 rotation mentioned above. You can also get high numerical error for such data.
The second thing is that - in general - you should avoid setting explicit position and rotation in physics engines, but rather apply forces and torques to make your body moving as you want. Your current approach may work perfectly now, but when you add another object and force you character to occupy the same space, your simulation will explode. And at this stage it's very hard to fix it, so it's better to do it right from start :) .
I know that finding correct force/torque can be tricky but it's the best way to make your simulation consistent.