Tag Info

New answers tagged

1

You're right, it can be done in two ways: -Moving the player -Moving the world This seems like a 50-50 deal. It doesn't matter how you do it, right? I don't agree. I would ALWAYS suggest moving the player. Because if you choose to move the world now, and a few months further on in development, when you have enemies, npc's, and other entities on screen, ...


0

For many collisions, there will be several contacts to resolve. This is why you're getting multiple calls to your player.destroy(). I don't know what you're doing in the destroy method, but you shouldn't destroy any Box2D bodies of fixtures in there, as they might be needed for other preSolve calls. What you could do is instead of immediately destroying ...


2

Directly editing the position of a box2d body will produce non-physical behaviour, it's present because sometimes you will need to teleport bodies to a far away location, or reset the position of an object without the need to destroy/re-create it, etc... In your case the joints are not handling the position adjustments well. The setPosition function should ...


0

Firstly, your question is very unclear. It doesn't have all the necessary information. Nothing at all in fact. Try to be a little more informative or precise in the future. When two bodies collide in Box2D there are numerous collisions. Collisions in Box2D are really the fixtures which are used to detect when a collision occurs. Collisions can happen in ...


0

ideally, you configure group/mask for your lights and objects. Using this, you can tell your point light to ignore those branches. See a great write-up here. alternatively, as a brute force approach, you could render lights before you draw your branch (though you should REALLY use the mask approach above): // draw all objects that should create shadows ...


0

Subtract the box position from the mouse position, normalise that vector and apply that as force You can multiply the normalised vector by a float to increase the force.


0

I'm just starting out with lighting myself, but one of these two solutions might help you. set an ambient light to brighten up the world: rayHandler = new RayHandler(world); rayHandler.setAmbientLight(new Color(.1f, .1f, .1f, .5f)); or allow the light to ignore bodies: pointLight = new PointLight( ... ); pointLight.setXray(true);


1

I know this is an old question, but I've just come across this solution and found that making sure restitution is not above 1 is not enough. friction also caused differentiation in the angle of which it bounces off. so setting friction to 0 allowed me to bounce a ball up against a 45* wall and get the expected perpendicular reaction.


0

The render() methods of ray handler should not in the batch.begin() and batch.end() methods. public void draw(Batch batch, float delta){ super.draw(batch,delta); batch.end(); ray_handler.render(); batch.begin(); batch.draw(Something......) } Above codes are working properly. The Result looks like this


2

The skewing is because of how the viewport is setup, try changing it to something like this; @Override public void create() { ... bodyDef.position.set(0, 0); // Let this be at origin for now, it's easier to debug ... camera = new OrthographicCamera(200, 200 * ((float)Gdx.graphics.getHeight()/(float)Gdx.graphics.getWidth()); ...


1

What's Happening This is completely accurate physical behaviour, which can be explained using a free-body diagram and a little high school physics1: The mass of the block is m and g is the gravitational constant. Fa is the applied force. To understand why the block is not moving, we can write out the force balances in the x and y directions. x-Momentum ...


0

I have found some sort of a workaround this, but I am not sure if this is a good way to code. When a key is pressed, I set the angular velocity to 10 and then at every update, I ask it to check if(weapon.getAngle() >= Math.PI / 2) { weapon.setAngularVelocity(-10); } if(weapon.getAngle() <= 0) { ...



Top 50 recent answers are included