Oui il est arrivé hier juste avant que je parte en déplacement. J’ai vite testé et tout à l’air fonctionnel cette fois-ci.
Cela etant je suis allé sur le discord GSI et j’ai aussi vu l’annonce. A la simexpo, ils parlaient de 2 versions : une USB et une alimentée par le QR.
La version USB devrait être disponible aujourd’hui ou demain. Donc le valo devrait être rapidement a la vente:
Quel que soit le type d’usb?
Sur ce lien tu as quelques infos sur les horloges dd moteur physiques des jeux/simulation de course :
où est ma carte bleue? 
Normalement je reçois le volant de remplacement aujourd'hui. C'est parti à 17h d'Helsinki hier, c'est bluffant!
Pour le futur, j'aimerai reprendre une roue moins ronde avec un dash. J'avais repéré la ascher arturo ultimate, mais j'ai vu que GSI avait sorti une version V2 de son FPE. Et je suis retombé sur la vidéo de la simexpo ou il était question d'une version simucube dans les mois qui viennent (mais quand?).
Du coups, mon choix se portera sans doute sur celle là quand elle sera rendue disponible. Elle gomme tous les défauts de la FPE originelle qui me faisaient hésiter au départ.
Oui j’ai fini par le recevoir ce matin. Le livreur est passé une heure après. Le support m’a informé qu’ils m’en envyaient un neuf en express mais je n’ai pas eu de Bon non plus
ca ne me parle pas vraiment, mais tu as toutes ces données ici :
IONI device model comparison - Granite Devices Knowledge Wiki
et ici :
IONI specifications - Granite Devices Knowledge Wiki
Ces chiffres ne me parlent pas, mais tu devrais y trouver des infos interessantes.
Je crois que sur le wiki de granite tu as les spe précises des ioni . Je pense que c’est le plus précis que tu puisses trouver
Il faudra voir ce que full force apportera. En l’etat, boosted media disait que les DD/DD+ ne se comparent pas a simucube/ invicta etc, mais plus a des bases du meme prix, simagic…
Le M4 GT3 etait tres bien aussi 😉
Journée assez sympa finalement et cette course qui finissait de jour a permis de pouvoir se balader dans les stands et de pouvoir voir le podium au milieu des mécanos du rowe.
J’ai pu ballader un peu, manquer de bousculer bortolloti et discuter avec Daniel Morad qui etait vraiment tres sympa et disponible. Un chouette type.
Ok, je les verrai debut mai alors.
Le chrono de Rossi aura au moins le mérite de voit une belle remontée de la 46 avec marciello et martin.
Jolie pole de la Iron Lynx. L’equipage de l’andorran Jules Gounon devrait bien embêter la lamborghini cet apres midi. Moi je suis posté au double droit du Beausset pour l’instant. Je vais tourner tout au long des 3 heures et j’irai aux paddocks vers la fin pour approcher les voitures
FloSimRace mais ou sont passées les iron dame?
C'est vrai que quand on lit cette histoire de rematricage, cela semble une solution peu élégante et pas très engageant.
Mais de l'avis de plusieurs personnes ayant fait le comparatif, cela semble porter tout de même un gain. Maintenant si on fait un blind test, je ne suis pas sur que les gens sachent différencier. Comme avec les différentes base du marché en fait. Et comme avec la hi res en audio.
Le ascher artura ultimate me fait de l’oeil
En me balladant aujourd’hui j’ai croisé Nikki Thim, Mathia Drudi et Lello dans le paddock. Je ne leur au rien demandé, ils avaient l’air peu occupés pourtant 
J’ai aussi croisé stephane Ortelli qui accompagnait un ami qui court en GT2. Comme chaque année, les gens font la queue devant le mobil home WRT (de plus en plus gros) pour voir Rossi. Les autres pilotes sont dans un anonymat absolu. C’est d’ailleurs le seul pilote qui a son stand de casquette.
Iracing a une limitation historique de son moteur FFB. Ils tentent de contourner le problème avec cette pirouette mais je pense que cela reste moins satisfaisant que d’autres FFB synchronisées sur les moteurs physiques d’autres simu.
y'a beaucoup de propos sans contexte qui seront difficiles à comprendre, mais cela donnera quand meme beaucoup d'infos
La norme USB HID ne peut pas envoyer une mise à jour plus rapide que 1 KHz, c’est une limite technique de la norme. S’ils sont réellement en train d’interroger à 8 KHz, alors ils doivent utiliser une autre api. Ou ils pourraient être en train de faire des sondages internes à 8 KHz et de vous envoyer simplement le signal lissé à 1 KHz (ou moins). Plus important encore, Windows utilise une file d’attente d’événements pour gérer les mises à jour de la souris et les jeux ne lisent cette mise à jour que si souvent. Nous exécutons cette mise à jour à 60 Hz, donc une souris de 8 KHz ne fait pas grand-chose pour vous (c’est un peu mieux, mais difficilement mesurable). Je doute que même les jeux de tir fonctionnent à plus de 200 Hz.
De plus, la norme USB HID est limitée à quelque chose comme 64 octets, ce qui est un gros problème pour les fabricants de roues qui souhaitent avoir plusieurs commutateurs de position rotatifs. Ils ne peuvent contenir qu’un nombre limité de boutons et d’axes dans un seul message HID, et il est difficile de tout équilibrer (surtout avec 3 pédales, un frein à main, un volant et des palettes analogiques). Augmenter le taux de mise à jour et la taille des paquets serait d’une grande aide. Quelque chose comme 512 octets et 10 KHz serait parfait.
Même dans ce cas, les appels en plusieurs étapes ajouteraient des avantages. Mais oui, l’idéal serait de courir plus vite.
Je suis loin d’être un expert en usb, mais je ne pense pas que l’on puisse utiliser les microframes en mode HID. Je suis sûr que vous pouvez écrire vos propres pilotes pour que cela fonctionne, mais il n’apparaîtra pas comme une souris générique sans pilotes. Mais pour être honnête, je n’ai passé aucun temps à m’intéresser aux souris à grande vitesse. Ce n’est pas quelque chose dont nous pouvons profiter, et je soupçonne un peu que tout cela ne soit que de la poudre aux yeux. Je suis sûr qu’une souris qui fonctionne à 500 Hz est une bonne idée, mais il est peu probable qu’aller encore plus vite aide.
Nous pourrions utiliser l’api telle qu’elle est écrite maintenant pour le faire.
Cela fonctionne très bien lorsque vous dormez pendant une longue période, mais pas si bien lorsque vous ne dormez que pendant une ms ou deux.
Oui, mais vous utilisez essentiellement un cœur à 100% tout le temps. Si Windows avait un support de veille fractionnaire de millisecondes (allez Microsoft, c’est 2024 !), nous pourrions simplement l’utiliser, mais comme Linux l’a depuis 20+ ans et que Microsoft n’a pas encore compris, il est peu probable que cela se produise de sitôt. En fait, Microsoft va dans l’autre sens et ralentit son horloge maîtresse afin que les threads dorment encore plus longtemps que demandé, afin d’aider sur le front de l’économie d’énergie.
Utiliser un cœur à 100% n’est pas terrible mais pas génial. Sur un ordinateur portable, cela ajoute beaucoup de chaleur inutile dans le processeur et entraînera un étranglement du processeur, dans certains cas. Et sur un ordinateur de bureau qui rend plus difficile pour l’ordonnanceur de faire son travail, et utilise plus d’énergie (pas que nous nous en souciions autant lorsque nous pilotions une carte 4090 à plein régime). Vous pouvez céder pour essayer de réduire cet effet (sleep(0) par exemple) mais cela apporte ses propres problèmes. Céder peut ne pas vous remettre en marche en une seconde, ce qui peut ajouter de la gigue ou simplement faire exploser tout le timing. Et en théorie, cela ne réduit pas du tout la consommation d’énergie (mais cela pourrait être le cas dans certains cas).
Le point principal est que vous devez courir à une vitesse où votre gigue est inférieure à environ 1/4 de l’intervalle, ou il n’y a vraiment aucun intérêt à courir à cette vitesse. Si nous pouvions fonctionner à 1000 Hz avec 1 à 2 ms de gigue, ce n’est vraiment pas mieux que de fonctionner à 300 Hz. C’est-à-dire que tout signal au-delà de 150 Hz serait détruit par la gigue, alors quel est l’intérêt d’aller plus vite. Il y a une réduction de la latence (mais même cela est détruit par la gigue), mais la latence est l’une de ces choses qui est soit un gros problème, soit pas un gros problème. Nous avons juste besoin de réduire la latence à un point où les roues peuvent fonctionner de manière stable, et pour l’instant, c’est autour de 200 Hz (mais plus c’est rapide, mieux c’est).
Elle fait l’objet d’une réflexion active. J’espère que nous pourrons y travailler, mais c’est un gros projet qui est en grande partie au-delà de ma capacité à le mettre en œuvre.
—
Il existe probablement des moyens d’implémenter des attentes occupées qui permettent de gagner du temps, mais je ne suis pas sûr qu’ils fonctionneront sur différentes versions de Windows. Par exemple, il y a des instructions de montage qui sont essentiellement sans opérations. Il est possible que ceux-ci puissent être utilisés pour ne pas faire de travail. Nous pourrions faire des appels bloquants dans un registre matériel qui prend un certain temps connu pour répondre. Cela met effectivement le fil en pause, sans céder de temps (en théorie). Et le moteur DSP utilisé par XAudio a un moyen de faire des micro-sommeils. Il est possible que nous puissions déterminer les cris qu’ils font et les utiliser dans notre physique. Mais ce n’est pas documenté (à part une seule présentation d’il y a 8 ans qui le mentionnait), et il est peu probable qu’il soit stable d’une version à l’autre de Windows. Et Microsoft a apporté de grands changements dans le fonctionnement de l’horloge globale de Windows, dans chaque version de Windows depuis Windows 95. Donc, encore une fois, il y a de fortes chances que quoi que nous fassions, nous nous brisons encore et encore.
Tout cela est très bien, si vous faites un utilitaire expérimental. Mais c’est une mauvaise façon d’essayer de développer une application commerciale complexe que vous voulez continuer à faire fonctionner pendant 20 ans. Vous vous doutez bien que réorganiser notre architecture sur la base d’une astuce qui nous permet de tourner à 2 000 Hz, par exemple, mais qui risque de se casser dans 2 ans, n’est pas une décision très sage. Quoi que nous fassions, il doit avoir une solution de repli qui fonctionne dans n’importe quelle version de Windows, y compris les versions futures, sans avoir d’impact négatif sérieux sur le fonctionnement de la simulation. Nous ne pouvons pas passer 9 mois à restructurer la simulation, pour que tout s’effondre.
Nous devons communiquer avec TrueDrive pour mettre le volant en mode 360 Hz, et cela dépend de la disponibilité de TrueDrive et de la communication avec le volant lorsque iRacing démarre.
Je soupçonne que c’est ce qui se passe. Le signal de 360 Hz est plus fluide, ce qui le rend plus léger. Je parie que si vous superposiez les signaux ensemble, vous remarqueriez à peine une différence. Mais il serait intéressant de regarder un exemple.
Auto regarde toujours le signal 360 Hz, peu importe le mode dans lequel vous avez le jeu de roues. Et il utilise un histogramme pour pouvoir jeter les pointes, afin qu’elles n’aient pas trop d’influence sur le signal.
Si la molette utilise un filtre de reconstruction, réglé sur 60 Hz, ces deux pistes auront le même aspect sur la sortie. C’est-à-dire que le filtre de reconstruction interpolera les échantillons pour remplir les choses afin qu’elles ressemblent plus ou moins au tracé de 360 Hz. Ce n’est que dans le cas où les deux signaux n’ont que des données bien inférieures à 60 Hz. Toutes les roues n’ont pas de filtre de reconstruction, mais la plupart des roues DD en ont.
C’est l’une des lacunes de l’entrée directe, que nous ne pouvons pas leur dire quel est le taux de mise à jour cible, de sorte que les fabricants de roues doivent deviner et espérer juste.
Pour être très clair, nous abusons de DirectInput pour nous permettre d’envoyer un signal haute fréquence à la roue. Il n’a jamais été conçu pour cela. Ils s’attendaient à ce que vous utilisiez des effets prédéfinis la plupart du temps, et que vous n’envoyiez des forces directes que dans les cas où les effets prédéfinis ne pouvaient pas être mis à jour assez rapidement. L’ensemble de la conception a été réalisé à l’époque où les ordinateurs étaient monothread et où la physique était principalement constituée de tables de correspondance.
Nous avons vraiment besoin d’une nouvelle norme qui permette aux développeurs d’envoyer des signaux dont l’amplitude et la fréquence sont connues, et idéalement regroupés, avec plusieurs échantillons à la fois. Ces appels à 360 Hz qui se développaient avec les fabricants de roues sont un pas dans cette direction. Ils nous permettent d’envoyer une amplitude de force connue et de dire à la roue quelle est la fréquence cible, afin qu’ils puissent développer correctement des filtres pour le signal. Et comme les échantillons sont regroupés, le timing peut être contrôlé pour une lecture parfaitement fluide (avec une touche de latence). Vous pouvez bien sûr également mettre en mémoire tampon des échantillons réguliers pour contrôler la gigue, si vous êtes d’accord avec une touche de latence.
Tout ce qui manque, c’est une norme unifiée (moyen) de communiquer ces nouvelles idées à la roue, afin que tous les fabricants de roues puissent la mettre en œuvre sans trop de difficultés. Il s’agit en fait d’un gros projet, il s’agit probablement d’une nouvelle norme USB HID (idéalement plus rapide que 1000 Hz). Et sans Microsoft, il serait très difficile d’obtenir un large soutien pour cela. J’espère qu’ils se tourneront bientôt vers les jeux sur PC.
