CODINGCHRONIQUE A100% DES LOGON SYSTEM ★ LOGON SYSTEM ACPC N°44 - 3D SCROLL DEMO ★

Logon System ACPC n°44 - 3D Scroll demoCoding Chronique A100% Des Logon System

Maxim Barrou

Eh oui, chers amis lecteurs, me voici de retour après de longs mois d'absence! Cette fois-ci, voici le source d'une des parties qui firent le succès de The Demo, la 3DSCROLL démo ! Pour ceux qui n'auraient pas vu cette démo, imaginez un scroll qui s'éloigne en profondeur, un peu à la façon du générique de La Guerre des étoiles. Sympa non?

Mais comment cela est-il possible? Avant les explications, tapez d'abord le listing Basic et le source assembleur (ou les datas pour les moins pros) et exécutez-les. Le listing Basic se charge de créer une table de profondeur et le patron de la forme du scroll.

Pour comprendre le principe, nous avons besoin de faire un peu de mathématiques... Non, ne vous enfuyez pas en courant, vous allez voir, c'est très simple (je suis d'ailleurs moi même nul en maths, alors pas de quoi vous affoler...) !

Tout d'abord, il faut savoir que l'oeil humain voit les objets en perspective conique. Cela revient à dire que la profondeur de l'objet dépend d'une fonction conique, et plus précise ment d'une fonction hyperbolique de type 1/x. En effet, dans une courbe de ce genre, plus x est grand, plus son image est petite. Il en est de même pour la vision. Plus un objet est éloigné de l'oeil, plus il paraît petit.

Afin de rendre cet effet, le programme Basic crée une table de profondeur composée de 200 valeurs, ce qui est le nombre de lignes de l'écran standard. En mémoire, nous avons un scrolling de 256 lignes. Les 200 valeurs créées par le listing Basic correspondent à certaines de ces 256 lignes, de façon à ce qu'on ait sur l'écran l'effet de profondeur souhaité.

Ensuite, la deuxième partie du scroll sert à créer l'écran pour donner un effet de profondeur à la largeur du scroll. Et là, je dois vous expliquer le principe du scroll qui est le même que celui employé dans le jeu Trail Blazer, si vous connaissez.

On fait passer différentes couleurs dans des encres diverses, grâce à des rasters. Cela dessinera des formes sur l'écran. En l'occurrence des lettres, pour ce qui nous concerne. Comme notre scrolling est en mode 1, nous nous servons des 3 autres couleurs (1, 2 et 3) pour l'affichage. Pour cela, nous avons besoin d'une police de caractères spéciale. Etant donné que nous n'avons que 3 encres, il nous faut une fonte qui fasse 3 pixels de large. Le premier pixel est représenté par la première encre, et ainsi de suite. Selon que chaque pixel de la fonte est éteint ou allumé, on fait un raster en couleurs ou en noir dans chacune des 3 encres. On a ainsi la forme de la lettre qui s'affiche à l'écran. Remarquez qu'il était parfaitement possible de faire le scroll en mode 0 et d'avoir ainsi une fonte composée de plus de pixels en largeur (pas trop, car il faut que la durée nécessaire pour changer les couleurs de chaque encre soit inférieure au temps machine d'une ligne raster). Le mode 0 permet aussi d'ajouter des motifs par-dessus le scroll, à condition qu'ils soient d'une autre couleur que les 3 premières.

Néanmoins, j'ai choisi le mode 1 afin de privilégier la finesse du tracé. D'ailleurs, rien ne vous empêche de dessiner le fond avec un utilitaire de dessin (vous pourrez obtenir des résultats très marrants tels un scroll en forme de boule, un scroll tordu, etc.).

BON COURAGE

Les plus habiles pourront essayer de modifier la table de profondeur. Je leur souhaite bon courage, car ce n'est pas si évident que cela. Voilà pour ce qui concerne le principe.

Maintenant, attaquons-nous à la programmation en assembleur proprement dite. Donc au source ci-joint!

Tout d'abord, le CALL &BC0E du début permet de passer en mode 1 et de mettre les pointeurs d'offset des registres 12 et 13 du CRTC à des valeurs qui conviennent au programme.

Puis, on charge les fichiers précédemment créés par le listing Basic, c'est-à-dire l'écran et la table qui nous serviront pour le raster. Pour charger ces fichiers directement du programme binaire, nous utilisons tout simplement les bonnes vieilles routines système, car c'est dur de faire autrement.

