
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