What Kwyrky said, but Monogame does all this for you in Vector2. You can just set the components, then normalize the vector.
float speed = 100; // pixels per second
Vector2 dir = Vector2.Zero;
dir.Y -= 1;
... // and so on... modify dir per your input so that it will result in X and Y being either -1, 0, or 1.
if (dir != Vector2.Zero) // Not sure off the top of my head if dir.Normalize() handles 0,0 already... easy to check :D
dir.Normalize(); // This will normalize your direction vector to a length of one... which you can now multiply by your movement speed.
_position += dir * gameTime.Elapsed.TotalSeconds * speed;
I might have gotten a variable wrong or two in here, but hopefully you get the idea
LoadContent is only called once on startup, so setting your sprite to an initial position of zero wouldn’t be the cause.
If I had to guess, it would be that your move puts the sprite in a position off the screen. You can verify this by setting a breakpoint in the Draw method, where you draw the sprite, and verifying the value of _position for the SpriteBatch.Draw call.
What you don’t show here is how you use dir to calculate your new position. It may help for you to both take a look at that, and post your code here
Here is the update code I currently have, I noticed that if I changed the Vertor2.Zero to Vector2.One my sprite appeared but didn’t respond to inputs and was moving very slowly towards the bottom right of the screen, very odd
protected override void Update(GameTime gameTime)
var dir = Vector2.Zero;
dir.Y -= 1;
dir.Y += 1;
dir.X -= 1;
dir.X += 1;
var deltaTime = (float)gameTime.ElapsedGameTime.TotalSeconds;
_position += dir * speed * deltaTime;
Yea, but keep in mind that speed is just a movement in pixels per second. Maybe take a minute to look over the code and understand how it works. You may want to use a different movement speed depending on your needs
Having a NaN returned when you try to divide by zero is very useful for debugging. If you are trying to normalize a zero length vector in your code then your logic has a flaw in it. This is especially the case when you have a vector that you assume is never zero length. Either your assumption is wrong or the code creating the vector is wrong. In either case, the NaN alerts you to the bug and makes it easier to track down and fix.