| ★ CODING ★ CHRONIQUE A100% DES LOGON SYSTEM ★ LOGON SYSTEM ACPC N°45 - SINUS DOTS ★ |
| Logon System ACPC n°45 - Sinus Dots | Coding Chronique A100% Des Logon System |
Et hop ! Ce mois-ci, c'est encore moi, Pict, qui m'y colle pour votre rubrique préférée.Je tiens tout d'abord à dire que je ne m'appelle en aucun cas Maxim Barrou, comme le titre du précédent article le laissait croire (je ne sais toujours pas qui est l'auteur de ce titre étrange, mais ça m'apprendra à rendre mes articles sans titre ... ). Aujourd'hui, nous allons parler animation, avec des pixels bougeant selon des courbes sinusoïdales, encore appelées Sinus Dots en jargon de demomaker. PAGE-FLIPPING A travers ce programme, qui anime près de 400 pixels en 50 Hertz (record !), nous allons voir comme d'habitude quelques techniques d'optimisation, mais aussi un système d'animation particulier, le Page-Flipping. RUSE OU RIGUEUR? Le Page-Flipping, ou encore PageSwitching (connexion d'écran), bien qu'il soit surtout utilisé dans les jeux, est un système qui tient plus de la ruse de demomaker que de la rigueur d'un programmeur professionnel. Cependant, cette technique n'est pas spécifique à l'Amstrad et est employée sur tous les ordinateurs de jeux. Son principe repose sur le basculement de 2 écrans: une fois qu'un écran est prêt, on l'affiche et, pendant ce temps, on modifie l'autre écran, qui est donc caché. Ce système est en fait nécessaire à partir du moment où l'on veut afficher de gros sprites, faire un gros scrolling, ou n'importe quoi modifiant l'écran qui prend beaucoup de temps machine. Pourquoi ? Parce que sinon l'animation se mange le balayage du faisceau d'électrons qui donne un résultat hideux à l'écran ... Etant donné que nous animons plusieurs centaines de points simultanément, cette technique est quasiment obligatoire! Pour réaliser le Page-Flipping, nous allons utiliser les deux pages vidéo de 16 Ko se trouvant en &4000 et &C000. Pourquoi ces deux pages-là plutôt que d'autres ? Eh bien, car encore une fois, notre bon vieux CPC nous tend une perche: le Gate Array à une commande qui permet de considérer l'écran en #C000 comme étant celui en #4000, cela est possible par un simple OUT &7F00,&C3 en Basic (Longshot et Sined ont d'ailleurs déjà parlé de cette possibilité dans des Cent Pour Cent précédents). Cette astuce nous permet de garder la même adresse absolue quel que soit l'écran que l'on trafique. DEJA MAL A LA TETE? Notre animation étant composée de pixels suivant des courbes sinusoïdales en abscisse et en ordonnée, nous allons gagner un maximum de vitesse en transformant les valeurs de la table de sinus en adresse de ligne d'écran pour les ordonnées, et en masques et octets pour l'abscisse AVANT de faire l'animation. Grâce à ce précalcul, il suffira d'additionner l'adresse de la ligne écran, donnée par la courbe des ordonnées, à l'octet des abscisses pour avoir l'adresse du pixel, et de masquer cette adresse par l'autre octet des abscisses, qui est donc le masque donnant le pixel. Toujours dans ce souci de rapidité, bien que l'on soit en mode 1, on n'utilise que l'encre 3, car le masquage se fait plus rapidement avec un écran où il n'y a qu'une seule encre (il suffit d'un simple OR). L'écran a subi un reformatage féroce et sauvage qui permet d'additionner l'abscisse et l'ordonnée grâce à une opération de 8 bits au lieu de 16, et donc de gagner quelques cycles (qui font en fait beaucoup de temps machine gagné puisqu'il faut multiplier le gain par le nombre de points affichés). En effet, l'écran reformaté fait 256 lignes de haut sur 256 pixels de large, soit 64 octets de large; dans un tel format, le poids faible de l'adresse du premier octet de chaque ligne de l'écran étant toujours inférieur à 192, et comme 192 + 64 = 256, une addition de 8 bits suffit donc. De plus, si l'écran est moins large, vous bénéficiez par contre d'un overscan vertical sympathique. Venons en à l'animation proprement dite. Vous avez 4 variables paramétrables en début de programme qui sont la vitesse d'animation et l'écart entre chaque pixel pour l'abscisse et l'ordonnée; essayez autant de combinaisons et de valeurs que vous voulez (mais ne dépassez pas 1 023 ou je ne réponds plus de rien !). il se passe toujours quelque chose de différent sur l'écran! PAS DE DETAILS ... Je ne vais pas détailler le listing davantage, il est déjà commenté en profondeur dans les remarques, mais je tiens tout de même à faire quelques précisions : le RES 3,H que vous pouvez voir plusieurs fois dans le programme est une sorte de compteur autobouclant qui présente 2 contraintes contrastant, hélas! avec son efficacité et sa rapidité. Tout d'abord, comme les compteurs autobouclants du mois dernier, il faut que la table contienne un nombre d'octets qui soit une puissance de 2 (ici 2 11 = 2048 octets) et de plus, il faut que la table de données commence à une adresse multiple de 256, ayant un poids faible, nul autrement dit. L'effacement des pixels se fait à la pile grâce à 2 buffers (un pour chaque écran du pageflipping) contenant les adresses des pixels à effacer. Aussitôt après, on affiche les nouveaux points; regardez bien cette routine, elle est difficile à appréhender (et à comprendre !L Je tiens d'ailleurs à dire que je ne l'ai pas pondue d'un seul coup, mais que j'ai passé plusieurs heures à la cogiter, afin d'avoir une routine rapide sans être pour autant trop gourmande en mémoire. Eh oui, ne croyez pas que savoir programmer signifie être capable de faire une routine par la seule force de ses doigts en tapotànt sur le clavier, il faut aussi (et c'est le plus dur) se servir de sa tête (n'est-ce pas Poum ? Nooon, pas un coup de boule ! Aïe ! Hum, c'est comme ça qu'il se sert de sa tête, lui ? ). En bref, un papier et un crayon sont souvent les meilleures armes face au bug récalcitrant... Je vous laisse ainsi méditer sur ces bonnes paroles, et je vous souhaite une bonne rentrée et de bonnes routines! A +
Pict (Emmanuel, pas Maxim, merci), ACPC n°45 Oct/nov92, p34, p35, p36
|
