Nice example!

Hope you're okay with some rambling because I've got some notes about diagonal movement: it's generally a good idea to watch out for your diagonal movement speed. Moving along the x or y axis alone both provide the same player speed, but if you're moving on x and y at the same time, then the resulting diagonal movement vector comes out longer than intended. It actually turns out to be a pretty significant difference if we use the Pythagorean theorem to check:

Length of axis-aligned movement (x=0, y=1)
=
sqrt(0^2 + 1^2)
=
sqrt(0 + 1)
=
sqrt(1)
=
1

_________________

Length of diagonal movement (x=1, y=1)
=
sqrt(1^2 + 1^2)
=
sqrt(1 + 1)
=
sqrt(2)
=
1.41

So by default, diagonal movement is almost one-and-a-half times as fast as your intended speed! This is fine for non-time-sensitive games, but it can be a noticeable problem in action games, because it means that moving diagonally gives you an unintuitive (and very-video-gamey) speed advantage.

To fix it, you can do the following, or something similar:

// tunable max speed, in any aribtrary direction
speed=2

// default state for frame: no movement
// these are "input x" and "input y" values:
ix=0
iy=0

// offset input x/y to represent buttons held
if (btn(0)) then
  ix-=1
end
if (btn(1)) then
  ix+=1
end
if (btn(2)) then
  iy-=1
end
if (btn(3)) then
  iy+=1
end

// THE IMPORTANT PART:
if (ix*ix+iy*iy>1) then
  // movement vector is longer than 1 unit!
  // normalize it:
  dist=sqrt(ix*ix+iy*iy)
  ix/=dist
  iy/=dist
end

// finally, apply the input direction to the player
x+=dx*speed
y+=dy*speed

In the case of 8-direction movement, the diagonal vectors always end up being (0.707,0.707) with optional negation for each axis. This is because 0.707 is the square root of 0.5:

length of adjusted diagonal movement (x=0.707, y=0.707)
=
sqrt(0.707^2 + 0.707^2)
=
sqrt(0.5 + 0.5)
=
sqrt(1)
=
1

this might be helpful

https://www.lexaloffle.com/bbs/?tid=29123