I'm trying to use Bullet Physics in my iOS game. The engine appears to be correctly compiled in that the demos work fine.
In my game I have the player's ship and some enemy ships. They're defined as btRigidBody objects and btCollisionObjects and I'm using btSphereShapes for collision.
At 'fast' speeds, collisions appear to happen sensibly - things collide and nothing goes 'weird'. If the speeds are very slow though and the player's ship touches a non-moving object the collision happens, but then the player's ship moves at incredible speed over the next few frames and appears a long distance from where it collided - completely out of proportion to the speed it was moving before impact.
To move the things around I'm using setLinearVelocity() each frame, ticking the physics engine, then using getMotionState() to update the rendering code I have.
Part of the issue might be I don't quite understand how to set the correct mass or what the best speeds are to use for anything. I'm mostly sticking numbers in and seeing what happens.
Should I be using Bullet in this way, and are there any guidelines for deciding on the mass of objects? (am I right in assuming that in collisions heavier objects will force lighter objects to move more)
I'm no expert yet in bullet, but I would not use setLinearVelocity. This is just for initial state, once in the world, if you want to give something a push in the right direction, give it an impulse. This is like being hit with an invisible object so is completely compatible with other collisions. Setting the velocity every frame will completely override the physics engines calculations.
I have noticed that when two objects overlap, they repel each other with a force relative to how much they overlap by. I think your setVelocity method is causing objects to overlap, then eventually the physics engine resolves this in an undesirable way.
I am making a space ship game, I make impulses to cancel out the current movement direction, plus impulses to move it in the new direction as long as the ship is not already moving at my chosen max speed.
Related
I'm trying to understand the proper way to move "obstacle" objects in corona/box2d. I want to know how to write my code so that the movement is deterministic and in-step with the physics engine. Is this possible?
I'm familiar with Unity which has a physics update (FixedUpdate). Where you can add a bit of code to execute on every physics step. This keeps the physics deterministic, frame and system time independent.
For example, in my game I want to do things like: Make a platform that moves back and forth, make an object that scales up and down in size. I would still like the physics to work properly and allow the ball in my game to bounce off of these for example. Depending on the case, I imagine that I should use either kinematic or dynamic bodies.
I've searched around and the way to periodically manipulate these objects is to use:
timer.performWithDelay. But this has an issue mentioned in the docs "Timers run on system time. If the app is suspended, running timers will not be automatically paused"
Listening to an enterFrame event. But this has a similar issue, if the frame rate drops then the object won't be moved enough. We can use delta time to deal with this, but this has determinism issues (moving an object too much on a lag spike).
transition.to. I'm guessing this is implemented with timer.performWithDelay and has the same issues.
I don't think that any of these will behave deterministic. Any suggestions? Thanks for the help.
You should really use:
object:setLinearVelocity(xVelocity, yVelocity)
or
object:applyForce(xForce, yForce)
instead of transition.to.
I've got a scene where a certain number of nodes spawn at the top of the screen and another batch of nodes at the bottom. Now if they collide, I want the game to end which it does, the only problem is that the collision causes a major frame drop or stutter/lag whatever you can think. It basically stops the game for a second and it continues.
The nodes don't have textures. There are no sounds playing when the nodes collide. I've stripped everything down and left just the nodes to collide and the problem persists. I can't point a finger at where it's really coming from since i've left nothing unturned and the scene is not complex 8/9 nodes most at a time.
This doesn't always happen sometimes the nodes collide and everything runs smooth. The only other information i can provide is that the nodes are moving rather fast so they fly in and out of the scene within 0.05 seconds which i tried setting it to a longer duration the problem still persists just more rarely. When the game is over the user has the option to present the scene again which adds the scene from the beginning.
This question leans more toward people who might have had a similar issue , since I don't know what more information I can provide. (Square nodes collide right away the game stops for a second and continues). Thanks.
I've made my way through the pages of SO questions regarding sprite-kit, the docs, available demos, and the vast empty space that is my brain to try and figure this one out but have come up short.
Working on a proof-of-concept that is a turn-based (using Game Center), physics-based game. Players take turns placing a node amongst a collection of other nodes and letting the physics play out. Where I'm flummoxed is in determining that all collisions have played out and the turn has ended.
It would seem that the nodes never stop colliding.
This is a tricky task with physics simulations.
First of all, with gravity enabled you always have a force acting upon bodies that may prevent it from resting. So you need to test every body every couple of steps (or every frame if you must) to see whether its velocity vector length is smaller than a given threshold. Then manually set the body's resting state to YES.
The bodies may wake up again during contacts, so it is crucial to perform this step after contact resolution in didSimulatePhysics.
The trick is in finding a threshold that is large enough to guarantee an end to the "physics entanglements" while not being too high to make objects stop where they clearly shouldn't.
Even then you probably also need to set a timer that starts when every body's velocity is below another (higher) threshold indicating that there will likely be little forces coming from those bodies anyway, and if after a grace period (ie 10 seconds) the bodies are still not all resting but below this threshold, consider the collisions resolved (as far as the game is concerned).
Also the number of bodies still not resting may be an indicator to end the game, ie if there are only 3 or 4 bodies of dozens still moving, there's probably not much going to happen as well.
I am currently part way through developing my first game with chipmunk2D on the iOS platforms.
One problem I have encountered however is the lack of repeatability within the chipmunk environment. For example, I can have a fairly simple (<20 blocks) setup and yet every time physics is applied to the body's they react in slightly different ways. The ways they react are never violently different yet they are different enough to the point where it is game breaking for me.
When creating the chipmunk bodys/shapes/spaces I am including size, mass, moment, friction, and elasticity. I believe I am including everything there.
Does chipmunk use some randomization in its physics code? If not (or even if it does) What is the best way to fix this randomization
http://chipmunk-physics.net/release/ChipmunkLatest-Docs/#cpShape-Misc
Chipmunk keeps a counter so that every new shape is given a unique
hash value to be used in the spatial index. Because this affects the
order in which the collisions are found and handled, you can reset the
shape counter every time you populate a space with new shapes. If you
don’t, there might be (very) slight differences in the simulation.
So, reset the counter before each simulation, and you should have better reproductibility.
I have seen the usage of plist and png atlasses for the game i am developing. However I've notice a slight performance swiftness(speed up) keeping the 60 fps, and for a side note my app has not crash at the moment.
The thing is I noticed I have used SpriteFrameCache with plist to do CCactions and animations for my characters(sprites). However some of the characters ive been using SpriteBatchnode, but it was on accident, since I am relatively new to deep development of a game, I didnt notice this difference before, they both work, but I feel like both are the same, its just that one has an easier way of implementation than the other, i was thinking that perhaps it was developed in an earlier version....
so my question is. is there a difference between the two? will my game benefit for using SpriteFrameCache over SpriteBatchNode?
Thanks for the help.
FYI: this doesnt slow down my developing, its just a question because I know at the end when my game is finished maybe i would want to optimize performance for my game.
Batch nodes draw all child sprites in one draw call.
Sprite frames hold a reference to a texture and define a region in the texture to draw from. The cache allows you to access sprite frames by name.
Both are different concepts, they are not replacements for each other. You can use sprite frames to create sprites or sprite frame animations. In addition to that sprite batching enables you to speed up rendering of two or more sprites using the same texture.
Note that if you use a batch node with only a single child sprite this will not be any different from rendering the sprite without the batch node, since both create a single draw call so there is no positive effect in using the batch node.