From memory and sort of pidgin coding C:
void Object::SetUpMove (rect A, rect B, unsigned int cycles){ xSlope = (float)(B.x - A.x)/(float) cycles; ySlope = (float)(B.y - A.y)/(float) cycles; origx = A.x; origy = A.y; NumCycles = 0; // start counter at zero MaxCyles = cycles; }xSlope and ySlope are member floats of the class as MaxCycles and NumCycles are unsigned int members. I probably set a flag in there specifying that there an active animatiion/move going on.
On each pass to update, I'm assuming that some sort of timing control is goin on I call a function I called Click() against all objects that tells them to check for active animation/moves/whatevers and to do what the object is supposed to do.
bool Object::Click(){ if (!action) return false; // checks for other actions // if it shows a linear move...... xpos = origx + (int)(xSlope * NumCycle); ypos = origy + (int)(ySlope * NumCycle); NumCycle++;}This approach relieved me of trying to base the y position on the x position for each cycle and eliminated the trig functions.
The directive to draw the object on the screen comes after all objects have been updated.
As I say, a bit simplistic but it works for my purposes. When it comes to actually doing more precise timing on it I'd likely work out a means of determining 'cycle' to be based on the tic count since starting divided by the total number of tics it should take to get to point B.
