Hi, so I was just wondering how I would be able to find the direction that my sprite is facing? The reason I would be trying to do this is so I can make him eventually move in the direction that he is facing. So if anyone can help me I would really appreciate it.
At 7/1/12 05:18 PM, PandaexpressMan wrote: Hi, so I was just wondering how I would be able to find the direction that my sprite is facing? The reason I would be trying to do this is so I can make him eventually move in the direction that he is facing. So if anyone can help me I would really appreciate it.
Is this something like a spaceship? Or is it a spritesheet character similar to the way Mario is?
At 7/1/12 05:18 PM, PandaexpressMan wrote: Hi, so I was just wondering how I would be able to find the direction that my sprite is facing? The reason I would be trying to do this is so I can make him eventually move in the direction that he is facing. So if anyone can help me I would really appreciate it.
It would be helpfull if you are explaining in what context you are too. Do you inherit your sprite from controlers, and if you do, which one? Also ditto the question of the guy over me.
Computer has no brain. DEAL WITH IT!
Stupidity is a dangerous and contagious disease. It can happen to you. It can happen to me
At 7/1/12 05:18 PM, PandaexpressMan wrote: Hi, so I was just wondering how I would be able to find the direction that my sprite is facing? The reason I would be trying to do this is so I can make him eventually move in the direction that he is facing. So if anyone can help me I would really appreciate it.
Assuming the game is 2d, you need to do the following things:
1. Find the angle at which your sprite is
2. Implement the following algorithm (I don't know the actual syntax for this in c#, but I'll explain it)
DistanceToMoveX = Speed*Cos(Angle)
DistanceToMoveY = Speed*Sin(Angle)
Sprite.x += DistanceToMoveX
Sprite.y += DistanceToMoveX
So, what this does, is takes a "speed" value (Which would be the overall velocity of your sprite) and multiplies is by Sin and Cosine of the sprite's angle. This means that (stored in a new variables) you have the actual amount that your sprite will move in both the x and y directions, so you add these values to the sprite's current position. (These values can be negative, hence why we always add).
And also, just as a side note, with anything to do with movement within a game, you should multiply the movement speed by "Deltatime" (The length of time between two frames). This would mean that regardless of what FPS your game runs at, a character would still move the same distance in a set period of time. You can implement this in the above algorithm as follows:
DistanceToMoveX = (Speed*DeltaTime)*Cos(Angle)
DistanceToMoveY = (Speed*DeltaTime)*Sin(Angle)
Im not sure if c# (Or whatever API, libraries etc) has a built in deltatime function, but if it does you should definitely use it. If not, do some research and make your own, its pretty vital :P
Hope this helps, if you need anything else drop me a line!
At 7/7/12 04:38 PM, StrikerF2 wrote:At 7/1/12 05:18 PM, PandaexpressMan wrote: Hi, so I was just wondering how I would be able to find the direction that my sprite is facing? The reason I would be trying to do this is so I can make him eventually move in the direction that he is facing. So if anyone can help me I would really appreciate it.Assuming the game is 2d, you need to do the following things:
1. Find the angle at which your sprite is
2. Implement the following algorithm (I don't know the actual syntax for this in c#, but I'll explain it)
DistanceToMoveX = Speed*Cos(Angle)
DistanceToMoveY = Speed*Sin(Angle)
Sprite.x += DistanceToMoveX
Sprite.y += DistanceToMoveX
So, what this does, is takes a "speed" value (Which would be the overall velocity of your sprite) and multiplies is by Sin and Cosine of the sprite's angle. This means that (stored in a new variables) you have the actual amount that your sprite will move in both the x and y directions, so you add these values to the sprite's current position. (These values can be negative, hence why we always add).
And also, just as a side note, with anything to do with movement within a game, you should multiply the movement speed by "Deltatime" (The length of time between two frames). This would mean that regardless of what FPS your game runs at, a character would still move the same distance in a set period of time. You can implement this in the above algorithm as follows:
DistanceToMoveX = (Speed*DeltaTime)*Cos(Angle)
DistanceToMoveY = (Speed*DeltaTime)*Sin(Angle)
Im not sure if c# (Or whatever API, libraries etc) has a built in deltatime function, but if it does you should definitely use it. If not, do some research and make your own, its pretty vital :P
Hope this helps, if you need anything else drop me a line!
C# doesn't have intrinsic functions for a 'deltatime', it has a TimeSpan class under the System namespace, which keeps track of different time intervals. However, your solution will only work because you're assuming that the player is a ship. If he is using sprite-sheet animation, then, unless he is going to get into buffers, you solution won't work.
Obviously, if the OP is using sprite-sheet animation, all he has to do is track which block of frames he is currently/going-to-be rendering. The 'right' set will walk in the positive x-axis direction, and 'left' the opposite.
At 7/8/12 10:18 AM, everette00 wrote: C# doesn't have intrinsic functions for a 'deltatime', it has a TimeSpan class under the System namespace, which keeps track of different time intervals. However, your solution will only work because you're assuming that the player is a ship. If he is using sprite-sheet animation, then, unless he is going to get into buffers, you solution won't work.
Obviously, if the OP is using sprite-sheet animation, all he has to do is track which block of frames he is currently/going-to-be rendering. The 'right' set will walk in the positive x-axis direction, and 'left' the opposite.
Yea, probably should have mentioned this is for a "top-down" approach, and nothing else, though the OP isn't too descriptive. It would be hell (and fairly pointless) to implement it in a side-scroller.
At 7/8/12 09:03 PM, StrikerF2 wrote: Yea, probably should have mentioned this is for a "top-down" approach, and nothing else, though the OP isn't too descriptive. It would be hell (and fairly pointless) to implement it in a side-scroller.
No, not necessarily. There are 2D side-scrolling platforming games that use a pivoting set of body parts for game play elements. For example, there was a 2D zombie shooting adventure that used pivoting arms for the aiming. That uses a slightly more complex version of what you provided, but it still uses something similar. And, it is used for directional movement of a sprite.
