Hi, all.  My first post so go easy on me.

I am modifying the sprite engine from xnaresources.com to have animations for diagonal movement (upleft, upright, downleft, downright). 

My first instinct to account for upleft movement would be this:

 

 

if (gs.ThumbSticks.Left.X < -.5 && gs.ThumbSticks.Left.Y > .5)

 

However, this is inadequate.  Because if the thumbstick is moved just slightly to the upleft (still less than .5 on both ends), it will just stutter and nt move anywhere.

The correct answer would be to cut the area of thumbstick movements into pie slices.

But I'm not sure how to represent that mathematically.  I'm sure it wil use "pi" in there somehwere.

To add another level to this, I'd also like to add 8 directional sprite animations for tiptoeing and running.

Tiptoeing would occur if the thumbstick was moved in any direction .25 or less

Running occurs when the thumbstick is as far as it will go.

Along with normal walking, tiptoeing and running cut the area into three more circles.

Here is a crude graphic to make this clearer:

<img src="http://www.partycapers.com/images/thumbstick.gif">

The inner circle would be tiptoeing, the middle walking, and at the very end is running.  Each pie slice is one of the eight possible directions.

So hopefully someone who is better at Math than I can help with this.

try:

if (gs.ThumbSticks.Left.X < 0 && gs.ThumbSticks.Left.Y > 0)


to get "pie slices":
const float MOVE_BUFFERT = 0.2f //Will make the analoge less sensitive

if (gs.ThumbSticks.Left.X > MOVE_BUFFERT)
{//Right
    if (gs.ThumbSticks.Left.Y > MOVE_BUFFERT)
    {
        //NorthEast movement
    }
    else if (gs.ThumbSticks.Left.Y < -MOVE_BUFFERT)
    {
        //SouthEast movement
    }
    else
    {  
          //East movement
    }
}
else if (gs.ThumbSticks.Left.X < -MOVE_BUFFERT)
{//Left
    if (gs.ThumbSticks.Left.Y > MOVE_BUFFERT)
    {
        //NorthWest movement
    }
    else if (gs.ThumbSticks.Left.Y < -MOVE_BUFFERT)
    {
        //SouthWest movement
    }
    else
    {  
          //West movement
    }
}
else
{//No horizontal movement
  if (gs.ThumbSticks.Left.Y > MOVE_BUFFERT)
    {
        //North movement
    }
    else if (gs.ThumbSticks.Left.Y < -MOVE_BUFFERT)
    {
        //South movement
    }
    else
    {  
          //No movement
    }
}

Vector2 thumbstick = gs.ThumbSticks.Left;

if (thumbstick.Length() > 1)
    thumbstick.Normalize();

float length = thumbstick.Length();

length will tell you how far the thumbstick has moved away from its resting place. You can compare that with you thresholds.

 

 

 

 

 

Dapper,

This is how I accomplished 8 directional movement with Joystick.  This took me a while to work out but it works very well.
You'll note that My If Thens determine all eight directions of stickangle and then run my various directional animations for my player.

I originally got this concept from Nick Gravelyn and his Tile Game Video Tutoriols.  I've just highly modified the concept.
I felt it was much easier to work with Mathhelper.ToRadians(degrees) since it's easier to think of a circle as 0 to 360.  When you dump all of the Pi crap it's a lot easier to grasp directions around a circle.

Hope this helps and I hope my code comments make some sense.  Think of a circle in two halves from 0 to 180 starting on the far right swinging up to 90, then far left to 180.  And then 0 to -180 on the bottom half again starting at 0 on the far right swinging down to -90 and far left to -180.  Then it's just a matter of checking degrees of your stick angle against those numbers.

You can see videos of this in action at my website.
www.xnascratch.com

If you just want to know which of the 8 directions you are going in this can be accomplished with the following:

float radians = (float)(Math.Atan2(thumbstick.Y, thumbstick.X));

float angle = radians * 180.0f / Math.PI;

int direction = ((int)((angle + 22.5f) / 45.0f)) & 7;

 

direction will give you an integer that tells you which of the 8 directions you are going in.

NOTE: You could probably do all this in radians but I find it easier to use degrees.

Dapper Swindler:

I am modifying the sprite engine from xnaresources.com to have animations for diagonal movement (upleft, upright, downleft, downright). 

My first instinct to account for upleft movement would be this:

 

 

if (gs.ThumbSticks.Left.X < -.5 && gs.ThumbSticks.Left.Y > .5)

 

However, this is inadequate.  Because if the thumbstick is moved just slightly to the upleft (still less than .5 on both ends), it will just stutter and nt move anywhere.

