# How do you program diagonal movement?

I'm wondering how a diagonal element that moves along a diagonal path that hops at each tick of the computer clock is able to travel a greater distance along the screen than an element moving at each tick along left-right or up-down paths (since it's a square lattice and the diagonal element of a triangle is the same length of the two legs of a 45-45-90 triangle, or just take a square grouping of nine pixels, the diagonal is 3 pixels, and the left-right and up-down direction are 3 pixels also, a violation of the hypotenuse, but you can still measure the diagonal distance of a square pixel with a ruler), so things move faster along the diagonal, and you'd have to also take into account variations of lower angled paths that move at a lower angle diagonal (they still move faster than left-right elements). I'm wondering if that's a source of jitter in a character object that is composed of a large blob of pixels, has somebody already figured out a ratio in reducing the speed of the diagonal moving pixels while still maintaining the shape of the blob of the character moving.

• If you're looking for the ratio of the diagonal to the unit of travel along an axis, it's sqrt( 1*1 + 1*1) = sqrt(2) = 1.414... - can you clarify in more detail what you need answered here? – DMGregory Jul 24 '18 at 16:05
• Is your question "How to make diagonal movement in such a way to be equal to horizontal/vertical movement and not faster/slower?" ? – TomTsagk Jul 24 '18 at 16:12
• I'm saying that a diagonal object moves faster across the screen, so yes, because there should be no preferred orientation. My only guess to how to implement is like on those arduino screens, have the pixels on the computer monitor, not just immediately completely light up, but start from a slow fire and increase gradually, with the position of the diagonal ones, increasing slower. Also, that's probably not enough and you'd have to have smaller snaking motion of strings of pixels moving through the collection of fire pixels from a slow ember embedded and moving among them (the snake lines). – Winterstorm D Jul 24 '18 at 16:18
• The snake lines or something else would be used to create distortion of the object because it would need to be distorted along the diagonals during diagonal motion. – Winterstorm D Jul 24 '18 at 16:24
• In addition to what Arcane Engineer said-- If you are asking about reducing jitter for movement in low resolution games, then you can look into the staircase effect, solution here: gamedev.stackexchange.com/questions/18787/… – Kyy13 Jul 24 '18 at 17:58

Vector mathematics is used to create motion in nearly every game these days. Said method uses fractional values typically calculated using floating-point or fixed-point arithmetic representations.

DMGregory correctly points out that sqrt( 1*1 + 1*1) = sqrt(2) = 1.414. So if you are moving an object by 1 pixel in both x and y each frame, then yes, the total distance travelled is roughly 1.4 units. But that's not the way we typically move things in games (these days) as pixels are no longer the primary basis for calculation of movement in most cases; and in any case, this approach was always wrong if you were then only moving 1.0 pixels in either x or y.

Instead, regardless of the direction being moved, a direction vector is always normalized before being multiplied by some scalar speed. Normalization means that we divide a vector's components (x, y) by the vector's overall magnitude, resulting in a magnitude of 1.0. So in our given case, a diagonal vector of length / magnitude 1.414 will have each of its components of length 1.0 divided by 1.414 resulting in absolute x and y values (talking about 2D here) of about 0.707 which results then in a vector magnitude of 1.0 rather than 1.414. You can see, on the other hand, how if a vector (1.0, 0.0) is normalized, it still has a magnitude of 1.0.

And no, you don't notice any jitter moving on the diagonal compared to moving on the horizontal or the vertical, especially on today's high-resolution displays; if that were ever the case, it may have been so in the days of 320x200 or lower resolutions, but even there, the human eye doesn't tend to pick such things up that easily, being more absorbed in the smoothness of the motion itself.

• Also, if there is antialiasing, I doubt jitter would be noticeable even for low resolutions. – Ocelot Jul 24 '18 at 17:30
• I noticed it in a cellular automata in Golly, that things propagate based on neighbor-neighbor, including diagonals which should be further away, but they're closer than they should be in determining -on screen- what cells should be on or off ie there's a disconnect with the theoretical model and what on-screen is happening, because especially things like compression software that records videos in a lossy format, it doesn't assume a square lattice, but normal space where motion (if it occurs as a larger coherent shape when zoomed out in Golly) doesn't have diagonals going faster, so the – Winterstorm D Jul 24 '18 at 19:16
• the compression software alters how the automata looks compared to the original. Golly software: golly.sourceforge.net – Winterstorm D Jul 24 '18 at 19:16
• @WinterstormD You do realise that most people here (including myself) don't know what Golly is? Perhaps link to it in your question. – Engineer Jul 24 '18 at 19:18
• I meant to say that there should be more squares bunched up in the diagonal squares if there's going to be correlation with movement in the real world or making any sense on screen with what's happening. – Winterstorm D Jul 24 '18 at 19:24

It sounds like you are trying to make the grid based algorithms of cellular automata match a real world concept of space. While the two worlds are quite different spatially you could try to balance the weights of diagonal cells by multiplying them by the normalized difference in distances as described by Arcane Engineer. (ie. scaling the propagation rate by .707)

• I'm thinking that since the diagonals propagate faster in real space (since the ruler measure of a diagonal automata cell is longer than the edges), to have the cells gradually increase to on, and gradually decrease to off, with the vertical-down and left-right, having a faster "turning on" or "turning off" to match the diagonal, when viewed as zoomed out in real space ("the effect"). When recorded in lossy video compression, the one I have now causes multiple small rotations everywhere, due to it picking up periodic behavior in the randomly flickering automata (an explosive rule). – Winterstorm D Jul 24 '18 at 22:01
• But having the vertical-down and left-right turn on or off faster, and since it more matches the diagonal speed, there is still oscillation in the automa I made, and then when video recorded, it has to pick up oscillation elsewhere (probably in larger groupings of the space) rather than picking up the small oscillator I have in the automata. This would be similar to ying-yang fire automata which is a 2d oscillation from a variable range from 1-10 of the degree of brightness of a cell, and rules based on which cell is lit. Here, if a cell turns on directly above another cell, it becomes on – Winterstorm D Jul 24 '18 at 22:04
• ... it turns on faster, since it's in the vertical direction and you're trying to create now a "jump" in large groupings of cells in the vertical or left-right as opposed to "jumps" along diagonals which naturally occur when you view it from a zoomed out position due to the cells having a longer distance along the diagonal of any individual square cell in the grid. – Winterstorm D Jul 24 '18 at 22:09
• So now you have overlap in large groupings of cells in the vertical or horizontal, which is similar to the mixing equation in a gas automata (a void in the gas automata that closes in and mixes). But since the vertical-down and left-right match the diagonal, it's really more like a hexagonal lattice now, so that a hexagonal lattice usually uses probability in deciding collisions, whereas this has probability embedded in it naturally, so it doesn't have to select error prone computationally produced "random numbers" anywhere to decide a collision. – Winterstorm D Jul 24 '18 at 22:19

You could accelerate the presentation of the cells in how they are presented -no change in underlying cellular automata rule ie the timing of presentation-, in certain directions, like vertical, with the horizont. no accel., and diagonal faster naturall to create larger rotations of pixels. Overlay that with one that has a faster presentation in vertical and horizontal, no faster presentation in diagonal (it already is fast) and you get fixed points. Now have a genetic algorithm mutating the two, and you should get those fixed points mixed in the larger clouds of rotation, and the large clouds getting caught up in something more complicated, -----no change in underlying rule---- in any subset of interacting ones in the genetic algorithm.