How do you program diagonal movement?

Question

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.

Answer 1

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.

Answer 2

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)

Answer 3

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.