Bonjour

c'est ma première tentative de C++

j'ai déjà fait ce script dans d'autres langages mais je n'arrive pas à passer sous les 5ms, c'est pourquoi j'essaye en C++ mais je n'y connais pas grand chose dans ce langage

je ne mémorise que le vert pour accélérer

je crée donc deux variables qui enregistrent le niveau de vert du pixel

puis une boucle while met à jour une des variable et je les compare jusqu'à e que la condition égales soit fausse

Mais C++ semble très exigeant et je tourne en rond

quelqu'un pourrait m'aider? lus je test des choses, plus j'ai d'erreurs à la compilation arrrrgggggg

#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);
Sleep(100000);
goto start;

              
cin.get();
cin.ignore();
return 0;

>je ne mémorise que le vert pour accélérer

Houais, bof, je connais pas le mode de stockage de votre VRAM, mais je pense pas que cela aurait le moindre avantage, voire pire, je pense que cela dégraderait les performances à cause des problèmes d'alignement des accès.

Mais bon, je vois rien dans votre code qui fasse ce "filtrage".

"goto", vraiment ????

Passer par le GDI, c'est bien gentil mais c'est pas fait pour les perfs.

Votre boucle active, c'est une méthode de bourrin et vous allez vous prendre les quanta du scheduler dans la tronche à chaque changement de contexte. Votre temps de réponse va dépendre des réglages "serveur/client" de l'OS, entre autre.

C'est vraiment pas top votre truc.

Bon, ça sent le truc pas très légale de bot "à l'ancienne", donc on va pas trop faire dans le détail, histoire de pas avoir d'emmerde avec ces conneries.

Si vous voulez des perfs. de malade, c'est plutôt du côté des drivers que vous devriez vous pencher (avec une boite de doliprane pour les migraines).

le goto start est pour les tests, afin de mesurer le nombre de pixel d’écart entre la détection et le clic droit qui ouvre un menu contextuel. La pointe du menu me donne l'écart, la répétition car l'écart varie à chaque fois (estimation de la précision). De la bidouille d'amateur, il faut bien commencer, open classroom il y a "open" et "classroom" ))) détendu pour les débutants j'ai pensé. A la fin ce sera un leftclic. je remplacerai goto par une touche de déclenchement. c'est pour un mini jeu ou il faut viser un curseur mobile, et pour m'amuser

merci quand même d'avoir pris le temps de me répondre, même si je comprend pas grand chose vu que je fait juste des petits truc en vb, AHK...

quand vous dites : "Mais bon, je vois rien dans votre code qui fasse ce "filtrage""

si j'ai comris, la fonction getpixel remonte les 3 valeurs: RGB, mais je ne crée qu'une variable au lieu de trois unsigned intg1 = GetGValue(color)

je ne test pas le R et le B. Vous devez être très fort car vous allez chercher très loin )))

du coup vous ne voudriez pas juste me dire quelle méthode mieux que while permettrai un test rapide de la mise à jour du pixel genre <2ms sans être bourrin?

le curseur bouge et je l'attend sur un pixel précis, quand il passe, clic, donc j'ajouterai un wait pour retarder la boucle pendant la phase d'approche

-
Edité par Anonyme 23 septembre 2022 à 13:42:17

>il faut bien commencer, open classroom il y a "open" et "classroom"

Vous êtes débutant, alors N'UTILISER JAMAIS GOTO.

Je ne vois absolument rien dans votre cas qui justifie ne serais-ce qu'un chouia l'utilisation d'un goto.

Je suis peut-être un peu sec, mais un goto, c'est très très très très rarement un bonne idée et quasiment toujours une idée calamiteuse.

