|
|||||||||||||||||||||||||||||||||||||||||||
|
J'ai toujours beaucoup aimé lire les détails techniques des autres démos, comme les articles de Leonard, Paradroid et Slummy. J'ai donc écrit ma propre description ci-dessous. Logo et titre Le logo et les écrans de titre n'ont été programmés que récemment lorsqu'il est devenu évident que les images statiques n'allaient pas suffire. Il fallait quelque chose de plus que des fondus pour coller à la superbe musique de Magnar ! Le logo et le titre utilisent le même code, ce qui est assez simple, mais les détails rendent le résultat final assez intéressant. À la base, il y a une image statique, et elle est simplement copiée dans le tampon mémoire arrière en tuiles de 16x16. Les destinations des tuiles restent les mêmes à chaque image, mais les positions sources sont mises à jour selon le motif de déformation en cours de lecture. ![]() Utiliser le Blitter pour copier un carré arbitraire de 16x16 nécessite un blit de 32x16. Pour fonctionner en 50 Hz, l'écran est limité à 21x11 tuiles pour une image 320x160 en 8 couleurs, ce qui est proche de la limite du Blitter. Nous pilotons le Blitter à partir de notre liste Copper afin de l'alimenter le plus rapidement possible tout en laissant le processeur libre. Pendant que le Copper est occupé à travailler sur le Blitter, le processeur écrit de nouvelles positions de source dans la prochaine liste Copper. Pour les modèles eux-mêmes, il n'y a vraiment pas assez de puissance processeur pour faire quelque chose d'intéressant, alors j'ai triché. Toutes les images des positions sources se trouvent dans un grand tampon mémoire d'animation qui occupe environ 360 ko de mémoire Slow. Heureusement, LDOS est si rapide à charger et à décompresser qu'il a le temps de charger une seconde animation en arrière-plan, ce qui signifie que les motifs peuvent être différents pour le logo et le titre. Les données d'animation elles-mêmes sont stockées sous forme de deltas qui se compressent très bien, il n'y a donc aucun souci d'espace disque. Pour générer les motifs, j'ai en fait prototypé des choses dans Shadertoy. Les zooms tourbillonnants et vacillants du titre "Arcanum" étaient les modèles originaux et ont mis un peu de temps pour être perfectionnés. Quand j'en ai été satisfait, je les ai portés sur un outil PC capable de produire un binaire Amiga approprié. Les deux premiers modèles d'animation du logo "Cosmic Orbs" sont un peu plus simples pour mieux s'adapter au style de l'illustration. Je pense que la vraie cerise sur le gâteau de cette séquence, ce sont les effets sonores ajoutés par Magnar. Ceux-ci mettent vraiment en valeur les effets et rendent le tout beaucoup plus intégré. Rotozoom 3D chunky J'ai toujours été un peu déçu par la plupart des effets Copper chunky, y compris le mien, et à l'origine, je n'avais pas l'intention de travailler sur un nouveau. C'est donc amusant que j'ai fini par faire cet exemple très chunky ! L'effet commence par se moquer à la fois de ma routine et de toutes les autres. L'idée était d'augmenter l'impact du rotateur final entièrement en 3D, ce qui, j'en suis sûr, est une première sur A500. Mais il ne semble pas y avoir eu beaucoup de réactions à ce sujet, peut-être simplement parce que le rotateur chunky qui suit a attiré l'attention. L'écran est configuré de manière à ce que chaque ligne chunky d'instructions de la liste Copper puisse être répétée facilement à l'aide de sauts du Copper. Le tramage et le scintillement masquent la basse résolution en utilisant une combinaison de décalages d'attente et de sauts pour exécuter la ligne chunky correcte à chaque position y. ![]() Il y a en réalité trois rotateurs différents pour cette section, chacun remplit le suraffichage autant que possible. Le premier rotateur coloré comporte des morceaux de 8x4 pixels et une résolution de 44x68. Celui-ci utilise la technique classique d'auto-modification, où chaque ligne réutilise le même ensemble unique de décalages UV interpolés. Cela provoque des artefacts de rupture lorsque vous zoomez de près, donc pour la version suivante, nous passons à une résolution inférieure avec des morceaux de 8x8 mais échangeons vers un interpolateur précis par pixel, ce qui rend le zoom beaucoup plus agréable. C'est une amélioration subtile mais peut-être que d'autres programmeurs l'auront remarqué. Pour le rotateur 3D, nous nous en tenons aux morceaux 8x8, mais l'interpolateur devient beaucoup plus délicat. Cette fois, nous utilisons une approximation quadratique pour nous rapprocher le plus possible d'un rotateur correct en perspective. Arriver à une boucle interne rapide avec juste assez de précision a été un défi amusant, et les mathématiques qui l'accompagnent ont pris du temps à être appliquées. Le fait qu'il fonctionne à moins de 50 Hz tient du miracle, mais il restait juste assez de temps pour conserver la fenêtre de texte en haut de l'écran afin que les gens sachent que c'est un peu spécial. Synchroniser cela avec la musique avec du mouvement et des reflets de flou chromatique était vraiment satisfaisant, en grande partie grâce à quelques grands moments de la musique de Magnar. Les cartes de texture de Facet font également vraiment la différence pour cet effet. Il a fallu quelques expérimentations de dernière minute pour trouver le bon style et pour éviter les effets disgracieux de crénelage lors d'un zoom arrière. Grand Rotozoom Cet effet est mon hommage à la fois à la version de M. Pet que j'ai vue pour la première fois dans la démo World Of Commodore et à l'itération encore meilleure de Kreator dans le jeu Brian The Lion. Ces routines étaient époustouflantes et m'ont vraiment marqué comme quelque chose que j'ai toujours voulu mettre en oeuvre. Je soupçonne que les deux exemples ont été inspirés par le livre "Digital Image Warping" de 1990, dans lequel George Wolberg détaille comment la rotation peut être séparée en deux passes obliques. Le résultat ajoute implicitement un zoom avec lequel vous êtes coincé, et vous devez gérer spécifiquement chaque quart de tour puisque l'inclinaison ne vous donne que 90 degrés d'une diagonale à l'autre. Cependant, les deux passes s'adaptent assez bien à l'Amiga car vous pouvez les incliner verticalement avec le Blitter, puis horizontalement avec une certaine mise à l'échelle verticale en utilisant le Copper. Tout mon respect à M. Pet pour avoir fait ces sauts mentaux il y a plus de 30 ans ! ![]() Pour effectuer une rotation plus rapide, vous devez copier l'intégralité du tampon mémoire précédent dans des colonnes de 16 pixels, certaines se déplaçant vers le haut/bas et d'autres nécessitant une division au milieu. Suivre où vous déplacez les choses et choisir soigneusement les bonnes divisions pour que cela fonctionne sans paraître bancal ou désordonné peut être délicat. La version de Michael Troughton suit cette approche et tourne plus vite, mais à une vitesse fixe. Je pense que cela est en partie dû au fait que les blits nécessaires sont pré-calculés pour une vitesse spécifique. Une autre contrainte vient du changement nécessaire à chaque quart de tour. À chaque diagonale de 45 degrés, les tampons mémoire sous-jacents doivent basculer complètement vers une copie de l'image pivotée à 90 degrés, mais inclinée dans la direction opposée. Pour continuer la rotation, vous commencez ensuite à désolidariser ce tampon mémoire. Afin de continuer à tourner à 360 degrés, cela doit se produire sur chaque diagonale. Le moyen le plus simple de résoudre ce problème est de conserver en mémoire toutes les images totalement asymétriques. Il y a cependant un problème lorsque vous souhaitez continuer à tourner au-delà de 360 degrés ou changer de direction. Dans ces cas-là, vous aurez besoin d'une image asymétrique. Vous finissez par avoir besoin de huit tampons différents et après avoir ajouté le remplissage nécessaire pour les blits et le défilement, il utilise facilement toute la mémoire Chip et plus encore. C'est peut-être la raison pour laquelle nous ne voyons pas de rotation au-delà de 360 degrés ou inversement par rapport au code de M. Pet ou de Michael Troughton. Pour mon effet, je voulais aller plus loin que ce que Michael Troughton avait réalisé. Cependant, il utilisait déjà la majeure partie de la bande passante et de la mémoire du Blitter. Mon implémentation parvient à utiliser un peu plus de bande passante et rend le rotateur beaucoup plus grand, mais le compromis est qu'il est en huit couleurs. Néanmoins, j'ai réussi à apporter ces améliorations :
Pour gérer les nombreux tampons mémoire biaisés qui ne tiennent normalement pas dans la mémoire, je les génère chacun selon les besoins en utilisant le temps processeur restant. En stockant un clone compact de chaque tampon mémoire biaisé, il reste normalement juste assez de temps pour recréer complètement chacun juste avant que la rotation n'arrive et que le tampon soit nécessaire. Cela signifiait que je pouvais tenir ma promesse envers Magnar et que la musique pouvait utiliser la moitié de la mémoire Chip pour les échantillons. Avec cette approche, le processeur est à peine capable de suivre le rythme lors de vitesses de rotation plus rapides. Une dernière astuce consiste donc à déplacer le rotateur en translation. Ce faisant, nous ajustons les récupérations du plan de bits, ce qui libère certains cycles indispensables afin que nos tampons mémoire puissent toujours être prêts à temps. Il s'est avéré qu'il me restait même un peu de temps pour ajouter des salutations en haut à chaque fois qu'un tampon mémoire est généré. Un grand merci à Prowler pour la belle police propre qui parvient à avoir fière allure tout en restant lisible. Au final, je suis content du résultat et je pense que cela va bien au-delà de la version de Michael Troughton. Mais ensuite, Michael Troughton a quand même réussi à intégrer : un zoom classique, un zoom par ligne, un effet mosaïque et beaucoup d'activité de sprite. Donc, je suis toujours complètement impressionné par ces routines classiques ! Partie finale La fin du polygone filaire allait être plus intéressante, mais avec le temps, il est devenu nécessaire de réduire cela à quelque chose de simple que je pourrais terminer. Heureusement, la musique de Magnar est excellente ! ![]() Pourtant, cela me dérangeait toujours que mon code mathématique soit plus lent que celui de Paradroid, alors je l'ai contacté pour chercher des réponses. C'était éclairant, car il s'est avéré qu'il n'avait même pas vraiment essayé de rendre son code mathématique rapide et qu'il avait tout de suite opté pour un tampon mémoire en anneau. J'étais tellement sûr qu'il devait y avoir une sauce secrète qui me manquait. Parfois, la magie consiste simplement à utiliser la bonne astuce, j'adore ça dans les démos. C'est tout J'ai vraiment aimé créer Backslide To Arcanum et je voudrais remercier Facet, Magnar et Prowler pour m'avoir aidé à élever mon code et à tout rassembler. J'aimerais également remercier tous les programmeurs Amiga, du passé et du présent, qui m'ont inspiré, il y en a beaucoup trop pour les mentionner ici ! Merci pour votre lecture. Jobbo
|