Suivez-nous sur X
|
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z,
ALL
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
A propos d'Obligement
|
|
David Brunet
|
|
|
|
Programmation : Assembleur - Run PAL
(Article écrit par Lionel Guillang et extrait d'Amiga News - juillet 1994)
|
|
A l'heure où le nombre de possesseurs de moniteurs multisync s'accroît du fait de
prix un peu plus abordables et surtout de la possibilité de connecter un moniteur VGA
aux Amiga AGA, il devenait assez urgent de faire le point sur les problèmes que posent
certains programmes ne faisant bon ménage qu'avec le PAL. Une fois de plus, Amiga News
vous apporte les réponses et les solutions sur un plateau !
Incompatibilité
Ceux qui possèdent un moniteur multisync savent depuis le début de quoi je
parle ; pour les autres, sachez que la majorité des programmes qui commutent eux-mêmes sur
des listes Copper personnelles ne fonctionnent pas si la fréquence de balayage système
à ce moment-là est autre chose que du 15 kHz (PAL). De plus, contrairement à ce qu'on
pourrait croire, cela ne se limite pas seulement aux jeux et aux démos : essayez de lancer
par exemple ProTracker, qui est soi-disant 100% compatible A1200, depuis un Workbench
en DoublePAL, bonjour les dégâts !
Tous ces problèmes n'en sont en fait qu'un seul et même : les listes Copper non synchronisées.
En effet, selon la fréquence de balayage, le nombre de lignes adressables par le Copper
varie, et à cela viennent se greffer d'autres problèmes de synchronisation horizontale et
de dilatation de pixels.
Les solutions
Comme souvent, il n'y a pas de solution unique, mais diverses possibilités, plus ou moins compliquées.
- La première, très simple, consisterait à demander explicitement à l'utilisateur de
commuter manuellement en PAL dans les préférences et de relancer le programme ensuite :
facile à réaliser mais franchement pas très convivial...
- La seconde, qui viendrait certainement à l'esprit des aficionados du matériel
serait de bidouiller la liste Copper pour que tout rentre dans l'ordre : à ceux-là
je dis "stop" ! Vu le nombre de registres qui touchent de près ou de loin au balayage vidéo
et le peu de documentation disponible sur le sujet, ça tient vraiment de l'exploit, voire
de la mission impossible si en plus on veut sortir de notre programme sans bobos
en rétablissant exactement l'état du système tel qu'il était auparavant.
Une autre raison de ne pas trop bidouiller à ce niveau-là, est qu'il serait dangereux,
d'après Commodore (écrit en toutes lettres dans les RKM), pour la survie de votre moniteur
multisync d'aller écrire des valeurs hasardeuses dans ces mêmes registres.
Vu le prix d'un multisync haut de gamme, il me semble sage d'abandonner cette possibilité.
- La troisième, qui est à mon avis la bonne, consiste, comme souvent pour de ce genre
de problème épineux, à utiliser le système, pas trop, juste ce qu'il faut pour assurer
la fiabilité et la pérennité de notre programme : il n'existe pas de fonction système pour
la commutation des fréquences de balayage me direz-vous : oui, enfin pas de fonction directe,
et il faudra donc un peu ruser. On utilisera tout simplement le fait qu'on peut choisir le
type de balayage d'un écran Intuition lorsqu'on l'ouvre. Rassurez-vous, vous ne serez pas
obligés de faire vos prochaines démos dans un écran Intuition, celui-ci ne servira que de
tremplin, en quelque sorte.
Concrètement, on ouvre un écran de 320x11 et d'une profondeur de 1, en demandant explicitement
un balayage PAL et le tour est joué ! A partir de ce moment-là, on peut commuter la liste Copper,
on est sûr d'être en PAL. Pour sortir, on recommute sur la liste Copper système puis
on referme l'écran bidon et on retrouve le Workbench tel qu'on l'avait laissé. Tout ceci ne
nécessite que quelques lignes de code supplémentaires et un peu de mémoire Chip, 440 octets,
pour l'écran Intuition.
Le programme
Pour une fois, ce n'en est pas réellement un, mais plutôt deux petites
routines que vous pourrez (oserais-je dire que vous devrez ?) insérer à l'avenir dans vos
sources, même si vous ne possédez pas de moniteur multisync (pensez un peu aux autres !).
La première, "Switch_PAL" teste la fréquence de balayage au moment où votre programme est
lancé : pour ce faire on utilise la fonction GetVPModeID() sur le viewport de l'écran
Intuition le plus en avant, qui retourne, comme son nom l'indique, l'identificateur du
moniteur dont le pilote est actif à ce moment-là. Pour du PAL, on doit recevoir en
retour PAL_MONITOR_ID, sinon il faut commuter.
Pour l'anecdote, sachez que l'écran le plus
en avant (le premier dans la liste des écrans) est toujours celui dont la fréquence de
balayage est prise en référence, même s'il est complètement abaissé : tous les autres écrans
visibles sont alors émulés dans cette même fréquence, ce qui donne d'ailleurs parfois des
phénomènes assez amusants tels que des changements de résolution horizontale ;
cela s'explique par le fait que les doubles balayages (DoublePAL, Euro, etc.)
multiplient par deux la largeur des pixels (le faisceau va deux fois plus vite).
On retrouve fréquemment le terme "coercion" dans les docs techniques Amiga, qui
n'est rien d'autre que cette fameuse émulation de fréquence. Si vous avez bien tout
suivi, vous devriez maintenant savoir pourquoi aucun double balayage ne permet d'activer
un écran super haute résolution (1280 pixels de large) !
Bon, j'en reviens à mes chèvres : une autre éventualité que la routine "Switch_PAL"
teste, est la vétusté du système. En effet, on ne peut commuter avec cette technique si
on est en 1.3, voire encore plus rustique (ne rigolez pas, il est tout à fait possible de
faire marcher l'ECS sur AmigaOS 1.3 et donc le mode Productivity). Dans ce cas,
je ne peux pas grand-chose pour vous, si ce n'est peut-être vous suggérer de changer de
système...
Pour ce qui est de la commutation proprement dite, il est absolument nécessaire d'utiliser la
fonction "OpenScreenTagList()" pour ouvrir l'écran, "OpenScreen()" avec une structure NewScreen
étendue ne permettant pas de forcer le mode "Promotion", Dieu sait pourquoi !
La fréquence de balayage voulue est demandée avec le marqueur "SA_DisplayID".
On demande un écran de type "SCREEN-QUIET" parce qu'on n'a aucun besoin qu'Intuition nous
dessine des gadgets, l'écran étant, je le rappelle, tout ce qu'il y a de plus bidon.
Dernière chose : cette routine doit être appelée avant tout gel du multitâche, et toute
commutation manuelle de liste Copper.
La seconde routine "Switch_Old" est la fonction inverse de "Switch_PAL", c'est-à-dire
qu'elle rétablit la fréquence de balayage d'origine. Elle doit être appelée après
avoir recommuté sur la liste Copper système et rétabli le multitâche.
Voilà, le reste est archi-classique et n'appelle aucune remarque particulière. Vous pouvez
aussi très facilement vous servir de ces routines pour activer (et annihiler) proprement
une liste Copper NTSC : il suffit pour cela de remplacer "PAL_MONITOR_ID"
par "NTSC_MONITOR_ID", bestial non ?
Le mois prochain, nous verrons comment rectifier avec cette technique tous
les programmes qui ne fonctionnent qu'en PAL, y compris les jeux !
Merci qui ? Sur ce, commutez bien...
|