(En plus, nous, on n'y comprend rien à votre code avec ce goto dans le "cyberspace")

>plus j'ai d'erreurs à la compilation

Rien n'interdit que ces erreurs soient lié à ce goto merdique.

Donnez les erreurs de compilations, SVP.

>si j'ai comris, la fonction getpixel remonte les 3 valeurs: RGB

Vous avez bien compris et c'est pour cela que je ne comprends pas que vous n'ayez pas compris que l'utilisation de la MACRO "GetGValue", que je n'avais même pas vue tellement c'est incongrue, est une perte de temps sèche et pas un gain.

GetPixel retourne un DWORD qui, généralement, correspond aux valeurs ARGB d'un pixel avec 1 octet par composant.

Donc GetPixel du GDI fait (en "oubliant" pas mal de détails):

-Appel une fonction dans la Dll du GDI

-....(plusieurs appels de fonctions internes possibles pour formatage selon le contexte GDI)

-Appel d'une fonction dans la Dll Kernel32 qui implémente la partie "core" de Win32

-...(plusieurs appels de fonctions internes possibles pour mise en forme pour appel d'API Native NT)

-Appel d'une fonction dans l'API Native NT "User"

-...

-Appel à une fonction du Kernel pour passer en ring 0 et faire le reste du travail en mode Kernel (cela gel le processus "User" appelant)

-Verrouillage des appels des fonctions "graphiques" pour interdire des modifications pendant le traitement lié à "GetPixel" (réentrance des modules Kernel)

-Appels en cascade des drivers graphiques pour répondre à la question "quelle est la couleur d'un simple pixel sur un écran 4K, oui c'est débile mais c'est le dev qui veut"

-...

-Le driver en charge de gérer le bus PCI-Express verrouille le Bus pour causer avec la carte vidéo.

-Le driver envoie la requête formatée par les drivers placés au-dessus du pilote de Bus à la carte vidéo

-La carte envoie les malheureux 4 octets ARGB sur le BUS PCI-express, qui n'a absolument pas été conçu pour faire du pixel à pixel mais pour faire des transferts "de masse".

-Le driver du Bus PCI-Express récupère ces 4 octets et déverrouille le Bus.

-Ces quatre octets remontent la pile d'appel des drivers jusqu'à la partie supérieure du Kernel, qui déverrouille l'accès aux primitives graphiques

-Le Kernel copie des 4 octets de l'espace d'adressage du Kernel vers la case mémoire de la variable "color" de l'espace d'adressage "User" du processus appelant. (ou d'une variable intermédiaire si les couches "User" ont besoin d'une variable intermédiaire)

-Le Kernel débloque le processus et le rend donc allouable à un CPU (c'est plus les thread que les processus mais bon)

-Le processus attend jusqu'à ce que le scheduler du Kernel lui trouve un CPU libre.

-Quand le processus est "remonté" dans un CPU, on retourne la pile d'appel jusqu'à votre fonction.

Ici, "color" contient les valeurs ARGB du pixel.

Et vous, vous optimisez tout cela juste en faisant EN PLUS, un masque binaire AND et un RIGHTSHIFT de 16 bits.

C'est pas en ajoutant des opérations qu'on rend ces opérations plus rapides, en général.

Je vous l'accorde, on n'est plus à 2 opérations logiques en plus près. 

Tester tous les composants est donc plus "rapide" que juste tester le vert.

Comme vous pouvez le remarquer, utilisez GetPixel n'est pas optimum.

Mais, c'est peut-être assez si votre machine est assez rapide, que votre anti-virus n'est pas réactif, que votre OS n'est pas trop optimisé pour faire certains types de tâche, etc...

C'est pas super fiable en fait.

Moi, je fais encore plus bourrin, je "reverse-engine" le "jeu" pour qu'à tous les coups je gagne. C'est pas garanti mais s'il n'est pas protégé, c'est rapide.

Mais, moi, je ne fais rien d'illégal et vous devriez en faire autant.

-
Edité par bacelar 23 septembre 2022 à 18:49:38

Tu l'as fait ragequit

C'est quoi qui l'a fait "ragequit" ?

Mon "insinuation" de botting ???

Ou peut etre juste qu'il a compris que c'etait hors de son niveau. Ou il voulait du code tout fait. Pas une grande perte, c'etait probablement du cheating.

    unsigned int g1 = GetGValue(color);
    unsigned int g2 = GetGValue(color);

    while( g2==g1 )
    {
        DWORD color = GetPixel(hdc, 90, 90);
        unsigned int g2 = GetGValue(color);
    }

On y voit mieux avec un peu d'indentation.

La boucle doit être sans fin ? la variable g2 dans la boucle n'est pas le même qu'a l’extérieur ! Le test ce fait avec g2 extérieur qui ne changera jamais !

il ne devrait pas y avoir un main ? 

5ms ça fait un rafraichissement de 200Hz, où tu veux améliorer le temps ? de la boucle for ? ça va dépendre de ton taux de rafraichissement d'écran;

pour 2ms il faut un temps de rafraichissement de 500Hz ...

On peut lire plus "rapidement" la mémoire vidéo que le rafraîchissement de l'écran.

Quand on triche, on ne s'arrête pas au fait qu'on lise un truc qui n'a jamais été envoyé à l'écran.

encore faut-il qu'elle soit mise à jour aussi rapidement