Moving objects getting stuck in a corner

I am working on a program which simulates objects moving in a field. The field has a boundary of 1024x1024. The object cannot go below 0 in terms of x,y coordinate and it cannot go above 1024. I have a method for each object called "move()" which moves the object in its current direction at its current speed. If the object approaches the boundary, it then turns around with a new direction and same speed.

The problem I am having is that when one of my objects gets close to both the x and y bound (corner of the field), it gets stuck in the corner. It is almost as if it is trying to move away from the corner, but then it turns back. It must love that corner. I looked over my code and to me, my logic seems correct. I check to make sure the new direction is not negative or over 359. I check to make sure the new x,y coordinate with the new direction is within the bounds too. I even have a method to set a new direction.

I have tried re-implementing this method with different logic, but no luck. If anyone could possibly find a flaw in my programming or point out what may be causing it, then that would be much appreciated.

I have tried to debug and step through my program and I see that when it gets to the corner, it changes direction to turn around, moves about 3 spaces, then goes back to the corner. Must be a wonderful corner.

Code for move method is below:

public void move(){

  localX = super.getX();
  localY = super.getY();

  float newX=0, newY=0;
  float testX, testY;
  boolean acceptX = false, acceptY = false;

  testX = (float) (Math.cos(direction)*10) + localX;
  testY = (float) (Math.sin(direction)*10) + localY;
  int testDirection;

  while(!acceptX){
   if(testX >= 0 && testX <= bound){
    newX = testX;
    acceptX = true;
   }//end if statement
   else{
    if(direction+180 > 359){
     setDirection(direction-180);
     testX = (float) (Math.cos(Math.toRadians(direction))*speed) + localX;
    }
    else{
     setDirection(direction+180);
     testX = (float) (Math.cos(Math.toRadians(direction))*speed) + localX;
    }
   }//end else
  }//end while that checks for X value

  while(!acceptY){
   if(testY >= 0 && testY <= bound){
    newY = testY;
开发者_Go百科    acceptY = true;
   }//end if statement
   else{
    if(direction+180 > 359){
     setDirection(direction-180);
     testY = (float) (Math.sin(Math.toRadians(direction))*speed) + localY;
    }
    else{
     setDirection(direction+180);
     testY = (float) (Math.sin(Math.toRadians(direction))*speed) + localY;
    }
   }//end else
  }//end while that checks for Y value

  super.setX(newX);
  super.setY(newY);

 }

and here is the code for setDirection

public void setDirection(int d) {
        direction = d;
    }

Say you have an object in the upper left corner, going up. Your first test turns it around so it goes down. Then comes your second check, which turns it around again to go up... again.

Your code could also use some more readability. The very first thing I noticed is that you're using the >359 checks to normalize the new direction to go in. Yet all cases include the movement code as well. I would do something like:

setDirection(direction + 180);          //turn around
if (direction >= 360) direction -= 360; //normalize
testY = ...;                            //move

to move the movement code out of the direction checking if/else blocks. 360 is also a better magic number to use; 359 degrees means nothing. As has been suggested, you should ultimately use a vector library and thus throw away most of the math.

I'd really recommend storing your direction as a vector (x, y) instead of calculating that vector from a scalar; I think that would help you immensely with your code.

Issue: When your object hits an edge, you turn it 180 degrees. If it hits both edges, it'll spin in place, and the test coordinates will always be in the wrong spot.

When one of your objects hits an edge, it needs to bounce, not About Face! Angle of incidence == angle of refraction, or some such. In other words, if you're checking the x coordinate and it bounces, negate the x velocity, not both x & y.