Maybe I'm just being dense, but I'm not entirely sure what the problem is.  When I implemented diagonal movement of sprites, I used essentially the same code, but I used a lower threshold of 0.3.  It worked perfectly, as far as I could tell.  As long as the stick was moved more than marginally in a diagonal direction, the sprite moved diagonally.  I wouldn't want the threshold to be too low, otherwise the player could find themselves moving diagonally inadvertently because they didn't hold the stick precisely in one of the cardinal directions.

Another option would just to check for movement to the left and right and up and down seperatetly. Then you'll move diagonally when the X and Y direction both have values.

Vector2 mMovement = Vector2.Zero;

if (gs.ThumbSticks.Left.X < -thumbStickThreshold)
{
       mMovement.X = -3;
}
else if (gs.ThumbSticks.Left.X > thumbstickThreshold)
{
      mMovement.X = 3;
}

if (gs.Thumbsticks.Left.Y < -thumbStickThreshold)
{
    mMovement.Y = -3;
}
else if (gs.ThumbSticks.Left.Y > thumbStickThreshold)
{
   mMovement.Y = 3;
}


mSprite.Position += mMovement;


Wouldn't that be the simplest way to support all 8 directions of movement?  (I apologize for any syntax errors, I just manually typed the code so you could see the concept).

George,

That would work if there was no accompanying animation.  However, if your sprite had a diagonal animation, your method would not call it.  In my code, I tell the game which sprite to draw/animate based on the direction the sprite is moving in; checking for X and Y seperately would break that.

But couldn't you check the Movement variable and play the appropriate animation? I'm just think it would be easier to check at that point then to have convoluted code messing with all 8 thumbstick directions.  Once you have the movement (with nice round numbers), it should be a simple thing to check and see if X isn't 0 or if y isn't 0 then you know you need a diaganol animation, etc.

Just seems a bit cleaner that way to me.

Thank you all for the swift replies.  I will try them out and post the results.

Okay, I tried Allan Chaney's code and it works great for the most part.

The problem occurs when I implement running and tiptoeing into the thumbstick length.

If thumbstick.Length() < .25 -> tiptoeing
If thumbstick.Length() >= .25 && < 1 -> walking
If thumbstick.Length() == 1 -> running

You can't run diagonally. I'm sure the reason for this is that when the thumbstick is tilted fully to any diagonal direction than neither the X or Y is 1.  This would work if the thumbstick moved in a square and our animation areas were triangles.  But the thumbstick moves in a circle area and our animation areas are pie slices.  Technically, this would also affect the tiptoeing area, but it's too subtle to notice.

Yep, that's true. If you tilt it diagonally it will only give a value of around x0.75, y0.75. But you can actually cut up the hand controller around the analog stick and get higher values, and people do this to cheat and move faster in some games, something to think about as creator.

There's no need for computationally expensive atan2 or sqrt (in .Length()) for any of this.

You don't even need to know nor care what the actual joystick values are in this situation - all you care are that two things always hold true :
1) that you have the same travel along both axes in both directions
2) that the values interpolate from edge of control to center for both axes congruently

Graphing this gives you straight lines, which means that all you really need to do is check slopes - Y/X. When X is 0, you have a vertical line (meaning your sprite faces up or down); conversely, when Y/X == 0, you have a horizontal line (meaning your sprite faces left or right).

So:

It's important to note that the code above assumes you're working in the screen coordinate space, where +Y points down, not up, though that's an easy adjustment to make if necessary. Something you may want to do, period, is zero out input values with a length less than, say, 0.2 or 0.3. This will make a deadzone where the player will have a non-frustrating time with their on-screen player spinning around as they let go of the thumbstick.

Lots of helpful suggestions for dividing the thumbstick into 8 directions.  But I'm still perplexed on how to test for running that only occurs when the thumbstick is pressed all the way in any direction.

If all else fails, I may just go with running when Thumbstick.Length() >= .75.  That should cover every angle in the circle area of the thumbstick.

That's a fine idea, but you want to avoid calling .Length() as much as possible, as it invokes an expensive square root calculation. Since you already know that the input values range [-1,1], you could also test if Math.Abs(input.X) or Math.Abs(input.Y) > 0.6f . I'm not one to be paranoid, and if you were targeting Windows and not XBox360, I'd not say anything, but on the 360, you want to avoid as many float calculations as you can get away with.

Pfhoenix:

That's a fine idea, but you want to avoid calling .Length() as much as possible, as it invokes an expensive square root calculation. Since you already know that the input values range [-1,1], you could also test if Math.Abs(input.X) or Math.Abs(input.Y) > 0.6f . I'm not one to be paranoid, and if you were targeting Windows and not XBox360, I'd not say anything, but on the 360, you want to avoid as many float calculations as you can get away with.

