 |
Vendredi 19 avril 2024 - 02:40 |
| Translate |
|
| Rubriques |
| Réseaux sociaux |
|
| Liste des jeux Amiga |
|
| Trucs et astuces |
|
| Glossaire |
|
| Galeries |
|
| Téléchargement |
|
| Liens |
|
| Partenaires |
|
| A Propos |
|
| Contact |
|
|
|
Après avoir laissé large place à ceux qui désiraient exprimer leur avis sur l'avenir du magazine, la rubrique Courrier des lecteurs reprend sa vocation initiale, à savoir répondre à vos questions de programmation.
Programmation de jeux, liste Copper
Salut à tous ! L'objectif de cette lettre ne consiste pas seulement à vous poser des questions, mais dans un premier temps, j'expose mon avis sur le journal et réponds à vos appels.
Si je me suis récemment réabonné, c'est que grâce à l'ANT, je réussis de mieux en mieux l'apprentissage de l'assembleur. Toutefois, il faut bien voir que c'est le seul journal de programmation en français et par conséquent, il est normal que l'on attende beaucoup de lui ! Notamment - et vous le savez - son prix relativement élevé, qui a failli me faire obstacle. Sinon, pour un tel prix, l'ANT ne répond pas toujours aux exigences des lecteurs (en tout cas des miennes) et l'on se sent parfois un peu frustré. Aussi, il est nécessaire qu'il y ait notre contribution dans le journal, et vous l'avez toujours demandée. Mais il faut qu'elle ait une suite concrète. D'autre part, pour faire face à certaines exigences, il faut impérativement que le journal s'agrandisse.
Je me permets de faire une autre suggestion qui me tient à coeur : la programmation de jeux m'attire pour son côté complexe, technique et esthétique. C'est pour cela que j'apprécie des rubriques telles que "DemoMakers" et le "Concours". Pourtant, je verrais bien une nouvelle rubrique, plus axée sur cette programmation de jeux. Attention, il ne s'agirait pas qu'à chaque numéro, on ait un jeu à taper, mais d'explications, d'aides, d'astuces techniques, par exemple sur la gestion des BOB, etc. Qu'en pensent vos autres lecteurs ?
Je suis bloqué pour programmer, par manque de connaissances, et c'est là le deuxième objectif de cette lettre. J'aimerais savoir comment on peut apprendre la programmation de la liste Copper, dont je ne connais absolument rien. Par contre, je sais programmer le Blitter, mais lors de transferts, mon plus gros souci, c'est l'adresse de destination pour un écran ouvert sous Intuition. J'ai beau savoir "qu'on récupère depuis la structure de l'écran, l'adresse du plan de bits", où ceci se trouve-t-il précisément, à l'octet près ?
Le Blitter peut-il s'utiliser dans une fenêtre ouverte sous Intuition et si oui, là encore, quelle est l'adresse exacte de destination ? Puisqu'on est dans la programmation du Blitter, restons-y ! L'affichage de BOB nécessite un transfert vers chaque plan de bits. Or, le démarrage du Blitter représente une importante part du temps machine, alors ne faire qu'un seul transfert apporte un gain de temps essentiel. La méthode permettant ceci consiste à mettre les unes à la suite des autres les lignes du plan de bits 1, du plan de bits 2, etc. L'affichage de fait alors en indiquant un modulo de fin de ligne. J'aimerais que vous expliquiez cette méthode en donnant comme exemple le transfert d'un BOB. Pourquoi d'ailleurs ne pas en faire une rubrique à part ?
Pour bien des programmes proposés dans l'ANT, les BOB proviennent d'une image au format Raw, que l'on petit obtenir par Deluxe IFFConverter, fourni avec Deluxe Paint. Le problème est que je ne possède pas un tel utilitaire, et que je ne vais pas acheter un autre utilitaire de dessin juste pour ça. Il serait donc intéressant de publier un programme de ce type, ce qui permettrait d'en apprendre le fonctionnement.
Enfin, j'aimerais connaître la gestion complète des manettes pour les deux ports, sans pour autant passer par les bibliothèques. J'aurais beaucoup d'autres questions à vous poser (par exemple, nombre de fonctions de la graphics.library me sont encore obscures) mais il fallait bien sélectionner ! Oh, j'allais oublier une toute dernière : le fait d'avoir ouvert un écran sous Intuition ralentit-il l'exécution d'un programme par rapport à toi écran créé avec le Copper ? [Nicolas Liquière, Le Truel].
Réponse
Fichtre, diantre, que de questions dans cette très longue lettre, dont nous avons pourtant coupé quelques passages relatifs à l'ex-proposition de changement de formule d'abonnement et aux RKM en français. Prenons donc le taureau par les cornes et notre courage à deux mains et essayons de répondre le plus précisément possible.
Une rubrique sur la programmation des jeux est une excellente idée, et nous allons y réfléchir. Le seul problème étant alors de trouver quelqu'un de suffisamment pointu dans ce domaine pour tenir cette rubrique. Si un programmeur d'une maison d'édition quelconque (nous ne sommes pas sectaires) lit ce courrier, qu'il nous contacte !
La programmation du Copper s'apprend... en lisant la documentation adéquate ! Je ne peux que vous conseiller, pour commencer, la Bible de l'Amiga, aux éditions Micro Application ; vous y trouverez un chapitre complet sur le Copper qui pour une fois, n'est pas truffé d'erreurs.
L'adresse des plans de bits d'un écran Intuition se trouve effectivement dans la structure Screen renvoyée par la fonction OpenScreen(). Le premier plan de bits se trouve à l'octet $C0, le second à $C4, le troisième à $C8, etc. Le Blitter peut effectivement s'utiliser directement dans une fenêtre Intuition, mais ce n'est là une méthode ni pratique, ni très sure. Si vous y tenez absolument, le mieux est encore d'ouvrir une fenêtre de type SUPER_BITMAP, pour laquelle vous précisez vous-même l'adresse des plans de bits à utiliser, plans de bits que vous aurez pu allouer auparavant avec AllocRaster(), par exemple.
La technique des "super plans" n'est plus un secret pour personne... Elle sera expliquée en détails dans notre prochain numéro. Quant à en faire une rubrique à part, c'est déjà fait ! Le Transactor, digne successeur du Concours Lecteurs, est là pour ça !
Un convertisseur IFF n'est pas très difficile à programmer en soi ; le plus ardu dans l'histoire étant de trouver les routines de chargement et d'affichage d'une image IFF. Une telle routine a déjà été proposée dans l'ANT, alors qu'il faisait encore partie de Commodore Revue. Sinon, le ScreenSaver de Max, proposé dans le cadre de la rubrique Utilitaire du numéro 24, peut être une excellente base à un tel programme au lieu de sauvegarder l'image en IFF, sauvez-là simplement au format "brut" !
Quant à la gestion des manettes, elle a, justement, été décrite dans notre dernier numéro, rubrique Transactor.
Enfin, il est évident qu'utiliser le système d'exploitation ralentit quelque peu l'exécution des programmes. D'abord parce que ledit système est multitâche (votre programme ne dispose donc pas de tout le temps machine pour lui tout seul) et ensuite, parce qu'il est obligé de gérer pas mal de trucs dont on n'a certainement pas besoin dans un jeu.
Détourage de droite, Copper et sprites matériels
Bonjour à tous ! C'est du fin fond de ma cambrousse que je vous écris... Où j'habite, il est difficile de se procurer de la documentation sur l'Amiga, exception faite des revues chez les libraires. En cherchant un peu, j'ai tout de même réussi à trouver La Bible de l'Amiga (ancienne édition), mais à part ça... Je n'ose même pas espérer trouver un jour ces fameux ROM Kernal Manuals, dont vous n'arrêtez de faire l'éloge. Si je vous dis tout ça, c'est pour vous que vous compreniez bien que je suis réellement tout seul dans mon coin ; je connais bien quelques types au lycée qui ont des Amiga, mais à part les jeux, rien ne les intéresse. Moi, j'ai envie d'aller plus loin avec cet ordinateur, de savoir comment il fonctionne et comment l'utiliser au mieux. Cela passe bien entendu par la programmation.
Après avoir été découragé par l'AmigaBasic, je me suis essayé au GFA, lequel m'a donné entière satisfaction jusqu'à ce que je décide d'aller plus loin encore, et de passer à l'assembleur. Je me serais bien essayé au C (je me suis procuré le Sozobon-C du domaine public), mais mon penchant pour les démos m'a naturellement aiguillé sur l'assembleur. Ce qui ne m'empêche pas d'utiliser les bibliothèques et le multitâche de temps en temps...
En suivant avec attention vos articles et ceux de vos confrères, je suis arrivé à un niveau correct, mais beaucoup de points me sont encore obscurs. Voici donc quelques questions, telles qu'elles me passent par la tête, auxquelles j'espère que vous pourrez apporter les réponses.
Comme Frédéric Mazué le faisait justement remarquer dans sa série d'articles "le Blitter de B à R" il y a fort longtemps, la routine de tracé de lignes au Blitter présentée dans La Bible de l'Amiga est boguée. Je l'ai corrigée, mais je voudrais maintenant pouvoir effectuer du détourage de droite dans une fenêtre de l'écran. Auriez-vous un algorithme efficace pour ça ?
L'instruction WAIT du Copper est pratique pour attendre une ligne de balayage particulière, mais je n'ai rien compris à la manière de l'utiliser pour attendre une coordonnée X différente de 0, par exemple, le plein milieu d'une ligne.
Toujours pour le Copper, quelle est l'utilité exacte de l'instruction SKIP, et comment l'utilise-t-on ?
Passons aux sprites matériels. L'utilisation du même sprite sur plusieurs lignes de rasters ne me pose plus aucun problème, mais j'avoue avoir du mal à mettre en oeuvre un sprite 16 couleurs.
Dans quelle mesure le Blitter est-il réellement plus rapide que le 68000 pour les transferts de blocs ? Faut-il l'utiliser en toutes circonstances, ou seulement dans certaines conditions particulières ?
Quelle est la séquence exacte (et la plus efficace) pour attendre le VBLANK, autrement dit le retour de balayage écran ? J'utilise une routine qui lit la valeur de VHPOSR, mais elle n'est pas toujours très précise.
Une petite dernière pour la forme. Pourriez-vous publier un tableau de toutes les combinaisons de MinTerms pour le Blitter, avec leur(s) effet(s) et leur utilisation ? Voilà. J'espère ne pas vous avoir trop ennuyé arec toutes ces questions et que vous pourrez trouver le temps d'y répondre [Gréogry Laville, Carbonne].
Réponse
Décidément, c'est la mode des lettres fleuve et des questions en vrac... C'est sans doute l'été qui veut ça. Il existe plusieurs algorithmes de détourage ("clipping"). Jérôme Étienne vous en a récemment démontré un dans sa rubrique DemoMakers, méthode à laquelle Thomas Landspurg avait apporté sa contribution. Mais d'après l'inénarrable Max, l'algorithme le plus performant est celui que messieurs Cohen et Sutherland ont mis au point. Il est d'ailleurs en train d'en finaliser une mise en pratique, qu'il vous proposera très bientôt dans l'ANT, sans doute dès le prochain numéro.
Le Copper est en effet très pratique pour des effets spéciaux tels qu'un dégradé de couleurs, des barres de couleurs, etc. Malheureusement, un cours complet sur ce coprocesseur n'est pas de mise dans cette rubrique. Mais le mot est passé à Loïc Far, qui a promis d'aborder le sujet très prochainement dans sa rubrique. Attacher deux sprites l'un à l'autre ne pose théoriquement aucun problème, pour peu que l'on respecte les quelques règles suivantes :
- On ne peut attacher les sprites que par paire : spr1 à spr0, spr3 à spr2, spr5 à spr4 et spr7 à spr6.
- Le bit ATTACH (bit 7 du deuxième mot de contrôle dans la structure sprite) doit être positionné pour le second sprite (celui de numéro impair : 1, 3, 5 ou 7).
- Les coordonnées des deux sprites attachés doivent coïncider exactement.
Il n'existe pas de routine "exacte" pour attendre le VBLANK ; le meilleur moyen est de tester le registre INTREQR pour déterminer si l'interruption VBL s'est produite.
Un tableau des MinTerms ? Ce n'est pas une mince affaire... Utilisez donc plutôt le diagramme de Venn suivant, tel qu'il est fourni dans le Hardware Reference Manual (voir figure).
1. Pour sélectionner une fonction D=A, repérez les numéros de bits totalement inclus dans le cercle A. Ce sont 7, 6, 5 et 4. Mis à 1 dans les MinTerms, ces valeurs donnent :
Bits : 7 6 5 4 3 2 1 0
MinTerms : 1 1 1 1 0 0 0 0 = $F0
2. Pour sélectionner une fonction qui est la combinaison de deux sources, repérez les numéros de bits qui appartiennent à l'intersection des deux cercles concernés. Par exemple, pour la fonction AB (A "and" B) :
Bits : 7 6 5 4 3 2 1 0
MinTerms : 1 1 0 0 0 0 0 0 = $C0
3. Pour sélectionner une fonction qui est l'inverse d'une source (par exemple a), repérez tous les numéros de bits qui ne font pas partie du cercle concerné. Dans le cas de a, nous avons :
Bits : 7 6 5 4 3 2 1 0
MinTenns : 0 0 0 0 1 1 1 1 = $0F
3 bis. Pour sélectionner une fonction qui est la combinaison de deux sources dont une inversée, repérez les numéros de bits qui ne font pas partie de la source inversée, mais seulement de la seconde. Par exemple, pour la fonction aB :
Bits : 7 6 5 4 3 2 1 0
MinTerms : 0 0 0 0 1 1 0 0 = $0C
4. Pour combiner plusieurs fonctions, effectuez un "or" entre ces fonctions. Par exemple, pour AB+BC :
Bits : 7 6 5 4 3 2 1 0
AB : 1 1 0 0 0 0 0 0 = $C0
BC : 1 0 0 0 1 0 0 0 = $88
AB+BC : 1 1 0 0 1 0 0 0 = $C8
Voilà pour ce diagramme, qui est, comme vous aurez pu le constater, très simple d'emploi.
|
