de JacquesZ » Jeu 22 Mar 2018 00:25
Je confirme ce que dit Jacques.
Le code pour les aiguilles vibrantes n'est pas trop complexe, quelques tests et 1 addition+ 1multiplication en plus.
Le taux de rafraichissement (vibration) des aiguilles est de 65 msec et la routine en elle-même ne fait que rajouter ou retrancher une valeur Delta (ajustée manuellement) à la valeur indiquée par l'aiguille, ce en fonction d'une plage de régime moteur (de volume sonore dans le cas de FSX).
Je suis d'ailleurs moi-même surpris de sa simplicité, elle est du coup facile à implémenter, y compris pour des instruments plus complexes tels que l'horizon.
Donc un fsx_subscribe() de plus par jauge soit une variable à surveiller pour le plugin d'AM qui a l'air d'être écrit en C, c'est pas grand chose, surtout que cette valeur ne change pas trop rapidement. D'après le développeur d'AM le plugin peut gérer simultanément plus d'un millier de variables ou events Simconnect, un peu comme FSUIPC. Ca ne devrait pas non plus faire un trafic réseau monstrueux en cas d'utilisation d'AM en déporté sur un PC peu puissant
S'il devait y avoir ralentissement, peut-être qu'au niveau affichage, le doute pourrait être permis, mais là aussi les routines Lua de rotation/déplacement d'image img_rotate() et img_move() ont l'air d'être efficace. Le passage en V3.0 devrait améliorer encore les choses, puisqu'on passe le moteur graphique en OpenGL et non plus en JavaFX.
Je n'ai pas testé les jauges telles quelles avec AM v3.0, mais comme elles ne contiennent aucun affichage de texte, ça ne devrait poser aucun soucis à mon avis.
Le seul apport d'une version spécifique AM3.0 des jauges serait de mettre les variables utilisateur (telles que les amplitudes de vibration, la possibilité d'activer ou non la fonctionnalité ou l'affichage des bezels, variables qui sont modifiables manuellement au début du code) à disposition directement dans le panneau des propriétés.
Jacques