Discussion :

[tezec]

Bonjour,
c'est mon premier essai en c++. Une vrai débutante. Je surveille un pixel dans une appli de jeu de golf, et quand il change de couleur, je clique.
Le problème avec AHK ou vb c'est que il y a jusque 10ms entre la détection et le clic, c'est trop lent. On m'a dit que c++ va beaucoup plus vite
Mais visiblement c++ est très exigeant, je crois que j'ai trouvé les commandes et à peu près la syntaxe mais j'ai tout le temps des erreurs, je sèche

j'ai aussi lu que la méthode "while" est bourrin, que d'autres méthodes sont mieux, mais j'ai pas trouvé quoi

donc le lis le code RGB du pixel, j'enregistre le niveau de vert dans deux variables, puis dans une boucle je met a jour une des deux variables jusqu'à ce qu'elle diffère de l'autre, pour détecter le changement de couleur. J'utiliserai une touche pour lancer le script, genre ²:: en AHK

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
#include <conio.h>
#include <iostream>
#include <windows.h>
#include <stdlib.h>
 
 
HDC hdc = GetDC(NULL);
DWORD color = GetPixel(hdc, 90, 90);
unsigned int g1 = GetGValue(color);
unsigned int g2 = GetGValue(color);
while( g2!=g1 ) {
DWORD color = GetPixel(hdc, 90, 90);
unsigned int g2 = GetGValue(color);
}
 
COORD p = { 90, 90 };
SetConsoleCursorPosition( GetStdHandle( STD_OUTPUT_HANDLE ), p );
mouse_event(MOUSEEVENTF_RIGHTDOWN | MOUSEEVENTF_RIGHTUP, 0, 0, 0, 0);

voyez vous ce qui cloche?

[tezec]

Donc je n'utilise que getpixel et compare directement sa valeur, découper la réponse ne fait qu'ajouter de la charge, du fait que cela génère des requêtes supplémentaires et ouvre d'autres threads, il est plus simple donc de surveiller le DWORD ARGB dans son intégralité

Ensuite, pas de wait + goto lors des tests, je relance à chaque fois

je vais commencer par ce détail, je ne suis pas du tout à niveau alors je vais essayer d'expoiter au mieux déjà ce que j'ai compris
j'ai quelques notion d’électronique (genre TP sur des microcontrôleurs, les BUS, les commandes principales... pas grand chose)
merci

[bacelar]

du fait que cela génère des requêtes supplémentaires

Je sais pas trop ce que vous entendez par "requête" mais votre "optimisation/filtrage vert" ne fait aucune requête au Kernel supplémentaire.
C'est juste que cela AJOUTE des instructions (qui sont beaucoup moins consommatrice que tout le reste, je vous l'accorde) donc sauf cas exceptionnel ( gestion optimisée des pipelines d'instruction, des différents niveau de cache, des prédictions de branche, etc... enfin, plein de trucs qui sont totalement hors de portée d'un "newbie") cela prend plus de temps que de ne pas le faire.

ouvre d'autres threads

Non plus.

il est plus simple donc de surveiller le DWORD ARGB dans son intégralité

OK

Ensuite, pas de wait + goto lors des tests, je relance à chaque fois

Jamais de GOTO et évitez les attentes actives.

Si votre objectif n'est pas le "botting", quel est-il, pour qu'on vous conseille une méthode plus pérenne.

[Bousk]

il y a jusque 10ms entre la détection et le clic, c'est trop lent.

Il faut de toutes façons que la frame soit affichée pour détecter le pixel avant de générer le clic qui ne sera effectif qu'à la frame suivante. Donc 10ms sera possible uniquement si ton appli a un fps supérieur à 100 et que ta détection et génération de clic se fait entre son affichage et sa gestion des inputs.
Si tu arrives déjà à faire ça en VB, et ne connais rien au C++, non, utiliser du C++ ne va pas sûrement magiquement accélérer quoi que ce soit.