Thread history

After some testing, maybe we can come up with a more consistent implementation for checking bullet collisions / line intersections in the Robocode engine. Here's the relevant code snippet: [1] (line 76 calling line 113).

Here's one that gets rid of the division which I expect is what blows up on poorly conditioned problems:

	private boolean intersect(Line2D.Double line) {
		double x1 = line.x1, x2 = line.x2, x3 = boundingLine.x1, x4 = boundingLine.x2;
		double y1 = line.y1, y2 = line.y2, y3 = boundingLine.y1, y4 = boundingLine.y2;

		double dx13 = (x1 - x3), dx21 = (x2 - x1), dx43 = (x4 - x3);
		double dy13 = (y1 - y3), dy21 = (y2 - y1), dy43 = (y4 - y3);

		double dn = dy43 * dx21 - dx43 * dy21;
                double dn_sign = Math.signum(dn);
                double dn_abs = dn*dn_sign;

		double ua = (dx43 * dy13 - dy43 * dx13) * dn_sign;
		double ub = (dx21 * dy13 - dy21 * dx13) * dn_sign;

		return (ua >= 0 && ua <= dn_abs) && (ub >= 0 && ub <= dn_abs);
	}

It might even be faster, divisions are about the same speed as sqrt.

Given that it is using it's own code to determine intersection rather than a JVM method, I wonder if the discrepancy between systems is actually in the data stored in the line objects.

I thought maybe I could tweak it using a small amount of movement to make it work on all systems, but so far my attempts have degraded shielding performance unacceptably. One bit of good news -- I tested and found out that Robocode security does not prohibit robots from reading System properties, so if I can figure out how to correct (at least partially) for the problem on other OSs or JVMs, I can test for them and just make those changes on the appropriate systems.