Code:

float meX = 100; 
float followX = 100; 
float step = 15; 
void setup(){ 
    size(400, 200); 
    rectMode(CENTER); 
    frameRate(24); 
}
float globalX = 0;
void draw(){
    translate( globalX, 0 );
    background(255); 
    fill(255,0,0); 
    rect(meX, 100, 20, 20); 
    fill(0); 
    rect(followX, 100, 20, 20); 
    if(keyPressed){ 
	  switch(key){ 
	  case '-': 
		meX -= step; 
		if(meX < -globalX) globalX += width; 
		break; 
	  case '+': 
	  case '=': 
		meX += step; 
		if(meX > width-1-globalX) globalX -= width; 
		break; 
	  } 
    } 
    followX += (meX-followX)*0.2; 
}
 

F

Ah - this is in Flash.

I'm asking the question here because I trust you guys with math better than Flash-heads. And in Processing I rarely get a "is it me or is Processing being crap?" And that's been the latter with Flash all week (delayed initialisation of objects a speciality!)



It's like asteroids but underwater, I flip to a different physics model when you leap out of water - quite fun really. I've also taken the Bresenham algorithm and used it to calculate the vector to push out of pixelated scenery. I know that creates some odd collisions with one particle - but tie those together with springs and it all gets very realistic!

I try to upload the physics engine for sharing when I'm done - I keep dickering with the thing and adding widgets.

I've gone with davbol's route - pushing and popping angles confuses me a bit.

Here's what I was after:
Code:

float theta = 2;
float target = 2;
float step = 0.08;
void setup(){
  size(200, 200);
}
void draw(){
  background(255);
  float x = 100+cos(theta)*100;
  float y = 100+sin(theta)*100;
  stroke(255,0,0);
  line(100, 100, x, y);
  x = 100+cos(target)*100;
  y = 100+sin(target)*100;
  stroke(0);
  line(100, 100, x, y);
  if(keyPressed){
    switch(key){
	case '-':
	  target -= step;
	  if(target < -PI) target += TWO_PI;
	  break;
	case '+':
	case '=':
	  target += step;
	  if(target > PI) target -= TWO_PI;
	  break;
    }
  }
  theta = wrapLerp(theta, target, 0.2);
}
float wrapLerp(float a, float b, float t){
  a += (abs(b-a) > PI) ? ((a < b) ? TWO_PI : -TWO_PI) : 0;
  return lerp(a, b, t);
}
 

Edit:

Sorry - thanks

It's not clear to me what you're trying to accomplish -- it appears you want your 'follow' to wrap in a 300-unit coordinate system (50,350) while your 'target' wraps in a 400-unit (0,width) coordinate system?  What does that mean?  What happens in those other 100 coordinate units?  Seems like a really bizarre use!  

At any rate, the fix *might* be simple:  All it's doing now is transforming a's world coordinate frame into b's local coordinate frame, so that a is always +/- w/2 from b.  But it does assume that they're at least both using the same origin (0).  Since in your case they're not, you'd need to further correct for that transformation, here's one easy way:

a -= minX; // put a's origin back at 0
a += ...// the existing half-span origin transform
a += minX; // put a's origin back where it was
return lerp(...

Similarly, if your usage gets weird enough to slide b off 0 origin then you may have to correct b also, it's hard to guess.  The question to always ask is:  how do i get a's coordinate in terms of a b-centered coordinate frame?  (and then put it back afterwards)  In such a coordinate frame, the shortest distance from b to a will always be in the right direction.

And if as you show, b's coordinate system is 400 units wide while a's is only 300 units wide, then you'll potentially even want to add a scaling factor in there (400/300ths) or you'd be lerp'ing across the wrong range.  Sorry, that's about as clear as I can be without understanding the use.  Suggested approach:

putAandBinACommonCoordinateSystem();
wraplerp(a,b,t, commonCoordinateSystemModuloBase);
putAandBbackInTheirOwnCoordinateSystems();