PureBasic

Certains de mes petits jeux ne fonctionnent pas avec les souris de type Razer ou Roccat alors qu'ils fonctionnent parfaitement bien avec des souris Microsoft, Logitech et autres.

Avec les méthodes de Taznormand ou d'Ar-S je crois, les jeux fonctionnent mais provoquent des IMA en sortie de jeux.

■ Un test avec KillBird que vous pouvez downloader sur ce lien
Download killbirds.zip

Il y a une version normal et une autre avec un patch pour Souris Razer. Ca sera l'occasion de me dire à vous détenteurs de souris Razer si
- le jeu normal effectivement lague au bout d'un moment.
- le jeu fonctionne avec la version patché.

Vous verrez dans la console que la version patché provoque un IMA en sortie de jeu.

■ Le code de KillBird étant un peu long, voici un code condensé qui je crois est d'Ar-s.Exécuter le et quitter le jeu. Vous obtiendrez la aussi, un Accès mémoire invalide.

N'ayant pas de souris Razer, je ne peux pas faire de tests plus approfondis pour trouver le code miracle pour un bon patch.

Oui l'acces mémoire invalide se déroule sur l'examinemouse au moment de quitter.

P.S : je crois pas que le code soit de moi.

Ar-S a écrit :je crois pas que le code soit de moi.

Effectivement il n'est pas de toi. Une trace ici
http://www.purebasic.fr/french/viewtopi ... 10#p167310

et une inspiration là
http://www.purebasic.fr/english/viewtop ... 94#p454094

essaye de refournir ton jeu avec PB_Screen_NoSynchronization pour le screen

J'ai ajouté la version KillBird NoSync

Les 2 versions sont fluides (normal + nosync) mais les mouvements de la nosync le sont encore plus.

Spock a écrit :avec le code que tu donnes, bien qu'il n'y ai pas de possibilité de sortir du prg autrement qu'avec un Alt+Tab , et fin de prg par le debugge

Toi le vieux routard du code tu ne vas pas me faire croire que tu ne connais pas la combinaison de touches Alt + F4.

Until WindowEvent()=#PB_Event_CloseWindow fonctionne aussi avec cette combinaison de touches Alt + F4. Non je ne peux pas croire que tu n'es pas vu ça !!

Spock a écrit :je n'ai aucune erreur en sortie !

Evidemment tu es sorti avec un alt + tab suivi d'un arret avec l'IDE.

Spock a écrit :ne pas oublier de compiler en Thread Safe on

Ce n'est pas obligatoire et ça ne change rien.

Testes à nouveau ce même code et sort avec Alt + F4 et tu auras un IMA.

A propos de cet IMA je pense qu'il est du au thread qui n'est pas détruit.

Alors le grand débat des souris qui rament, que je n'ai finalement découvert qu'hier soir...

Un brin de technique niveau CP:

Le problème n'est pas spécifiquement lié à une marque (Razer, Roccat, etc...), c'est une question de fréquence d'update. Une souris "normale" envoie ses déplacements "jusqu'à" +-100 fois par seconde. Si elle ne bouge pas, elle retourne 0 événement, si elle bouge très vite, elle en retournera +-100.

Avec une souris 500 ou 1000 Hz, c'est exactement pareil, la souris pourra retourner jusqu'à 500 voir 1000 événement par secondes à l'Os. Je suppose qu'une Logitech gameur dans une telle config aura le même souci.

SUPPOSITION (rien de plus):

Le problème que je suspecte de ExamineMouse(), c'est qu'il doit n'être capable que de traiter un nombre limité d'événements par appel (Bug? Limitation?). Nombre suffisant avec une souris 100 Hz, mais pas avec une 500/1000.

Le fait de "threader" ExamineMouse() permet de l'appeler 1000 fois par seconde (delay(1)), et ainsi d'éviter de se retrouver avec une quantité d'événements ingérable (souris bloquée). C'est un peu bruteforce voir over-engineering mais ça reste "propre" (avec guillemets de rigueur), avec 2 inconvénients majeurs:

-ExamineMouse() est une fonction très "basic", simple d'usage. En la threadant, on se complique la vie, avec un code pas du tout "comme dans la doc".
-Le thread execute ExamineMouse() 1000 fois par seconde... quoi qu'il arrive! Ainsi donc, même lorsque votre souris ne bouge pas, vous aurez une charge CPU presque aussi conséquente que lors d'un déplacement rapide.

L'autre solution:

L'autre solution, c'est d'éradiquer ExamineMouse() de votre code et de passer par des WindowEvent(). C'est une solution plus "bas niveau". Ici vous récupérez (presque) vous mêmes les événements que l'Os retourne. Cette solution parlera à tous les mecs qui ont tapés des langages un peu plus bas niveau puisque c'est la "seule vrai" solution. Là encore 2 inconvénients:

-Il faut impérativement avoir une fenêtre, même invisible (c'est l'Os qui exige ça)
-C'est une philosophie proche de la gestion des événements en C, avec une "vrai" loop à écrire, et donc, on perd les avantages de fonctions simples comme ExamineMouse()
+Néanmoins vous tapez du code propre, "comme dans la doc", et qui fonctionne partout, tout le temps.


La mise en thread de ExamineMouse() on appelle ça un "work-around", c'est à dire un "palliatif", détourner/modifier l'usage de quelque chose pour contourner un bug bien réel. C'est bien, ça fonctionne, mais si on peut, il faut éviter. C'est pour ça que je préfère revisiter tout mon code et passer à la deuxième solution.

(je décline toute responsabilité si tout ce qui est dit ici n'est qu'un ramassis de conneries amenant à une invasion extraterrestre dans votre village)