Hmmm, I knew I should have gone with a pizza example instead

a nested for loop helps with the multi-obj colission. Here's a fairly lame ball-ball collision example (book has a more accurate example):

Code:

int ballCount = 30;
Ball[] balls = new Ball[ballCount];

void setup(){
  size(400, 400);
  noStroke();
  fill(120);
  smooth();
  for (int i=0; i<ballCount; i++){
    float xpos = random(50, width-50);
    float ypos = random(50, height-50);
    float rad = random(3, 10);
    float spdx = random(-1, 1);
    float spdy = random(-1, 1);
    balls[i] = new Ball(xpos, ypos, rad, spdx, spdy) ;
  }
}

void draw(){
  background(255);
  for (int i=0; i<ballCount; i++){
    balls[i].create();
    balls[i].move();

    // simple boundary collision
    if (balls[i].x>width-balls[i].radius || 
	balls[i].x<balls[i].radius){
	balls[i].speedX*=-1;
    }
    if (balls[i].y>height-balls[i].radius || 
	balls[i].y<balls[i].radius){
	balls[i].speedY*=-1;
    }

    // ball-ball detection
    for (int j=0; j<ballCount; j++){
	if (i!=j  && dist(balls[i].x, balls[i].y, balls[j].x, balls[j].y) < balls[i].radius + balls[j].radius){
	  // really lame dumbass collision
	  // there's a more accurate (and complicated) example in book
	  float tempspdX = balls[i].speedX;
	  float tempspdY = balls[i].speedY;
	  balls[i].speedX = balls[j].speedX;
	  balls[i].speedY = balls[j].speedY;
	  balls[j].speedX = tempspdX;
	  balls[j].speedY = tempspdY;
	}
    }
  }
}

class Ball{

  float x, y, radius, speedX, speedY;

  Ball(float x, float y, float radius, float speedX, float speedY){
    this.x = x;
    this.y = y;
    this.radius = radius;
    this.speedX = speedX;
    this.speedY = speedY;
  }

  void create(){
    ellipse(x, y, radius*2, radius*2);
  }
  
  void move(){
    x+=speedX;
    y+=speedY;
  }
}
 

Cedric wrote on Aug 16^th, 2008, 4:17am:

Oh, that's Casey's book. Or rather, it's Casey and I's book, but it's his baby. Actually it's not his baby because now he has a baby. Err, so he did the "hard" work on the book. How 'bout that. So if only one of us gets mentioned, it should be him.

Had it just been me, I mighta just stolen Ira's burrito examples. Mmmm, beans.

But as for your question, the problem is that for each object, you're testing collision between every single object over again. That is, inside the collision() method, you're checking for collisions between all objects, which is fine. But then you're calling the collision() method on each object, which means you're rechecking everything again! So with 100 points, that's 100x100x100 collision tests, which is, uh, a lot.

Point is, inside collision(), you should be testing that particular Spot's x and y position with a single for() loop that compares it against the others. Same goes for the lines() function. The fixed versions look like:
Quote:

While Ben's suggestion will very significantly reduce the number of comparisons you need to make from n*n*n to n*n, you can improve things still further.

Both collisions and line drawing in your example are symmetric. In other words, if spot A collides with spot B, then spot B must also have collided with spot A. You can therefore halve the number of line drawings and collision detections you need to make. In fact, it is slightly less than half since you never have to compare a spot with itself. An easy way to implement this is to pass an index number of the current spot being tested to your collision() and lines() methods. These methods need only compare with the remaining untested spots in your array.

A second, minor improvement, is to remove the stroke and fill settings from inside your for loops since they do not change in response to the loop iterations. While this will have a very minor effect in this case, it is good practice separate code that depends on each loop iteration from that which applies to all loop iterations.

There is also slightly more subtle bug introduced by Ben's more efficient drawing code. Because  the code for drawing an uncollided spot is in a different method to the code for drawing a collided spot, a spot that is drawn as collided, can get redrawn as uncollided as the for loop in draw proceeds. A more object-oriented solution would be to store as part of the state of each spot, whether or not it is in collision with anything, and then modify Spot's [tt]display/tt] method appropriately.

Code incorporating all of the above is shown below:

Quote:

Thanks Jo,
This is great stuff!

If it's not on there yet, seems like an excellent example under Hacks

-Ira