А размер системного шрифта везде одинаков?

Ну, по крайней мере на моем ПК и в виртуальной машине одинаковый.

ПЫ.СЫ. Все, проблема решена. Остается, правда, загадкой, что это было. Понадобилось сменить разрешение в виртуальной машине. Сменил, и все заработало, смещение стало точно таким же. Вернул старое разрешение, и все равно все нормально работает. Уж не знаю, что это за глюк такой был. Остается только ноутбук у знакомого, где не работает так, как нужно, но это уже, по всей видимости, заскоки его машины. Ибо у других все нормально.
Большое спасибо. Благодаря Вам не только все заработало, но и стал лучше понимать, что к чему :-)

Думаю кнопку правую надо чуть погодя отпускать.

Да, спасибо большое. Действительно разброс, который в моем варианте наблюдался на некоторых ПК, был из-за этого. Так же, действительно, dpi никак не влияет на величину смещения.
Но... целиком справиться с проблемой все равно не получается. По крайней мере на одном ноутбуке (не моем) смещение без разброса, но другое. А еще попробовал в виртуальной машине. Там то же самое. Все работает, разброса нет, но смещение другое. В чем тут дело, пока непонятно. Но скрипт тут уже, скорее всего, ни при чем. Буду, все таки, пытаться пробовать с виртуальной мышью ОС.

	Sleep 50		; устраняет инертную прокрутку, возможно следует увеличить
	Click Right U

Думаю кнопку правую надо чуть погодя отпускать.

И что мешает использовать мой вариант?

Ничто не мешает, спасибо :-) Просто хочу понять, почему мой вариант не срабатывает.

Я в конец запутался... Ваш вариант, действительно, вообще никаким боком не зависит от dpi

И что мешает использовать мой вариант?

Но dpi же должно влиять.

Например из этой статьи я такого вывода не сделал.

Мало вероятно, но может от смены dpi, в программе меняется инертная прокрутка, в коде есть комментарий.
Я так понял при смещениях на 1 пиксель, dpi ни на что не вляет.

А зачем, если это такая же эмуляция.

А почему это понятно?
Проверил, dpi мышки никак не влияет на смещение, ведь оно задаётся от точки до точки.

Хмм... скорость курсора, да, действительно никак не влияет. Но dpi же должно влиять. Так как расстояние то одинаковое, а вот количество точек на этом отрезке разное. Более того. Я менял dpi мыши (благо на ней 3 разных переключаемых dpi) при использовании описанной мной выше конструкции. И таки смещение было разным.

Спасибо за пример. Надо переварить и попробовать. Но, боюсь, что на разных dpi тоже смещение может оказаться разным. Хотя, может, я чего-то и недопонимаю. А я пока, как альтернативный вариант, все никак не могу совладать с виртуальной мышкой. Что я делаю не так? Почему виртуальная мышь не видит нажатий клавиш нумлока с использованием Send в скрипте?

CoordMode, Mouse

Up::
Down::
Left::
Right::
	BlockInput, MouseMove
	ControlGet, hWnd, HWND, , Grym_MapView1, ahk_exe grym.exe
	WinGetPos, WinX, WinY, WinWidth, WinHeight, ahk_id %hWnd%
	MouseMove, WinX + WinWidth // 2, WinY + WinHeight // 2
	Point := A_ThisHotkey = "Up" ? "0 " -WinHeight // 2
			: A_ThisHotkey = "Down" ? "0 " WinHeight // 2
			: A_ThisHotkey = "Left" ? -WinWidth // 2 " 0"
			: A_ThisHotkey = "Right" ? WinWidth // 2 " 0" : "0 0" 
	SendPlay {Click 0 0 Right D Rel}{Click %Point% Rel}
	Sleep 50		; устраняет инертную прокрутку, возможно следует увеличить
	Click Right U
	MouseMove, WinX + WinWidth // 2, WinY + WinHeight // 2
	BlockInput, MouseMoveOff
	Return

А почему это понятно?
Проверил, dpi мышки никак не влияет на смещение, ведь оно задаётся от точки до точки.

MouseMove, X/2, Y/2  ;Перемещение курсора в центр окна
sleep, 500
MouseClickDrag, Right, X/2, Y/2, X/2, Y/2+200, 100  ;Смещение камеры до упора вниз
sleep, 500
	Loop, 600  ;Цикл дискретного смещения камеры по вертикали
	{
		MouseMove, X/2, Y/2  ;Перемещение курсора в центр окна
		MouseClickDrag, Right, X/2, Y/2, X/2, Y/2-1, 0  ;Дискретное смещение камеры по вертикали вверх
	}
sleep, 500
	Loop, 960  ;Цикл дискретного смещения камеры по горизонтали
	{
		MouseMove, X/2, Y/2  ;Перемещение курсора в центр окна
		MouseClickDrag, Right, X/2, Y/2, X/2+3, Y/2, 0 ;Дискретное смещение камеры по горизонтали вправо
		PixelSearch, MX, MY, X/2-20, 0,  X/2+20, Y/24, %CF%, 2, Fast  ;Поиск точки заданного цвета в заданной области
			if ErrorLevel = 0
				Goto, Block010  ;Переход к блоку зуммирования
	}		

В целях экономии времени и чтобы зрителю не приходилось видеть вращение камеры упертой в пол, или небо, я решил попробовать позиционировать камеру по вертикали без поиска маркера. Просто задать некоторую величину смещения относительно пола.
И вот тут я и столкнулся с проблемами.  Смещение зависит от dpi мышки, это понятно. Непонятно поведение команды MouseClickDrag, если я пытаюсь смещать камеру не дискретно, а сразу на заданный угол. Скажем, такая команда

MouseClickDrag, Right, X/2, Y/2, X/2, Y/2-600, 0

совсем не эквивалентна такому циклу:

Loop, 600  ;Цикл дискретного смещения камеры по вертикали
	{
		MouseMove, X/2, Y/2  ;Перемещение курсора в центр окна
		MouseClickDrag, Right, X/2, Y/2, X/2, Y/2-1, 0  ;Дискретное смещение камеры по вертикали вверх
	}

Если цикл постоянно точно выводит камеру на нужный угол, то разовое смещение дает непредсказуемый результат. Один раз повернет на один угол, в другой раз на другой.
Но так как смещение зависит еще и от dpi мышки, даже работающая на моем ПК конструкция не у каждого пользователя станет работать (хотя у многих и работает). В связи с этим вопрос. Возможно ли осуществить подобные манипуляции как нибудь еще?
Я решил попробовать с вируальной мышкой, из центра специальных возможностей в Winows, но напоролся на то, что моих знаний, судя по всему, катастрофически не хватает. Я даже не смог скриптом вызвать этот режим. Плюс, даже вызвав его вручную, виртуальная мышь все равно "не видит" нажатий клавиш нумлока скриптом. Она не переходит в заданные режимы и не перемещает курсор. Я пытался использовать команду send. Но, видимо, тут нужно иначе поступать. А как, не хватает знаний.