# 24 Directional Iso Movement

This topic is 2419 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

First off I have done about 3 days worth of searching and have not come across a solution to my problem.

I am currently working on an isometric 2D racing game (2:1 ratio). My problem is that I do not simply want 8 directions for movement. I would like to have 15 degree incremements for the sprite's rotation/movement.

I am trying to figure out the math behind making the vehicles move at the proper speed depending on their orientation. I was messing with sin/cos functions since the speed ratio is an oscillation depending on theta, such that when theta = 0 vehcile speed is at a minimum, at theta = 45 degrees the vehicle speed is at a maximum, and at theta = 90 degrees speed is again a minimum. Also, movement NE, NW, SE, SW must be twice as fast as movement in the N,E,W,S directions.

Does anyone have an idea on how to calculate the speed ratio for intermittent orientations (i.e. theta = 15, 30, 60 etc degrees)?

Thanks again

##### Share on other sites
Just out of curiosity, what is the reason for the weird speed oscillations? Are you trying to move the vehicles in screen space, rather than in world space where such transformations belong? Or is it for some other reason?

##### Share on other sites

Just out of curiosity, what is the reason for the weird speed oscillations? Are you trying to move the vehicles in screen space, rather than in world space where such transformations belong? Or is it for some other reason?

Well what I'm trying to do is calculate how fast the sprite should move in a given direction. So I suppose I am trying to move them in screen space. Given the 2:1 isometric view I am using, if a sprite moves with an orientation of 45 degrees (i.e. towards the top right of the screen) it should move faster than if moving with an orientation of 15 degrees (almost horizontal to the x-axis), this change in speed is what I am trying to calculate.

I hope this answers your question, and thank you for the response.

##### Share on other sites
Well, you can save yourself a lot of weird computation, and a throbbing headache, by not trying to move objects in screen space. Move them in world space (using normal vector/velocity calculations) then just transform them into screen space only when they are drawn. It's the way of sanity, my friend.

To be a little less terse:

According to my recent journal post on Iso games, you can operate in World space then transform to screen space. These are the equations I use in that article:

 // Function to convert a world position to a screen (view) position sf::Vector2f WorldToScreen(sf::Vector2f v) { return sf::Vector2f(2.0f*v.x - 2.0f*v.y, v.x + v.y); } // Function to convert a screen (view) position to a world position sf::Vector2f ScreenToWorld(sf::Vector2f v) { return sf::Vector2f((v.x+2.0f*v.y)/4.0f, (2.0f*v.y-v.x)/4.0f); }}