Sprite Movement Angle Or Move To Specific Pixel

[motorollin]

Is it possible to specify an angle in degrees and a velocity for a sprite rather than X and Y velocities? Alternatively is it possible to make it move in a straight line towards a specified pixel?

 

[skeezix]

Depends on the system you're using for handling sprites. If you're coding it yourself you can do what you like. If you're using a sprite managemenbt library, it depends on that library.

You've not really given enough information to answer.

jeff

 

[motorollin]

Depends on the system you're using for handling sprites.

It's hand-coded using SDL - so my "sprite" is really just an image on a surface which gets pushed around the screen by changing its x and y velocities.

If you're coding it yourself you can do what you like.

Would you be able to point me towards an example? I have Googled but can't find what I'm looking for.

If you're using a sprite managemenbt library, it depends on that library.

Unless you're referring to SDL, I'm not.

 

[Squidge]

Of course you can do that, but the question would be why. Floating point maths on the gp2x never really gets you anywhere fast, so you would be better of with predefined routes for your sprites to follow, and it would be a lot easier to code.

 

[motorollin]

My sprite starts at a random position in the playfield and needs to move off at a random angle. When it hits one of the edges of the playfield it deflects back in to the playfield. Short of telling the sprite to move in a direction then when it gets to the edge changing the angle to 180-angle, I don't know how else to achieve this.

 

[Squidge]

http://en.wikipedia.org/wiki/Trigonometry

 

[motorollin]

I understand trigonometry. What I don't understand is how to use it in this situation. The only way I know how to move sprites is to change their x and y velocities. I don't know how to either specify an angle in degrees or calculate the correct x and y velocities given the angle in which I want the sprite to move. Any examples of this would be greatly appreciated. It's a matter of not knowing the correct C++/SDL functions rather than not understanding the theory behind trigonometry.

 

[charlieb]

Is it possible to specify an angle in degrees and a velocity for a sprite rather than X and Y velocities? Alternatively is it possible to make it move in a straight line towards a specified pixel?

Ok so what you're talking about is actually polar vs cartesian. A polar coordinate is a speed (scalar) and an angle (direction) and a cartesian is a vector with X and Y magnitudes that points at the target.
To actually plot the sprite on a cartesian grid you will need to use a cartesian vector but the real question is what *internal* representation to use.
Some other points:
Cartesians:
* Are easy to calculate with because all you have to do is add them to the sprite's position to get the next position
* You'll need to keep a floating point internal vector and round it when plotting the sprite on the screen or you'll likely miss the target because of fractional pixels.
* They are kind of annoying if you need the speed to vary because you'll need to keep a normalized direction vector and a speed.

Polars:
* Are really useful for tracking moving targets or doing smooth direction changes.
* You'll probably end up using them anyway if only for a tiny intermediate step.

I hope I have made things clearer not more murky!

charlieb

My sprite starts at a random position in the playfield and needs to move off at a random angle. When it hits one of the edges of the playfield it deflects back in to the playfield. Short of telling the sprite to move in a direction then when it gets to the edge changing the angle to 180-angle, I don't know how else to achieve this.

If your playfield is a rectangle this is really easy, just negativize the appropriate element of the vector, if you hit a vertical wall change the y = -y or x = -x for a horizontal.
Otherwise you'll have to start calculating normals and that's beyond the trig I can do off the top of my head.

 

[motorollin]

Calculating the angle of deflection is not the problem I am having. It's what code to use to actually make my sprite move in a specified direction instead of doing "x+=5;y+=5;".

 

[woogal]

Sprites are just things that you position with x and y coordinates. Usually there aren't any functions to position them any other way because you're supposed to create those yourself (why have an overly bloated lib that contains loads of functions most people will never use?). The majority of game coding is usually understanding maths rather than using functions, so you either need to use maths to work out how to create the x and y coordinates based on your input values or hope that someone else has done a similar thing before and there's code around online that you can adapt and use. Don't expect to find loads of functions in SDL for achieving the same end result in slightly different ways - the S stands for Simple.

 

[motorollin]

Understood - so still hoping for a good example of what I'm trying to do since I can't get my head around the maths.

 

[charlieb]

Calculating the angle of deflection is not the problem I am having. It's what code to use to actually make my sprite move in a specified direction instead of doing "x+=5;y+=5;".

So you mean somehting like this?
CODE

velocity = calc_velocity();
sprite.x += velocity.x;
sprite.y += velocity.y;
draw(sprite);

 

[motorollin]

So you mean somehting like this?
CODE

velocity = calc_velocity();
sprite.x += velocity.x;
sprite.y += velocity.y;
draw(sprite);

If calc_velocity() takes an angle in degrees as an argument, and then returns the necessary x and y velocities to make the sprite move in that angle, then yes. What that calc_velocity() function contains is what I can't get my head round :rolleyes:

 

[charlieb]

If calc_velocity() takes an angle in degrees as an argument, and then returns the necessary x and y velocities to make the sprite move in that angle, then yes. What that calc_velocity() function contains is what I can't get my head round :rolleyes:

Oh ok well that is really just basic trig:
CODE

x = speed * cos(angle);
y = speed * sin(angle);


Right guys?

 

[motorollin]

That works! Thanks
Now, to work out *why* it works, so I understand for next time...

Thanks again!

 

[mrsnature]

quick searchon google found this... there will be lots and lots of information on this subject on the 'net though

http://id.mind.net/~zona/mstm/physics/mech...gComponents.htm

That works! Thanks
Now, to work out *why* it works, so I understand for next time...

Thanks again!

 

[Sphinxter]

Is it possible to specify an angle in degrees and a velocity for a sprite rather than X and Y velocities? Alternatively is it possible to make it move in a straight line towards a specified pixel?

Tough achieving a perfect angle on a raster display or even fudge something near it, for example 15 degrees closest fit may be over 5 and up 2 pixels which would have to be corrected on a supercell basis every so often to keep it anywhere near the neighborhood of 15 degrees. That might be what is in your function.

 

[charlieb]

Tough achieving a perfect angle on a raster display or even fudge something near it, for example 15 degrees closest fit may be over 5 and up 2 pixels which would have to be corrected on a supercell basis every so often to keep it anywhere near the neighborhood of 15 degrees. That might be what is in your function.

This is why you should keep a floating/fixed point representation of the coordinates internally and round before plotting the sprite. You could re-calculate the vector every iteration but that would be more expensive (I would think)

charlieb

 

[Squidge]

Whatever you do, don't copy that code verbatim, it's meant as an example only. Hopefully your release code will use pre-computed tables.

 

[Sphinxter]

Tough achieving a perfect angle on a raster display or even fudge something near it, for example 15 degrees closest fit may be over 5 and up 2 pixels which would have to be corrected on a supercell basis every so often to keep it anywhere near the neighborhood of 15 degrees. That might be what is in your function.

This is why you should keep a floating/fixed point representation of the coordinates internally and round before plotting the sprite. You could re-calculate the vector every iteration but that would be more expensive (I would think)

charlieb


That would be irrational.