Attention! L'heure est grave. Vous assistez en direct à la naissance du nouveau bébé de votre revue préférée. Moi, Poum, en ce jour du 20 juin de l'an de grâce 1990, je promets solennellement de vous livrer tout mon savoir sur la création de jeux d'arcade. 
Nos journalistes sont tous à leur poste, voici à chaud leurs commentaires sur cet événement mondial: Sined : "Eh bien, c'est pas trop tôt. Depuis que nos lecteurs nous réclamaient une nouvelle rubrique qui traitera des..." Franck: l'Excuse-moi de t'interrompre, mon cher Sined, mais j'ai des nouvelles toutes fraîches provenant de la salle de rédaction. Oui ! Je vois Poum au travail. Oh, c'est extraordinaire ! Quel spectacle !" Zède : "Je confirme, mon cher Franck. Ce n'est pas possible! Il a en plus un laser à rayon plasma muni d'un
compresseur 38 soupapes à injection radio magnétique !" Lipfy : "Zzzzzzzzzzzz." A force de voir le courrier que je reçois (et je ne vous parle même pas des coups de fil anonymes qui me menacent de mort si, dans les plus brefs délais, je ne donnais pas suite à mes promesses), je me sens fin prêt pour partir avec vous vers une nouvelle aventure qui, cette fois, nous fera découvrir le monde merveilleux des jeux d'arcade. ' Durant notre balade, on verra comment organiser un jeu d'arcade, comment faire ses sprites. et les animer, comment tester les collisions et gérer les bruitages. On passera un moment également sur la mémoire écran. Une condition tout de même pour le bon déroulement des opérations: il me faut plein, plein de courrier pour que je sache sur quel pied danser et surtout que je connaisse tous les problèmes que vous pouvez rencontrer. Avant de finir cette page, sautez vers votre bureau et prenez une plume et du papelard et griffonnez-moi quelque chose, sinon j'arrête le massacre dans les deux mois qui suivent. VU ? Chez nous, l'écran de nos machines en a dérouté plus d'un, c'est pour cette raison que nous allons l'affronter de face. Puisque vous êtes courageux, suivez-moi. L'ECRAN DU CPC A LA LOUPE Je dois vous avertir que le suivi de ces articles demandera de votre part un minimum de connaissances en assembleur car, contrairement aux jeux d'aventure, la réalisation des jeux d'arcade sous Basic ne me paraît pas d'un grand intérêt (on se trouve très rapidement bloqué par des problèmes de vitesse et d'organisation). Je vous donnerai tous les chiffres en hexa. Alors, pour les moins forts d'entre vous, courez du côté de chez Zède et revenez nous voir, la porte reste grande ouverte.
Pour commencer avec cette mémoire écran, sachez que la mémoire de l'ordinateur va de 0 à &FFFF. Les octets allant de &C000 à &FFFF sont réservés à cette mémoire écran. N'importe quelle valeur mise dans ces octets fera apparaître quelque chose à l'écran. Pour vous en persuader, encodez ce qui suit: 10 MODE 1
20 POKE &C000,RND*&FF
30 GOTO 20ou10 MODE 1
20 POKE &C000+RND*&4000-1,&FF
30 GOTO 20Dans le deuxième minuscule programme, le &4000 correspond à la taille de notre détestable mémoire écran qui, je l'espère, deviendra bientôt notre mémoire écran chérie. Le petit -1 évite un débordement de cette mémoire; en effet, &C000+&4000 donne 0, ce qui est un de trop pour les micro 8 bits.
Vous devez désormais être familier avec quelques chiffres comme &C000 qui est le début de l'écran, &4000 qui est la longueur en octets de la mémoire écran et &FFFF qui en est la fin. Il existe deux autres chiffres importants: &50 et &800 (nous verrons un peu plus loin le rôle de ces deux p'tits gars).
Pour voir comment les octets des notre écran sont alignés, encodez ce qui suit. Vous verrez la logique des octets les uns par rapport aux autres.10 MODE 1
20 FOR I =&C000 to &FFFF
30 POKE I,&FF:NEXT IEtrange, non? Le premier octet est &C000, à sa droite on trouve &C001, suivi de &C002, &C003... jusqu'à &C04F. La 1re ligne a donc une longueur de 80 octets (toutes les autres lignes également...). L'octet qui suit est le &C050 (&C050-&C000 donne &50, et c'est le premier chiffre qui devra être gravé sur vos cellules grises).Sa place devrait être en début de la 2e ligne, mais on constate rapidement que les choses ne sont pas ce qu'elles devraient être, car l'octet &C050 est le début de la 8e ligne. En continuant cette logique, on passera en revue les 25 premières lignes de l'écran en sautant, à chaque fois, de 8 lignes vers le bas. En fin de la 25e ligne, on revient tout en haut et on commence sur la 2e ligne, à savoir juste en dessous de l'octet &C000. L'adresse de cet octet est &C800 (tiens, &C800-&C000 ça donne &800. Et voilà le deuxième chiffre qu'il fallait retenir). Cela étant, on constate que peu importe la ligne sur laquelle on est positionné : en additionnant 1 à l'adresse mémoire, on se trouve un cran à droite (sauf si l'on est déjà coincé sur le bord droit), et en décrémentant ce même octet, on se voit aller à petits coups à gauche (il est vrai également qu'il ne faut pas se trouver sur le bord gauche). Par contre, pour monter et descendre, c'est une autre histoire. L'AUTRE HISTOIRE DE L'ECRAN On se replace tout en haut à gauche (comme j'ai l'habitude de le dire sur le segment haut gauche SHG ou &C000), et on voit que pour descendre on doit additionner à &C000 la valeur &800. On essaie, et ô miracle, ça marche. On continue, plus &800 et on se trouve bien sur la 3e ligne, etc., etc., et on arrive sur la 7e ligne. On est sur l'adresse &F800. Si on additionne un petit &800, on déborde de l'emplacement mémoire. Pour cela, je raisonne: "Quand j'étais sur &C000 (en haut à gauche), en additionnant &50, je me trouvais 8 lignes plus bas. En additionnant 8 fois &800 je me suis trouvé aux fraises, car débordé. Alors, j'en déduis que pour retomber sur mes pattes, je vais faire le chemin inverse. Je retranche les 8 fois &800 pour me retrouver en haut, et j'additionne le petit &50. . D'où la formule magique: "Quand l'eau déborde, retranche 8*2048 et additionne 80." En deux mots, pour descendre on additionne toujours &800 et, si on constate que l'on dépasse les &FFFF autorisés, on retranche 8*&800 et on additionne &50 ou, pour être encore plus clair, on retranche &3FB0 hexa.
Voici un petit prog Basic pour calculer l'octet écran se trouvant sous celui à qui on rend visite: 10 ADR=ADR+&800
20 IF ADR>65535 THEN ADR+ADR-8*&800+ &50ou l'équivalent assembleur:; En entrée HL pointe sur l'octet écran
; Le registre BC est modifié
LD BC,&800
ADD HL,BC
RET NC
LD BC,&C050
ADD HL,BC
RETVous voyez, additionner &C050 ou soustraire &3FB0 revient au même, car &C050+&3FB0 est égal à 0. Vous vous posez sans doute la question: "Pourquoi faire une addition quand on peut obtenir le même résultat avec une soustraction ?"ADD HL,BC et ADC HL,BC existent en assembleur, SBC HL,BC aussi. Par contre, SUB HL,BC non. Alors, pour faire la soustraction, il faut d'abord mettre la carry à 0 et cela prend une instruction qu'il vaut mieux apprendre à éviter (comme le dirait le père Barbare, c'est de l'optimisation). Comme mon ami Zède le dit si bien dans ses articles, il existe des vecteurs pour venir en aide aux programmeurs que nous sommes. En l'occurrence, il existe le vecteur BC26 qui fait exactement l'opération que nous venons de voir, c'est-à-dire le calcul de l'adresse inférieure d'un octet écran. Son avantage? Il teste toutes les anomalies comme les dépassements, ou les écrans placés dans n'importe quelle zone de la mémoire (eh oui, un écran, si on le force, peut se loger en &4000, par exemple). Avoir les avantages sans les inconvénients me paraît rare, et le BC26, je l'avoue, met plus de temps pour faire ses calculs, c'est d'ailleurs pour cette raison que je préfère utiliser le petit prog ci-dessus. A VOS MARQUES, REPOS! Je sais, tout ça est relativement rasoir à lire et à comprendre, mais malheureusement, il faut y passer. Vous avez donc deux mois pour tout comprendre et vous sentir à l'aise dans le monde de l'écran CPC. Un dernier mot pour être complet, il va de soi que pour les calculs écran, on peut les faire en remontant vers le haut. En utilisant les vecteurs systèmes, on peut, par exemple, appeler le BC29 qui calcule l'adresse en haut de l'octet pointé par HL. Pour réécrire celui-ci, c'est un petit peu plus compliqué que l'autre mais enfin, voici ma version (qui n'est absolument pas universelle) : LD BC,&F800
ADD HL,BC
LD A,H
CP &C0
RET P
LD BC,&3FB0
ADD HL,BC
RETPour donner deux mots d'explication concernant ce prog, je dirai que le débordement ne se calcule pas par rapport à &FFFF mais à &C000 et qu'il faut vérifier qu'on n'est pas en dessous. Pour cela, on regarde la tronche de &C000 en binaire: 1100000000000000Dans le registre L, on a 0 et dans H, 192 ou 11000000. Toutes les valeurs en dessous de &C000 feront que le registre H aura une valeur inférieure à &C0, d'où le test CP &C0 et le retour par RETP, ou retourne voir tes potes si t'es plus grand (si le Cœur vous en dit, remplacez la comparaison par les opérations logiques). . Allez au boulot, et rendez-vous dans deux mois pour une suite beaucoup plus passionnante. Poum, ACPC n°28 juill-aout90, p68-69 | ★ AMSTRAD CPC ★ A voir aussi sur CPCrulez , les sujets suivants pourront vous intéresser... |
CPCrulez[Content Management System] v8.73-desktop/c
Page créée en 225 millisecondes et consultée 2244 foisL'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. |
|
|
