Obligement - L'Amiga au maximum

Samedi 27 mai 2017 - 15:51  

Translate

En De Nl Nl
Es Pt It Nl


Rubriques

 · Accueil
 · A Propos
 · Articles
 · Galeries
 · Glossaire
 · Hit Parade
 · Liens
 · Liste jeux Amiga
 · Quizz
 · Téléchargements
 · Trucs et astuces


Articles

 · Actualité (récente)
 · Actualité (archive)
 · Comparatifs
 · Dossiers
 · Entrevues
 · Matériel (tests)
 · Matériel (bidouilles)
 · Points de vue
 · En pratique
 · Programmation
 · Reportages
 · Tests de jeux
 · Tests de logiciels
 · Tests de compilations
 · Articles divers

 · Articles in english
 · Articles in other languages


Twitter

Suivez-nous sur Twitter




Liens

 · Sites de téléchargements
 · Associations
 · Pages Personnelles
 · Moteurs de recherche
 · Pages de liens
 · Constructeurs matériels
 · Matériel
 · Autres sites de matériel
 · Réparateurs
 · Revendeurs
 · Presse et médias
 · Programmation
 · Développeurs logiciels
 · Logiciels
 · Développeurs de jeux
 · Jeux
 · Autres sites de jeux
 · Scène démo
 · Divers
 · Informatique générale


Jeux Amiga

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


Trucs et astuces

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


Glossaire

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


Partenaires

Annuaire Amiga

Amedia Computer

Relec

Hit Parade


Soutien

N'hésitez pas à soutenir le projet Obligement



Contact

David Brunet

Courriel

 


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 tag "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 ?

Assembleur
Assembleur

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...


[Retour en haut] / [Retour aux articles]