* * *
Programmation
* * *

Wobler



 Après les plasmas d'interférence, un autre effet graphique, très simple à réalisé : le wobler. Pour ceux qui ne saurait pas ce qu'est un wobler, et bien une animation de lignes horizontales qui se rétrécissent (comme au lavage) et qui s'agrandissent (comme à l'utilisation!), suivant des courbes le plus zarbi possible. Pour avoir une première idée, exécutez le source d'exemple (woblerh.s). Une petite remarque concernant ce source : je décline toute responsabilité concernat les dégats physique que peuvent entréainé l'utilisation du source (et de tous les sources fournit avec Falk'mag). A vos risques et périls.

1ere idée : du soft !

 Puisqu'il s'agit de visualiser des lignes horizontales qui s'agrandissent et se rétrécissent, et bien il n'y a qu'a les afficher. Cette méthode est la plus simple, mais aussi la plus longue en temps d'exécution. L'algorithme est le suivant : Pour chaque ligne, il suffit de calculer la largeur de cette ligne, puis de recopier la ligne précalculée qui correspond à cette largeur. Cette technique est mise en oeuvre dans le source woblers.s. Il n'y a pas d'astuce exeptionnelle, donc pas plus de commentaire. Mais par contre, ça rame! L'explication est toutes simple la résolution est de 640*200 en true color, il faut donc pour afficher remuer 500 Ko de données (250 Ko en lecture, et pareil en écriture) par VBL, soit 25000 Ko par secondes, soit 37500 Ko de données qui transite sur le bus par seconde, car il ne faut pas oublier que notre petit videl utilise le bus pour lire la mémoire écran. Hors nous avons un malheureux bus à 16 Mhz et de largeur 16 Bits, donc un débits max de 32000 Ko (en gros) par seconde, donc avec toutes la bonne volonté du monde, ça ne passe pas! Là vous vous dites, c'est déjà la fin de l'article, il devient de plus en plus fainéant ce Golio ! Et non, car si il y a une première idée, c'est qu'il y en a une deuxième! Et là voilà :

2ième idée : du hard !

 Là vous vous dites : on va avoir droit au blitter! Et bien non, car pour les même raisons que le 68030, le blitter ne peut pas faire transiter autant d'informations (ou plutôt le bus)! L'idée est la suivante : au lieu de recopier dans la mémoire écran, pourquoi la mémoire écran n'irait pas pointer directement sur les données? Le problème c'est que l'adresse de la mémoire écran n'est fixée que pour le début de l'écran. Faux, il est possible de la changer en cours d'affichage. Et c'est là que réside toute l'astuce, car à chaque HBL (interruption qui se passe toutes les lignes d'affichages), il suffit de changer l'adresse d'affichage en cours. Le Videl permet de modifier les registres de pointeur vidéo (octets aux adresses $FF8205 (poid fort), $FF8207 (poid moyen) et $FF8209 (poid faible)) et les prend en compte. Ainsi, à chaque HBL, il faut modifier ces registres pour que la ligne suivantes affiche la bonne ligne.
 Mais, il y un petit problème : les conflits d'interruptions. La HBL est l'une des interruptions les plus faibles, et comme elle nous interresse au plus au point, autant s'arranger pour que personne le l'interrompe. Sur un falcon normal, il y a (à ma connaissance) que trois interruption : la MFP (la plus prioritaire), la VBL et la HBL (la moins prioritaire). Le cas de la VBL ne pose pas de problème car elle se produit hors de l'affichage de l'écran, donc elle ne viendrat pas interrompre la HBL pendant le moment crucial. Par contre l'interruption du MFP viendrat l'interrompre (le MFP s'occupe entre autre, des timers et des interruptions clavier). Hors si l'on remplace simplement la routine d'interruption par une routine bidon, le temps de changement de contexte (passage superviseur) et le saut à la routine bidon plus le retour, est trop long pour que le 68030 puisse changer l'adresse de la ligne toutes les lignes. La solution consiste a interdire toutes les interruptions du MFP au niveaux même du MFP. N'étant pas un expert du MFP, j'ai appliqué une méthode brutale pour empècher les interruptions (si quelqu'un trouve une méthode moins brutale, je suis preneur). Ce petit point est sans doute le point le plus crucial de la bidouille, car elle interdit tous simplement l'utilisation des interruptions clavier pour une gestion de la souris sous interruptions, et aussi une gestion des routines soundtrack au timer A.

 De plus, il faut que le changement d'adresse de ligne se fassent quand le Videl est en train d'afficher quelque chose, sinon ça ne sert à rien! Pour se synchrioniser avec le début de l'affichage, la soluition retenue est une bète attente active, c'est à dire que l'on guette le début de l'affichage. Le problème qui se pose est de savoir quand est le début d'affichage. Et bien on utilise encore les registres du Videl! Les registres VDB ($FF82A8 : Vertical Display Begin) et VDE ($FF82AA : Vertical Display End) indiquent en demi-lignes quand commence l'affichage de l'écran et ou il se termine. Le registre VFC ($FF82A0 : Vertical Frequency Counter) compte simplement le nombre de demi-lignes qui se sont écoulé depuis la VBL. Ainsi lorsque VFC contient une valeur inférieur à VDB, on se trouve dans le bord haut de l'écran, quand il a une valeur comprise entre les VDB et VDE, on se trouve en plein dans l'affichage de l'écran, et par contre lorsqu'il est supérieur à VDE, et bien on se trouve dans le bord bas de l'écran. Donc pour commencer notre "affichage", il faut attendre que l'on soit dans la zone de d'affichage, et pour arréter, il faut attendre que l'on soit sorti. Entre les deux attente, on paut faire n'importe quoi, par exemple calculer la prochaine table d'adresse!

 Le source woblerh.s ne contient pas de subtilité, donc pas de commentaire. On commence par enlever les interruptions du MFP en prenant soin de pouvoir les restaurer, ensuite on installe la routine d'interruption HBL, et on attend le début de l'affichage pour laisser les interruptions. Ensuite on calcul la nouvelle table d'adresse, et on attent la fin de l'affichage pour réinstaller le MFP et l'interruption HBL. Une remarque : il n'est pas obligatoire d'installer/desintaller à chaque VBL, mais compte tenu de la structure du programme, on ne peut pas faire autrement.


 Au lieu d'attente active, on peut très bien imaginer une routine HBL, qui scrute le moment de début d'affichage, puis installe la routine HBL précédente. Puis à chaque VBL, on réinstalle la routine qui scrute. Bon il y a plein de solution possible pour enlever les attentes actives, mais à vous de les trouver!

 J'espère que cette petite technique qui n'est pas très original sur CPC, mais un peu plus sur Falcon (je n'ai jamais vu d'article/demo l'utilisant sur Falcon), vous donneras des idées pour l'améliorer!

 Bon code et A++





Golio Junior