Même si la gestion et la programmation des LDV reste simple, elle doit respecter quelques règles de bon sens, on ne peut tout de même pas se permettre n'importe quoi ! Voici quelques règles et eclaircirssements sur quelques points pouvant être troublant lorsque l'on programme ses premiers LDV:
# | Recommandation / Conseil |
1 | Si vous écrivez un LDV, envoyez le moi ! J'aimerais bien que le site de VISION centralise tous les LDV crées. Vérifiez aussi que votre LDV n'est pas compilé avec les informations de Debug ! Cela ne servirait à rien sinon à en réduire les performances ! |
2 | Il serait sympa et profitable à tout le monde de fournir les sources du LDV avec celui-ci.. Cela peut donner de bonnes idées à certains... |
3 | N'oubliez pas qu'au travers des fonctions que VISION appelle, vous avez un accès direct à la mémoire interne à VISION. Donc si vous faites un peu n'importe quoi avec les pointeurs passés, VISION a toutes les chances de planter tôt ou tard... |
4 | Si vous utilisez VAPI (conseillé !), la même remarque s'applique, la variable Vapi globale du LDV pointe directement sur la mémoire de VISION et si vous écrivez dans cette structure, c'est votre LDV qui risque de planter ! Je vous laisse imaginer les dégâts si vous modifiez l'adresse de la fonction PrSetProg et que vous l'appelez ensuite ! |
5 | L'ERREUR à ne pas commettre dans la fonction Run est d'allouer vous-même la mémoire pour l'image passée dans le paramètre out. Pourquoi ? En faisant cela, déjà vous écrasez le pointeur que VISION a déjà alloué pour cela, mais en plus dès que VISION voudra l'utiliser, cela va planter. En effet, votre LDV est en gros "un PRG" lancé par VISION et terminé lorsque VISION (plus précisemment le gestionnaire LDG) le décide. A ce moment, le compilateur ou le système libèrera la mémoire que ce module avait allouée, même si vous ne le faites pas explicitement. C'est pourquoi c'est toujours VISION, par l'intermédiaire la fonction PreRun qui allouera la mémoire pour le LDV puisqu'il s'en servira ensuite. La fonction PreRun est vraiment essentielle ! |
6 | Si vous utilisez la fonction PrSetProg de VAPI (vraiment TRES conseillé à moins que votre LDV ne soit fulgurant !), évitez de l'appeler trop souvent, comme par exemple à chaque itération de boucle, cela ne sert à rien (si ça se trouve le pourcentage n'a même pas changé !) et cela va ralentir inutilement votre LDV. Faites précéder cet appel d'un test du style if ( ( ++iter & 0x0F ) == 0x0F ), cela aura pour effet d'appeler la fonction de progression seulement une fois sur seize, ce qui devrait être amplement suffisant. |
7 | Les fonctions PrSetProg et PrSetProgEx de VAPI, rendent temporairement la main à l'AES. Cela permet de pouvoir déplacer les fenêtres à ce moment. C'est aussi une des raisons pour lesquelles il faut l'appeler un peu... mais pas trop ! |
8 | Si votre LDV est paramétrable (au plus 4 paramètres), vous devez utiliser un fichier INI associé. Je vous recommande d'associer systématiquement un fichier INI à votre LDV, c'est vraiment très pratique pour les traductions et pas difficile du tout ! Si votre LDV nécessite vraiment une saisie de paramètre très spécifique, vous pouvez définir la fonction GetParams dans votre LDV. |
9 | Si vous utilisez un fichier INI, votre LDV doit contrôler la validité des paramètres qui lui sont passés et ne pas se vautrer lamentablement si un d'eux est hors limites... Dans un tel cas, renvoyez simplement le code d'erreur ELDV_INVALIDPARAMETER. N'oubliez pas que le fichier INI est un fichier texte, aisément modifiable par un utilisateur... |
10 | A priori les nombres flottants, bien que prévus pour une extension future, ne sont pas nécessaires au paramétrage des LDV. Imaginons que vous deviez saisir une valeur entre 0.0 et 1.0, il vous suffit d'indiquer comme plage de variation [0;1000] dans le fichier INI (ce qui vous donne tout de même une précision supérieure à celle pouvant être saisie par l'interface), de convertir le paramètre passé par VISION en float puis de le diviser par 1000. Il doit exister des cas tordus où il devient nécessaire d'utiliser des flottants mais on doit s'en sortir très bien dans 99% des cas ! |
11 | Je vous conseille, pour des considérations de performance mémoire, de toujours utiliser les flags LDVF_OPINPLACE et LDVF_SPECFORMAT. Allouez la mémoire que vous voulez dans le LDV (si vous le pouvez...), et libérez la après son exécution. |
12 | Si vous ne travaillez que sur les lignes et colonnes, utilisez le flag LDVF_SPECFORMAT. La fonction VDI vr_cpyfm par exemple est faite pour cela. Utiliser le flag LDVF_ATARIFORMAT ou LDVF_STDFORMAT obligerait VISION à vous allouer de la mémoire inutilement (d'autant plus que les fonctions VDI travaillent TOUJOURS sur le format spécifique de la machine : LDVF_SPECFORMAT !) |
13 | Si vous êtes amené à manipuler les
indices TOS et/ou VDI, :
|
14 | Même si l'utilisateur a sélectionné un bloc comme zone d'application du LDV sur l'image, vous n'êtes pas limité à la seule zone définie par ce bloc. Vous avez accès à toute l'image, voire même plus si vous décidez de modifier sa taille (champs out->fd_w et out->fd_h de la fonction PreRun). Par contre, n'oubliez pas de mettre à jour les champs x1, x2, y1 et y2 de la structure LDV_PARAMS fournie par la fonction PreRun, afin que le buffer UNDO permette de revenir en arrière. |
15 | Si vous utilisez Magic Mac, vous allez peut être avoir le problème "classique" du FPUPATCH : en effet, la librairie PCSTDLIB.LIB du compilateur PURE C provoque un blocage lors du lancement du programme (vrai pour VISION et ses LDV). Il faut donc le passer au travers de FPUPATCH ou encore patcher directement le fichier PCSTDLIB.LIB. |
16 | Depuis la version 4.0d de VISION, vous pouvez obtenir des statistiques de performances survotre LDV. Il suffit pour cela d'insérer la ligne ShowPerf = 1 dans la section [LDV] de VISION.INI. Après exécution du LDV, VISION affichera diverses statistiques sur les temps de traitement du LDV, vous permettant d'optimiser les parties critiques. |