These two things kind of puzzle me a bit. I imagine for some accurate/efficient collision, a decent algorithm would need to be in play. What my real question is, how do you implement collision in a way that it remains accurate, no matter the speed of the objects colliding?

If you don't know what I mean, it's basically that, to move an object across a screen, each frame, the x and/or y position of the object is incremented/decremented according to how fast you want it to appear moving. Well, if an object is moving very fast, then in one frame it'll be at x-coord 20, and then the next, it could be at x-coord 200. Well, if there was an object that it was suppose to collide with at position 100 that was only 50 pixels wide, then there is technically never a point of intersection between the objects. And, if coded to only check if object A has crossed into the bounds of object B, than this would definitely cause problems with detecting the collisions.

I'm going to assume there are movement/collision algorithms available in various places among the net. But, I guess I'm looking for what is most efficient/accurate, and maybe an explanation as to how that is derived.

Instead of detecting if the object cordinates match up with the designated cordinates you could detect if the cordinates are greater then where you want them to . Thats how I did my collision detection.

That wouldn't work well at all, especially in situations where the object is allowed to move around the target. You need to check for an actual intersection, rather than just seeing if the position is greater than the target object.

I feel like I need to be able to predict where collisions could occur...which sounds complicated.

What you're looking for is "Continuous Collision Detection". Its something that is fairly difficult to get right and does add quite a bit of overhead to the Collision Detection. Most game engines have a hard constant of how fast an object is allowed to travel, for example, it does not try to solve a collision for an object travelling at the speed of light for example. Fast objects skipping collisions because they travel too fast is whats called "Tunneling".

For bullets or extremely fast objects like laser beams you might wish to use Ray casting instead. For Continuous collision detection you can approach it in a number of ways.

1) You can construct a polyhedral type volume from the objects previous position and current position, and perform tests to make sure nothing came in between. This scheme can EASILLY become slower than brute forcing everything.

2) You can perform a Raycast from the objects previous position in the direction of current position, if the ray hits anything it means object has missed a collision, you can re-update the objects position to the first object the ray has hit and perform a collision detection as normal.

3) Simply add a hard constant for how fast objects can travel. The maximum distance traveled per collision step should be equal to half the radius of the object. This will ensure object does not miss any collisions. This is the most primitive, simplest and easiest to implement method, and it works very good for platform games that don't require rapid movement.

There are plenty of other ways to do this, just mess around with a couple of schemes and use whichever you like. Collision Detection is a fairly difficult topic and its a nightmare trying to code anything that's even remotely robust, but I hope I gave you some implementation directions

Easiest way is to step your world in small enough increments that you don't miss a collision. Remember that you can step many more times than the number of frames you show.

Not exactly on topic, but this is actually something that's been puzzling me. In a rudimentary setup, the more frames the machine can handle, the faster the game, runs. How can I do what you just said? Restrict the frames to something like 60, yet, be able to update as many times per second as the machine can handle?

You only need to do as many frames as are actually required to have correct logic. Running flat out is a waste of cpu cycles.

As always, you have a broad phase, where you can calculate, say, a bounding sphere of an entity, and position it at the current location. Then create a bounding sphere at the location the entity will be at the end of the tick. Connect the two and you now have a capped cylinder. Do this for all entities that travel at a velocity that would otherwise cause tunneling or other defects. Then do simple capped-cylinder vs. capped cylinder intersection tests, and if (and only if) this causes any collision, you start to simulate the physics at more fine-grained intervals. Where the interval is the inverse of the maximum velocity.

If you don't need to simulate two bullets colliding in mid-air, ignore everything I just said.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

You only need to do as many frames as are actually required to have correct logic. Running flat out is a waste of cpu cycles.

As always, you have a broad phase, where you can calculate, say, a bounding sphere of an entity, and position it at the current location. Then create a bounding sphere at the location the entity will be at the end of the tick. Connect the two and you now have a capped cylinder. Do this for all entities that travel at a velocity that would otherwise cause tunneling or other defects. Then do simple capped-cylinder vs. capped cylinder intersection tests, and if (and only if) this causes any collision, you start to simulate the physics at more fine-grained intervals. Where the interval is the inverse of the maximum velocity.

If you don't need to simulate two bullets colliding in mid-air, ignore everything I just said.

Yeah. I get that. My last question wasn't really related to the collision issue.

But but ... I liked to warp through planets in Frontier, if a collision was unavoidable! (high speed + full time zoom = chance to step right through a planet)

If you want to dive into math, set up a vector (new point - last point) and calculate the distance of all possible obstacles to this vector. If the distance is lower than a threshold (object radius + obstacle radius) you can try a more detaild caclulation. This isn't cheap but precise.

Edit: It's basically the same as Riven's suggestion, because the line+radius check is equal to the cylinder intersection. Sorry, didn't read all of the thread before posting

Already, so hopefully, loosely based on what was said (the language confused me a bit. Maybe I need some more math classes), I came up with this crude algorithm to either move an object the proper distance, or move them to the point of collision with another object:

/** * Pass in the distance to move, and the object to check * for a collision */moveToCollisionX(intdistance, Objecto){ // We start at this object's x positionintstart = x;

// For the distance parameter we'd pass in something// like (speed * delta), or whatever value is normally// used to adjust the x position. We add that to start// to get the final x position that this object SHOULD// end up at.intend = x + distance;

// Get bounding shape of o somehow

// movePoint is the final x coord that this object// will move to.intmovePoint = distance;

if (/*point intersects o bound*/) {// If the point ends up on touching o's bound// Point becomes the new x-coord to move tomovePoint = point;break; } }// Move this object to the determined x-valuex = movePoint;}

This is still rather crude. I've not determined a way to get the bounds of o yet, or how to efficiently check if the point in the for loop crosses that bound.

One question I have (if this algorithm isn't completely off track), would it be more efficient to create a line object between start and end? Then I could just check if that line intersects o. I don't know if I'd still have to loop through the coordinates that make up the line or not. This is only a first draft, after all.

Keep in mind, I am only working towards collisions in a 2 dimensional space.

Hmm. Well, since that makes my method very inefficient, couldn't I just go to the line theory, get the intended (x,y) coordinate, draw a line from the start point, and find where the line intersects?

If this is an approachable option, what does Java provide from drawing a line and then checking for intersection? I know that the Rectangle class has some sort of method that does that, but as far as I know, there isn't a line class with the same capabilities.

EDIT: Nevermind. I just looked at the API and the line class in Java2D does, in fact, have intersect methods. Though, they only return a true or false if there is an intersection. How can I get the actual point of intersection?

/** * Moves this object to the point of collision with obj, if * there is one. As well, if there is a collision, return true */publicbooleanmoveToCollision(intxDist, intyDist, EObjectobj) { // We start at this object's x positionPointstart = newPoint (xDist, yDist);

// The point where this object should end up if// there is no collisionPointend = newPoint (x + start.x, y + start.y);

My issue is, if they do intersect, how do I get the object to move to the proper location? Like, how do I accurately move it to the point of the collision? Do I just check the direction of movement and move the object to the opposite bounding edge of the other object? What if it collides at a diagonal? Should I stop movement altogether? Or should I continue movement towards the axis that didn't receive the collision?

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org