Ensuite, on remercie le système de nous avoir chargé les fichiers voulus, puis on s'en sépare en le désactivant via un EI-RETI bien envoyé à une adresse que je n'ai plus besoin de citer. Enfin, on passe à l'initialisation de l'écran. On met un fond noir, un border bleu, on initialise le diviseur d'interruption tout en s'assurant d'être en mode 1 et l'on monte l'écran de 8 lignes grâce au registre 7 du CRTC, afin que le moment où le faisceau d'électrons du téléviseur envoie la première ligne d'écran corresponde au moment où se produit le premier HAL T (ouf 1). Cette manipulation permet de faire notre « scroll-raster » juste après une instruction HALT, car la première interruption interviendra en même temps que l'écran commencera à être affiché sur le moniteur.

Il ne reste plus qu'à débuter la boucle principale du programme.

ÇA ROULE RAOUL

Tout d'abord, on attend le retour du faisceau d'électrons en haut de l'écran, puisqu'on fait un raster. Aussitôt après, on s'occupe de la gestion du scrolling. Il y a en premier un compteur de lettres, qui permet d'attendre qu'une lettre soit complètement affichée avant de passer à la suivante. Remarquez que ce compteur est autobouclant, étant donné que chaque lettre fait 64 lignes de haut, soit &40 lignes de haut (en fait, en mémoire, chaque lettre fait 8 lignes de haut, mais on recopie 8 fois chaque ligne, d'où la raison d'être d'un second compteur autobouclant plus loin). Il suffit donc de faire un AND &3F sur la variable comptant les lignes pour réinitialiser la variable au bout de 64 fois. Chouette, non? C'est pratique, net, et c'est plus rapide en temps machine, donc plus court en mémoire, qu'une gestion de pointeur classique.

Ensuite, on affiche la ligne courante de chaque lettre dans un buffer intermédiaire. D'ailleurs, à propos des lettres, je vous signale que vous ne disposez que des caractères de ponctuation, des majuscules et des chiffres, pour que vous n'ayez pas trop de datas à taper.

