I'm using Cocos2D, SpaceManager and Chipmunk. I have a parallax node with 4 layers on it, this is tied to the location of a playable chipmunk body. This body needs to collide with static objects on one of the parallax layers, the static bodies must start off screen then move into screen and collide.
I know you are not supposed to move static bodies with Chipmunk, unless you rehash. However, rehashing 60 time a second to keep up with the framerate seems messy. Can anyone think of an alternate way to do this?
Cheers.
One thing you could try is joining all the objects in each parallax layer to a non-colliding body using rigid joints. Then move that body along with the parallax layer to drag the objects along. THis may not be the best method, though.
Related
Hello recently i started to mess around with SDL. Since i was interested in some 2D/2.5D games.So i started messing around with SDL in C++, I was looking to recreate something similar to Original Zelda.
So as far as i understand those game work with some kind of isometric prespective, or standard Orthogonal view but one thing i do not understand is how can you generate 3D-like Collisions between those objects on the map (tiles, sprites etc which are in 2D). Have a look at the video link below. Is this created purely in SDL, is it PerPixel collision or rectangular ? Or it might involve OpenGL as well ?
Link: https://www.youtube.com/watch?v=wFvAByqAuk0
The original was probably a simple Rectangular collision.
I believe that your "3D collision" is the partial collision present in some objects. For example, Link can go through the leaves, but not through the trunk.
You can do it easily in 2 ways:
Layers of rendering and collision. The trunk is located in one layer and is covered by some collision boxes. Link is present in a intermediary layer. And the leaves are in another layer, on top of Link. Then you can check collision between Link's Layer and the layer with the trunk and other objects, for example.
Additionally you can create a property for your tiles in which you can store the type of collision you hope to obtain. For example, 'box' collision will tell your engine that the object is collidable on every side. Or 'bottom' collision will tell your engine that Link will collide with this object only if he is walking down into the object (this is the effect of you will see on some 2D sidescrollers: jump through a tile but then fall into it solid.
Per pixel collision in those simple cases is not worth it. I find it much better to personalize the collision ourselves, using creativity, masks and layers.
BTW: This topic would fit better on https://gamedev.stackexchange.com/
after applying to a Box2D body:
b2Vec2 force = b2Vec2(velocity.x/PTM_RATIO, velocity.y/PTM_RATIO);
_body->ApplyLinearImpulse(force,_body->GetPosition());
I'm trying as in many game (like doodle jump) to stop moving the hero body once it reaches a certain distance from the top of the screen and start scrolling the stage so that we feel the hero is still climbing higher. For this I need to move the hero in the first place and then move the stage.
How can this be achieved correctly ? Any idea?
Thats quite an odd thinking to solve the problem. You never stop the character or any of the environment objects. Let them behave as they are intended by box2d. You have everything added to one root node of some sort, your environment and the character. What you do is create some sort of a "camera controller" and you give the characters CCSprite, or the wrapping objects if you have one, as a target. In the update function that you call each frame you change the root nodes position in a way that it centres the screen on the character. You can implement follow delays, smooth scrolling and other nice features as you need them.
Unfortunately I don't use Cocos2d at all, so I can't give you a sample code. The given solution will work for Cocos2d as it is not far of the engine I use at my work place.
I just started using Cocos2D this week. While playing around with Box2d i was wondering if it was possible to move CCSprites with the help of CCActions and use box2ds collisiion detection feature to detect collision between those sprites..
I'm pretty sure this must be possible?
If you don't need real physics behavior, I'd highly recommend to "manually" deal with your collision logic. That said, for your scenario I would start with this approach.-
Create one body per sprite, and assign each sprite to the user data.
Your 'static' scenario would map to static bodies (i.e floor, platforms, etc...)
Your 'dynamic' sprites would map to dynamic bodies, which only fixture would be marked as sensor
You'd register a b2ContactListener to listen for the collisions.
As for the tricky part, you'd need to set in each iteration of the main loop, the position of each body to the position of each sprite (of course, translating pixels to meters), in order to avoid that they just behave as physics bodies. You could try just to not calling world->step, but not sure if contactListener would work then.
Hope it helps!
When I drag an object in my game, the object is never directly under the finger. There us this lag / delay that I cannot get rid of. It follows my finger instead of being directly underneath it. You can try in the Testbed as well. Trying moving an object really fast and the object is never underneath the mouse/finger
Is this a weakness in box2d? Or am I missing something obvious ?
Thanks in advance
That's because mouseJoint is similar to distantJoint (spring). There is a maxForce parameter you can specify to minimize the delay - make the spring more hard.
EDIT:
Also you can move your object directly specifying it's position to your finger position. But if this object will collide with something it will provide non-physical behavior because the velocity of the body will be zero.
So to move it correctly (if there will be collisions) you should specify it's velocity or acceleration (as mouse joint does). But to evaluate your finger velocity you will need some time and delay will remain.
Most of it has to do with latency in the hardware. If your timings are completely perfect, their will be 16ms of lag caused by the iPhone's GPU, ~20ms of lag from the touchscreen, and then how ever long the processing takes for your scene. So those add up to anywhere between 36-70ms of lag. Also, there is a small amount of damping applied in box2d on the mouse joint, for stability of the physics simulation.
I'm making slow but steady progress with a Cocos2d game, but I'm stuck creating moving platforms.
The main character needs physics and collision detection, and is therefore a chipmunk shape/body. I wrote a class to iterate over the TMXTiledMap in order to cut back on the amount of bodies in the chipmunk space. So with a map like this
----------
--------x-
-xxx----x-
----------
instead of having 5 individual bodies (rects), there are two bodies, One is three tiles wide, the other is two tiles tall.
I've managed to get the code working to identify which tiles are part of a moving platform and to move the tiles as needed.
However, the bodies need to move with the tiles in order for this to work properly. And this is where I'm stuck. The bodies are of a static mass so...
platformShape->body->p = cpv(x,y);
Doesn't do anything (I'm guessing that this is the expected behavior).
But if I set their mass to anything other than static, all the physics comes into play and the bodies do not behave as expected, or they behave perfectly depending on you how you look at it. They move erratically and the rotate when they hit another body (eg: the main character). What I'm after is the typical type of moving platform you would expect to find in a typical platform game that moves smoothly in any given direction.
My question is; Has anyone implemented something like this before and what was your technique? Or, if you were to implement something like this, how would you do it?
The relevant code is here. I put it in a pastebin since I figure it's more of a conceptual misunderstanding than anything else.
It turns out you need to call
cpRehashStaticShapes
Obvious really, but easy to miss in my opinion.