View more

View more

View more

### Image of the Day Submit

IOTD | Top Screenshots

### The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.

# [C++] Delayed action of srand() - coordinates for object

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

23 replies to this topic

### #21slicer4ever  GDNet+

Posted 22 November 2012 - 09:40 AM

Wrong again. It should be:

if(abs(ballposition.x-balltarget.x)< ballspeed || abs(ballposition.y-balltarget.y)< ballspeed)
{
balltarget.x = (rand() * 100) % SCREEN_WIDTH;
balltarget.y = (rand() * 100) % SCREEN_HEIGHT;
}

umm....no? (seriously, i'm trying to figure out why you think this would work, am i missing something?)
Check out https://www.facebook.com/LiquidGames for some great games made by me on the Playstation Mobile market.

### #22SuperVGA  Members

Posted 22 November 2012 - 09:53 AM

I guess if you really intend to use "manhattan units" how about using
   if( ( abs(ballposition.x-balltarget.x) + abs(ballposition.y-balltarget.y) ) < (ballspeed * 2) )
{
balltarget.x = rand() % SCREEN_WIDTH;
balltarget.y = rand() % SCREEN_HEIGHT;
}


But as it seems to be about a ball, I feel inclined to suggest that you just use an actual velocity vector,
the root of the squares of dX and dY added. (Or don't do the root but work in squared units, if you can/want to.)

Even better, you could use a 2d vector struct
struct 2dmotionvector
{
float dx;
float dy;
float len;
float angle;
}

To define your velocity, and work with that instead of having only independent x and y speeds to deal with.
-You can use len and angle primarily, and then set dx and dy if you need it in later statements.
(What if you apply spin to the ball, or it bounces off a surface? Way easier with 2d vector math on composite types in my opinion)

Edited by SuperVGA, 22 November 2012 - 10:54 AM.

### #23Trienco  Members

Posted 22 November 2012 - 11:27 PM

Well, L.Spiro has a version that will at least trigger at all (when one coordinate is getting close enough), while the other version looks like in the end the ball will reach one coordinate first, then start jittering around on one axis, move only along the other axis and finally find a new destination. It also means that if one coordinate is reached, the balls will effectively move at only half the speed.

So obviously I second the approach of using vectors, simply because the other code only allows for 45° steps in motion and I doubt that sudden changes of direction while heading towards a destination are intended.
f@dzhttp://festini.device-zero.de

### #24L. Spiro  Members

Posted 23 November 2012 - 02:08 AM

umm....no? (seriously, i'm trying to figure out why you think this would work, am i missing something?)

My version is based on the logic in his first post. “If both coordinates move by over 300 units, generate new coordinates, but if only the X or the Y moves by over 300, that is fine.”

For his revision I only didn’t notice that he had switched from > to <, which achieves the correct results.

Comments would go a long way here. Don’t be afraid; they don’t bite. I really couldn’t look too terribly closely because there is not a single comment anywhere, although the code I “corrected” was small enough that I could have paid more attention there.

I still don’t really understand the goal behind the code, and again I would insist on using vectors. Makes everything simple.

L. Spiro

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.