C'est une question que je trouve très intéressante...
Le fait que le curseur soit fixé au centre de l'écran, et que ce soit l'environnement qui est en mouvement n'est pas gênant en soit puisqu'il est possible cependant de simuler des déplacement "absolus", a partir du moment ou le curseur revient systématiquement au centre de l'écran après chaque action : sera pris en compte uniquement le nombre de pixels parcourus durant le déplacement.
Le problème c'est que dans un FPS on cible des objets en 3D, la distance en pixels du curseur (crosshair) à l'objet ciblé n'est pas forcément égale à la quantité de mouvement en pixels à simuler pour atteindre la cible : puisque celle-ci n'est pas fixe relativement au curseur, elle se déforme en raison de la variation de l'orientation 3D, de plus cela dépend aussi de l'accélération de la souris configurée par le jeu vidéo et par Windows dans certain cas, qui fait varier les angles parcourus en jeu, et aussi tout naturellement de la vitesse de déplacement de la cible en question.
Quelques petits screenshoots pour illustrer le problème, pris sur un jeu tout à fait pourri mais qui a tué l'ennui de nombreuses de mes soirées glandouille...
Je commence par cibler un objet, ici il s'agit d'une lampe suspendue au plafond :
Loading Image
En vert est représenté la distance véritable séparant à cet instant le crosshair de la cible, qui fait 110 pixels ici, et en orange le mouvement de souris suffisant à atteindre la lampe, qui est légèrement plus court.
Pour se déplacer de notre position initiale à celle-ci qui pointe parfaitement sur la lampe :
Loading Image
On s'est déplacés d'un angle de 17° pour pouvoir pointer la lampe.
Il apparaît clairement qu'a cause de l'accélération souris et de l'orientation 3D la distance réelle nécessaire au déplacement du curseur vers la cible et celle mesurée sur l'écran sont très différentes.
Une solution à ce problème peut-être approchée en créant un algorithme vérifiant dynamiquement la position relative de la cible par rapport au curseur et modulant progressivement le mouvement de manière à s'en approcher progressivement.
Cette méthode soulève plusieurs obstacles :
- Les effets d'ombrage et la variation des teintes dues à la 3D rendent difficile le ciblage dynamique des pixels, surtout avec AutoIt
- La simulation des déplacements sous AutoIt exige de connaître la position d'arrivée ce qui implique de partir systématiquement d'une position centrale
Sauf erreur, je pense que c'est la manière dont fonctionnent les aimbots pour FPS...
Ça a l'air sacrément tordu à torcher en tout cas.
Sinon bonne année 2013, je suis en train de me mater le Seigneur des Anneaux un bon jus de fruit en main, le pied quoi.