Is this true?  I'm not syaing it's not.  I just don't know.  I thought given today's GPUs and CPUs it was a legacy myth that floating point calcs were slower than other calcs.  That was certainly the case in my early days of game development in the 80s but I thought we were over that.  I thought evolving CPU and GPU tech had made float calc concerns a thing of the past.

Pfhoenix,

Is there somewhere that documents how using math functions or float calculations are slower than numerous If Then loops in C# and XNA on the 360?

If so, where can I find that info?

It was my understanding that the 360 has a very impressive modern GPU and a Triple Core CPU.  I figured floats and math would be no problem for the 360.

Am I wrong in that thought?

Thanks
Allan

Allan Chaney:

It was my understanding that the 360 has a very impressive modern GPU and a Triple Core CPU.  I figured floats and math would be no problem for the 360.

The 360 runs the Compact edition of the .NET framework, which mostly targets PDAs and phones. It makes sacrifices in speed for gains in power consumption, etc. While the underlying Xbox CPU(s) should certainly be able to handle the math, it's the framework in between that is not optimizing the CPU calls.

That being said, it's not as bad as everyone seems to believe. It really only rears its ugly head when there is a lot of looping every frame, like running a particle simulation entirely on the CPU. A square root calculation every frame won't register.

Yes, you shouldn't sweat three float operations per frame. You should sweat, however, 30 done in a loop (matrices can drastically increase the number of float ops). You should *especially* sweat using expensive trig ops when unnecessary, as a bool check will always be faster than a float calculation. Will you notice one sqrt versus two or three bool evals per frame? If it's just that, then not likely, but I personally like to ensure that my code is as fast as is reasonable given the time taken to optimize. It's a *really* easy optimization that allows you to then recalculate maybe hundreds of facing sprites per frame without worrying about that sqrt.

Pfhoenix,

Sounds good.  Given that...What would be the best way to determine the direction a sprite is traveling regardless of input method?

In other words, if I want to make comparisons to the direction my player character is traveling and change things about the player or things around him.

If (player is moving north) then
If (player is moving south) then etc. etc.

I've seen this example but it seems computationally expensive not too mention kind of hard to understand and of course you would be doing this on every frame:


Is there a better way?

Thank
Allan

Dapper,

I see what you're saying.  My method doesn't account for analog variability along the stick when choosing which animation to draw.  It's either on or off which seems to defeat the whole point of going analog at least as far as choosing different subtle animations that may reflect speed.

That's unfortunate..... 

I sure would like to see some better ideas for movement where you can account for analog variability and change animations based upon that variability.

Allan

Same thing applies to this examples as well:


There is no variabiliy for analog.  It's either on or off.

There must be a better way.

Allan

Allan Chaney:

There is no variabiliy for analog.  It's either on or off.

So what? Are you limited to solutions of 3 lines or less? Use that sample if it suits you for identifying direction, then take the length of the thumbstick and measure it afterwards.

For the running thing, just allow running to be active at a lower value like length > 0.7f. You can code for players who carve their controllers, if that is your choice, by normalizing the thumbstick and then multiplying it by a scalar decided by TipToe, Walk, Run. All of these examples have been exactly that... examples, it's OK to modify them to better suit your individual need.

Mr. Leebo,

Huh?

I never said I was concerned with the number of lines of code.  

I certainly didn't intend to sound derogatory about that code.  I was just noting that those 3 lines return absolute values.  

Since one of those examples above is my example and it has more than 3 lines of code......whatever.

But I get your point about carving out length after you've determined direction.  That's very useful.

Thanks

Allan

It sounds like you should just be looking at a Vector2 Velocity value, inspecting the components to know where the object is moving, but if what you really want to know is how fast an object is moving in relation to the direction it is facing, you could take a Vector2 representing the facing direction of the object and do:


You'll see that I went with a dot product here - heavens! My reasoning is that Velocity isn't tied to cardinal directions, in which case for proper results, you have to suck up the float ops on this. However, if your Velocity is tied to the same cardinal directions as the object facing direction, you can very easily do:


The value 0.707107f comes from x^2+y^2=1 for a circle and having x == y (a right triangle with equal length sides, not hypotenuse) breaks that down to 2*x^2=1, which is x^2=0.5f, so sqrt(0.5) is ~0.707107. This will make your movement rate the same whether the object is moving diagonally or not.

Note that the facing vectors above are a Vector2 here. If you represent object facing as a single number, you'll need to convert the cardinal direction value to a Vector2 similar to:

Thanks, I will give this a try