RAD XE3 ou XE5 - Comment s'assurer de la synchro de balayage vertical

[Miloslav Bilik]

Bonjour,

J'ai écrit il y a plus de vingt ans un programme en C pour des tests de vitesse de réaction : un spot s'affichait en bas de l'écran parmi 4 endroits possibles, et il fallait presser un bouton parmi 4 boutons sur un boîtier externe.
La précision demandée étant de l'ordre de quelques millisecondes, un petit bout en assembleur déclenchait un évènement depuis le port série quand un des 4 boutons se fermait, le meme bout d'assembleur reprogrammait le timer à 1024Hz; pour l'affichage, à cause du balayage vertical, un petit sous-programme vérifiait que la remontée du balayage se terminait - pour éviter l'imprécision liée par exemple à un rafraîchissement de 60 Hz.

Je voudrais réécrire ce programme de nos jours, mais Windows n'est pas MSDOS, il ne me permet pas de m'adresser aux ports vidéo ou de reprogrammer le timer..

Je pense avoir résolu les problèmes de timing pour une mesure temporelle précise, et aussi avec une librairie Phidget celui de la gestion d'évènement en temps réel quand on appuie sur un bouton du boîtier externe.

Mon dernier problème est celui du rafraîchissement vertical de l'écran, pour assurer que le spot est vu au moment t0 à quelques millisecondes près.

Je n'ai vraiment pas envie d'apprendre de zéro l'usage de librairies OpenGL alors que je n'ai que 4 spots (4 cercles pleins) à afficher en 4 endroits éventuels, sur un écran tout noir sans rien d'autre.

Pourriez-vous m'indiquer un moyen de réaliser mon programme au plus vite en réglant ce dernier problème ?

Je ne suis pas pro, mon cerveau vieillit.. J'aimerais finir ce p.. de programme avant ma retraite

Merci de votre aide,

PS: j'utilise Embarcadero Delphi XE3 ou XE5
-----

[azad]

Salut.
Il me semble que ce qui devrait paraître aléatoire pour la personne testée, n'a pas besoin de l'être pour le programme.
Si j'ai bien pigé le truc tu as quatre bandes verticales au bas desquelles va s'allumer un "spot" et l'usager doit réagir en pressant un poussoir parmi quatre.
Quatre bandes verticales cela signifie- - si l'on connaît la durée de balayage d'une ligne - quatre zones d'écran. En divisant la durée d'une ligne par quatre on va trouver une valeur T et ton spot sera soit entre Start et T ou T et 2T ou 2T et 3T ou enfin entre 3T et 4T.
Le coup est de commencer le comptage (Start) au début de chaque ligne, ton programme sait dans quelle colonne il place le spot. Le sujet testé doit presser le bon bouton et son temps de réaction est le temps mesuré entre Start et une pression sur un bouton.

[azad]

… en fait quand je parle de "durée d'une ligne" je veux dire "durée entre deux tops de synchro ligne. Il va sans dire que la résolution de l'écran a son mot à dire dans le calcul de la durée d'une ligne. Ainsi d'ailleurs que la fréquence de rafraichissement verticale. Mais tout cela est facile à calculer - et pas obligatoirement par ton programme -
Cela devrait marcher quel que soit l'écran utilisé, CRT ou LCD.

[Miloslav Bilik]

Le plus simple pour moi est de m'assurer que l'affichage de n'importe quel spot se fait au même moment du rafraîchissement vertical; la mesure n'a pas besoin d'être absolue, il suffit qu'elle soit comparable, quel que soit celui des 4 spots qui va s'afficher (et je ne crois pas avoir besoin d'être précis au point de prendre en compte la vitesse de balayage horizontale, sans calculer, quelque millisecondes sont acceptables; de plus le côté multitâche de Windows va générer de variations, mais ca c'est inévitable)
Ma question est donc comment m'assurer que l'affichage se fera en temps contrôlé pour n'importe quel spot sans apprendre OpenGL ? Je n'ai aucune envie d'apprendre à faire un jeu vidéo, les rendus 3D, etc..
Et plus précisément avec RAD XE3 ou 5 ?
Jusque là j'ai pris des boîtes de dialogue standard pour l'affichage.
Y aurait-il un choix de présentation qui forcerait l'usage d'OpenGL ou autre sans que j'ai à m'en soucier ??
Ou alors y a t-il un moyen sous Windows de savoir quand commence le top de rafraîchissement vertical, sans me préoccuper de la librairie ?
Merci pour ton aide.

[A voir en vidéo sur Futura]

[azad]

Bonsoir.
J'avais raisonné en terme d'électronique. Et, puisque l'électronique c'est rapide, pensé à utiliser un top de synchro H. Mais il va sans dire que l'on peut utiliser le signal synchro V. Détecter ce signal (présent sur le fil synchro de la carte vidéo) et s'en servir pour actionner une bascule bistable dont l'état (haut ou bas) sera envoyé sur le port série et lu par ta routine en assembleur implique une petite réalisation électronique à quelques centimes d'euros. Chaque changement de la bascule indique une nouvelle trame verticale. Si ton programme détecte ce changement d'état, il lui suffit simultanément de lancer un compteur qui ne sera stoppé que si la réponse du sujet est bonne. (n'oublies pas que dans mon optique, le programme "sait" quel est le bouton qu'il faut presser. En cas de mauvaise réponse, on attend pour un autre essai. En cas de bonne réponse, la lecture du compteur donne (en mili-secondes par exemple) le temps de réaction du sujet. Et peut importe la fréquence de rafraîchissement, puisque c'est ton compteur qui sert d'horloge. Et si les "tops" de cette horloge sont bien choisis - par exemple une période de 1 milli-seconde) le temps de réaction en milli-secondes, sera le temps écoulé entre le signal de départ et la pression sur le (bon) bouton.
Mais pour que cela fonctionne, il faut également connaître le temps nécessaire pour que le "spot" s'affiche à l'écran.
Et cela me donne une autre idée : pourquoi, ne pas lancer le compteur tout de suite après la routine d'affichage ? Du coup, plus besoin d'électronique : ton programme "sait" quel devra-être le bouton à presser. Alors on n'a pas à s'occuper de ce qui se passe à l'écran. Plusieurs trames vidéo peuvent passer, plusieurs minutes même. Le compteur tournera jusqu'à ce qu'un bouton soit pressé. Si c'est bon bouton on affiche l'état du compteur, si c'est le mauvais, un message de consolation.

[azad]

Sinon, et pour répondre à ta question, non, je ne crois pas que Windows sache à quel moment débute une trame vidéo. Ton contrôleur vidéo, lui, le sait sans doute, mais alors OpenGL est à mettre en oeuvre.