In my two d game, I move a white 40x40 pixels square, ramdomly on the map appear some red square, as a simple pic 40x40.
The player can move freely for all the map, exept on the red square that are obstacle just like walls.
How can I limit the movements of the player according to the space covered by the red squares?
Probably the quickest solution would be to cast a ray in each cardinal direction - one ray per frame would more than likely suffice.
[java]
Vector3f playerLocation = player.GetLocation();
Vector3f north = Vector3f.UNIT_Z.negate();
Vector3f east = Vector3f.UNIT_X;
Vector3f south = Vector3f.UNIT_Z;
Vector3f west = Vector3f.UNIT_X.negate();
Ray ray = new Ray(playerLocation, north);
CollisionResults results = new CollisionResults();
rootNode.collideWith(ray, results);
CollisionResult result = results.getClosestCollision();
[/java]
I’m not absolutely positive if ray collision works as I believe it does, but I think if you organize your red squares in the rootNode properly - e.g. put them in a child node instead of just into the rootNode, you can check on that child node instead, and thus it would only have to check collision for the red boxes instead of the entire rootNode, which will more than likely speed up the process.
I attached the square to the guiNode
[java]guiNode.attachChild(n);[/java]
But result is null.
From the player’s controlUpdate.
[java]if (up) {
ray = new Ray(playerLocation, north);
results = new CollisionResults();
rootNode.collideWith(ray, results);
result = results.getClosestCollision();
if (spatial.getLocalTranslation().y < screenHeight - (Float) spatial.getUserData(“radius”)) {
if (spatial.getLocalTranslation().y < result.getContactPoint().getY()) {
spatial.move(0, tpf * speed, 0);
}
};[/java]
well that’s because you attach it to the guiNode and then check the rootNode for collisions. I’m not sure raycasting even works on the guiNode. Give it a whirl. Would be nice to know.
Same thing using the guiNode.
It doesnt look like rays are meant to be used in the guiNode then I’m afraid. Personally I would use the rootNode instead, and just lock the z-plane to zero - which will make things a lot easier for you in the long run. Most things including particles don’t play well on the guiNode.
Rays work fine on the gui node but you have to construct them properly. ie: the position is in screen coordinates and the ray points along the -z axis, etc.
Oh, though if you mean like for player collisions then no that won’t work since everything is probably flat in z space.
I moved all the elements on the rootNode but now seems that the ray hits the center of the red squares instead a point on it’s perimeter.
@Tanelorn said: I moved all the elements on the rootNode but now seems that the ray hits the center of the red squares instead a point on it's perimeter.
Yeah, I was going to follow up that this wouldn’t really work even in 3D. Trying to intersect a quad directly from its edge either won’t work at all or will give very strange results suspect.
This kind of thing is easier if you just do the math, though. Calculating axis-oriented quad collisions is one of the more trivial types of game math you can do.
isnt it easier to just use .getDistance() from the collisionResult - and thus determine a collision based on the that value? For example, if less than .5f .
I think rays will also have the problem that the corners will be able to penetrate. Unless you cast lots of extra rays.
The math for calculating the intersection of two quads is not hard and the result will tell you exactly how much they penetrate in x and y… which I assume would be needed for resolving the collision.
Another option is to use dyn4j or box2d… they work well with JME. I would suggest dyn4j over the other.
ah those pesky corners. I didnt think about that.
@t0neg0d said: Another option is to use dyn4j or box2d... they work well with JME. I would suggest dyn4j over the other.+1 for using dyn4j - been messing with it for some time now, it really is superb for doing 2D physics.
Ok I will try with physics.
@Tanelorn said: Ok I will try with physics.
This will solve later issues if you add things like projectiles, etc. Keep in mind that you’ll likely not be able to use gravity as I don’t think 2d physics allows you to set the gravity along the non-existent z axis if working from a top-down view 
However, you can still apply friction and such to slow movement. You should be able to approximate the effect this way.
Once added the dyn4j jar library to the project, should I modify the “build-imp.xml” file?
@Tanelorn said: Once added the dyn4j jar library to the project, should I modify the "build-imp.xml" file?
Why would you?
Is there any code example of a dyn4j-jme integration?