Voyons maintenant de quoi est composé le buffer intermédiaire dont je vous parlais. Afin de pouvoir afficher la lettre en raster, il faut transformer les pixels de chaque lettre en couleurs. Ainsi, si un pixel de la lettre est éteint, on met du noir à l'endroit correspondant à ce pixel dans le buffer intermédiaire. S'il est allumé, on prend une couleur dans une table pour chaque ligne et on la met dans le buffer au même endroit. La lettre est maintenant prête à être affichée comme raster. On peut donc la mettre dans le buffer final qui servira pour le scroll. Cependant, pour que notre message scrolle, il faut le décaler à chaque balayage en donnant ainsi la sensation de mouvement. Mais, étant donné que nous devons bouger 3 x 256 octets (puisqu'on scrolle 256 lignes de 3 octets [un pour chaque couleur]), des LDI(R)S prendraient trop de temps machine, c'est pourquoi on utilise la technique des décalages de pointeurs dont je vous avais déjà parlé lors du listing sur les ondulations d'écran. Mais cette fois-ci, il y a une nouveauté puisque nous devons réactualiser le buffer.

Cela est en fait très simple à réaliser, puisqu'il suffit de recopier le buffer intermédiaire à l'adresse donnée par un compteur général du scroll au début de la routine. Notez que ce compteur est lui aussi autobouclant, mais on n'a pas besoin de faire un AND, car le buffer est composé de 256 lignes (étant donné que c'est un compteur 8 bits, il revient de lui-même à zéro! Mais non, je ne vous prends pas pour des imbéciles, mais c'est déjà suffisamment compliqué comme ça...).

Une remarque, n'oubliez pas que l'utilisation des décalages de pointeurs nécessite deux fois plus de mémoire et qu'il faut réactualiser les 2 parties identiques du buffer. C'est pourquoi il y a en tout 6 LOis dans la gestion du programme (puisqu'il faut recopier 2 fois les 3 octets du buffer intermédiaire, soit 2 x 3 .. 6). Une fois la gestion du buffer finie, DE contient l'adresse de départ des données à afficher dans le raster, et il ne reste plus qu'à attendre le HALT pour se synchroniser avec le début de l'écran virtuel et enfin lancer notre raster.

ET LE RASTER FUT

Pour afficher notre raster, nous allons nous servir d'OUTls et de la pile. Or pour pouvoir utiliser cette dernière, nous devons envoyer un DI afin que le Z80 n'aille pas poker une adresse due à une interruption fortuite en plein milieu des données. Il faut aussi sauver l'adresse contenue dans SP, puisqu'elle va être modifiée. Le pointeur de pile va adresser la table de profondeur précédemment calculée en Basic. En faisant à chaque raster-line un POP HL et en l'additionnant avec le contenu de DE, on aura l'adresse de la ligne du scroll à afficher, ce qu'on fait avec des OUTls, en changeant à chaque OUTI de couleur. On n'oubliera pas de réinitialiser le registre B à chaque rasterline, car il est modifié par OUTI. C'est ce qu'on fait avec LD BC,&7F01, ce qui permet de remettre aussi le registre C à l'adresse correspondant à la première couleur. Après les OUTls, on attend la fin de la raster-line avec des DJNZ de tempo et un NOP (il faut avoir exactement le temps machine d'une rasterline, c'est à dire 64 NOPS). On fait ça 200 fois, puis on teste la touche CONTROL pour changer (enfin non, ce n'est pas pour changer, mais quand j'ai écrit le programme, je ne me rappelais plus le code de la barre d'espace...

Hem !. Si elle est enfoncée, alors on quitte le programme et on revient au système ( le "Firmware" comme disent les pros ). La suite du listing est composée des données et allocations mémoires ( ça y est, je me crois sur Amiga ! ) nécessaires au programme ( fontes, table de couleurs, etc. ).

LOGON, LA CLASSE!

Voilà, j'espère que ce programme vous plaira, et que ceux qui se demandaient quel était le truc en voyant The Demo l'auront compris et sauront l'utiliser à bon escient. Croyez-moi, il permet de faire des trucs faramineux.

A propos, si vous avez fait un fond rigolo ou étonnant pour ce scroll, n'hésitez pas à l'envoyer à la rédac. Bon, je vous quitte, car Poum veut rentrer chez lui, et je n'oserai contredire sa décision.

10 REM ON CREE D'ABORD LA TABLE DE PROFONDEUR DES ORDONEES
20 MODE 2:ORIGIN 0,0:ADR=&4000
30 INITIAL=256:FINAL=200:C=2*INITIAL
40 REM "INITIAL" CORRESPOND AU NOMBRE DE LIGNES QUE L'ON
41 REM A AU DEPART ET "FINAL" A CELUI QUE L'ON VEUT OBTENIR
50 FOR a= 0 TO FINAL-1
60 B=C*(1-FINAL/(A+FINAL)):PLOT 2*B,2*A
70 LOCATE 1,1:PRINT A,INT(B)
80 VL=3*INT(B):POKE ADR+2*A+1,(VL AND &FF00)/256:POKE ADR+2*A,VL AND 255
90 NEXT
100 SAVE "PROFTAB",B,ADR,2*(VL+l)
110 REM MAINTENANT ON CREE L'ECRAN QUI S'ERVIRA POUR
111 REM "SIMULER" L'EFFET DE PROFONDEUR SUR LA LARGEUR DU SCROLL.
120 MODE 1:ORIGIN 0,0
130 FOR A=0 TO 2
140 GRAPHICS PEN (A+1):FOR B=2*(107*A) TO 2*(107*(1+A)
150 PLOT B,0:DRAW 320,initial*2
160 NEXT
170 NEXT
180 SAVE"ECRAN",B,&C000,&3FFF

Call 0 ! Pict !, ACPC n°44 juil92, p42-43-44

★ ANNÉE: 1992
★ AUTEUR: PICT

Page précédente : Logon System ACPC n°43 - Le PPI 8255A ( Programmable Peripheral Interface )
★ AMSTRAD CPC ★ DOWNLOAD ★

Other platform tool:
» logon44DATE: 2012-08-27
DL: 90 fois
TYPE: image
SIZE: 528Ko
NOTE: w393*h4432
 

Je participe au site:
» Newfile(s) upload/Envoye de fichier(s)
★ AMSTRAD CPC ★ A voir aussi sur CPCrulez , les sujets suivants pourront vous intéresser...

Lien(s):
» Coding » Logon System ACPC n°38 - Overscan facile
» Coding » Logon System ACPC n°33 - Les interruptions du Z80
» Coding » Logon System ACPC n°45 - Sinus Dots
» Coding » Logon System ACPC n°49 - Le soundtrack sur CPC
» Coding » Logon System ACPC n°34 - Les usages détournés de la pile
» Coding » Logon System ACPC n°36 - Rupture facile

CPCrulez[Content Management System] v8.7-desktop/cache
Page créée en 110 millisecondes et consultée 974 fois

L'Amstrad CPC est une machine 8 bits à base d'un Z80 à 4MHz. Le premier de la gamme fut le CPC 464 en 1984, équipé d'un lecteur de cassettes intégré il se plaçait en concurrent  du Commodore C64 beaucoup plus compliqué à utiliser et plus cher. Ce fut un réel succès et sorti cette même années le CPC 664 équipé d'un lecteur de disquettes trois pouces intégré. Sa vie fut de courte durée puisqu'en 1985 il fut remplacé par le CPC 6128 qui était plus compact, plus soigné et surtout qui avait 128Ko de RAM au lieu de 64Ko.