Coder un sine scroll sur Amiga (1/5)

SoC, , , ,
Un des effets les plus mobilisés par les coders sur Amiga a été le sine scroll, c'est-à-dire le défilé de texte déformé en modifiant l'ordonnée de colonnes de pixels successives selon un sinus, comme par exemple dans cette intro du groupe Falon :
Un beau sine scroll par Falon sur Amiga 500, mais pas au pixel
Le must est le one pixel sine scroll, où chacune de ces colonnes est affichée à une ordonnée spécifique. Toutefois, produire un tel effet est très consommateur en temps de calcul, comme nous le montrerons en y procédant d'abord au seul moyen du CPU. Pour étendre l'effet, nous déchargerons le CPU en sollicitant deux coprocesseurs graphiques : le Blitter et le Copper.
Cet article peut être lu par n'importe qui, ayant été rédigé pour qui n'aurait jamais codé en assembleur 68000, et encore moins pour attaquer le hardware de l'Amiga.
Cliquez ici pour télécharger l'archive contenant le code et les données du programme présenté ici.
Cette archive contient plusieurs sources :
  • sinescroll.s est la version de base dont il sera question jusqu'à ce que nous optimisions ;
  • sinescroll_final.s est la version optimisée de la version de base ;
  • sinescroll_star.s est la version enjolivée de la version optimisée.
Cet article est le premier d'une série de cinq. Nous allons voir comment installer en environnement de développement sur un Amiga émulé avec WinUAE et coder la Copper list de base pour afficher quelque chose à l'écran.
NB : Cet article se lit mieux en écoutant l'excellent module composé par Nuke / Anarchy pour la partie magazine de Stolen Data #7, mais c'est affaire de goût personnel...
Mise à jour du 12/07/2017 : Suppression du positionnement de BLTPRI dans DMACON pour améliorer les performances.
Mise à jour du 17/07/2017 : Désactivation de la fonctionnalité Save marks dans ASM-One pour faciliter l'édition mixte PC / Amiga.
Click here to read this article in english.
Mise à jour du 30/05/2018 : Ceux qui utilisent Notepad++ peuvent cliquer ici pour récupérer une version améliorée de l'UDL 68K Assembly (v4).
Mise à jour du 16/06/2018 : StingRay / Scoopex a permis de corriger des co(q)uilles, d'ajuster du vocabulaire et d'ajouter des détails pour la comptabilité. Merci à lui !
Continuer la lecture de "Coder un sine scroll sur Amiga (1/5)" →
Coder un sine scroll sur Amiga (1/5)

Coder une cracktro sur Amiga (2/2)

SoC, , , ,
Cet article est le second, et donc le dernier, d'une série consacrée au développement d'une cracktro sur Amiga. Dans le premier article, nous avons vu comment mettre en place un environnement de développement en assembleur 68000 dans le contexte d'un émulateur Amiga, et nous sommes rentrés dans une présentation d'un des deux coprocesseurs graphique, le Blitter, exemple à l'appui. Ici, nous présenterons pareillement le Copper et nous conclurons sur l'intérêt de revisiter ce passé.
Cracktro sur Amiga
Pour rappel, vous pouvez visualiser un enregistrement de la cracktro sur YouTube ou un parfait portage en HTML5 sur Flashtro. Quant au code (à peine un gros millier d'instructions en assembleur 68000), vous pouvez le télécharger en cliquant ici.
Continuer la lecture de "Coder une cracktro sur Amiga (2/2)" →
Coder une cracktro sur Amiga (2/2)

Une brève archéologie des diskmags sur Amiga

SoC
L'histoire de la micro-informatique est avant tout celle des micro-informaticiens. A ce titre, elle peut être notamment documentée à l'aide des témoignages publiés par les fanas des technologies qui se sont succédé. Avant l'avènement du Net, c'est par notamment le moyen de fanzines sur disquettes que de tels témoignages ont pu circuler. Une brève archéologie des diskmags produit par la communauté Amiga à la fin des années 80 démontre la richesse du matériau disponible.
Quelques splash screens de diskmags sur Amiga
Mise à jour du 24/07/2018 : Ceux que le sujet intéresse sont invités à lire les articles "All mags are alike" et "Discmags = DELAYS!" publiés dans R.A.W. #3 en 1992. Ils éclairent de manière fort intéressante d'autres aspects du petit monde des diskmags sur Amiga, alors en pleine ébullition.
Continuer la lecture de "Une brève archéologie des diskmags sur Amiga" →
Une brève archéologie des diskmags sur Amiga

Coder une cracktro sur Amiga (1/2)

SoC, , , ,
A l'occasion de la sortie du deuxième documentaire de la formidable série From bedrooms to millions cette fois consacré à l'Amiga de Commodore, prenons un instant pour revisiter ce qui fut un des nombreux aspects de la scène de l'époque : la production de cracktros. Nous prendrons pour exemple une cracktro codée il y a un quart de siècle pour le célèbre groupe Paradox :
Cracktro sur Amiga
Cette cracktro a été choisie parce que son code a été retrouvé et qu'elle exploite le Blitter et le Copper, deux des coprocesseurs de l'Amiga dont il sera ainsi possible de souligner l'originalité de l'architecture.
Noter qu'il est possible de visualiser un enregistrement vidéo du résultat produit sur YouTube. La cracktro fait même partie de la sélection de portages en HTML5 de We Are Back, mais les auteurs de ce portage ont fait l'impasse sur l'effet le plus notable : l'utilisation d'une police à espace variable... Par contre, leurs homologues de Flashtro ont parfaitement réussi.
Continuer la lecture de "Coder une cracktro sur Amiga (1/2)" →
Coder une cracktro sur Amiga (1/2)

Itérateur et générateur en JavaScript

SoC, ,
Comment créer facilement une liste d'éléments qu'il sera possible de parcourir à l'aide de l'instruction for... of... (à ne pas confondre avec for... in...) ?
Cette liste doit pouvoir être totalement spécifique, et non seulement une liste prédéfinie dans JavaScript, comme notamment un tableau. En particulier, ses éléments doivent pouvoir n'être générés qu'au fil de l'itération.
Continuer la lecture de "Itérateur et générateur en JavaScript" →
Itérateur et générateur en JavaScript

Clipping de droite par un rectangle

SoC,
Comment déterminer l'intersection d'une demi-droite avec le périmètre d'un rectangle dans lequel l'origine de la demi-droite est situé, sans nécessairement que ce soit au centre de ce rectangle ?
figure0
Ce problème de découpage (ou "clipping") est assez classique. Plus généralement, il se rencontre quand il s'agit de découper un polygone dès qu'il sort d'une surface de rendu, parce qu'il faut déterminer précisément les coordonnées des sommets résultant du découpage et/ou plus basiquement parce qu'il faut optimiser le rendu en le limitant à ce qui est visible.

Continuer la lecture de "Clipping de droite par un rectangle" →

Clipping de droite par un rectangle

Génération aléatoire d’un labyrinthe de cavernes et de tunnels

SoC,
Comment générer aléatoirement un labyrinthe à base de tunnels et de cavernes en creusant tant qu'il est possible un surface ? Le résultat doit ressembler à cette sorte de gruyère (la partie praticable est en gris) :
Labyrinthe aléatoire avec murs droits
Continuer la lecture de "Génération aléatoire d’un labyrinthe de cavernes et de tunnels" →
Génération aléatoire d’un labyrinthe de cavernes et de tunnels

Shader d’explosion de pixels avec WebGL (2/2)

SoC, , , , ,
Cet article est le second (et donc dernier) d'une série portant sur la production d'une animation de "pixels" s'éloignant d'un point d'origine en tournoyant (autour de leurs centres et autour du centre de l'écran), en grossissant et devenant toujours plus transparents jusqu'à disparaître de l'écran.
L'explosion de "pixels"
Dans le premier article, nous avons vu comment créer le vertex shader (VS) et fragment shader (FS) et les alimenter en données pour que tous les "pixels" soient transformés et rendus en appelant une seule fois drawElements () par étape de l'animation.
Reste à voir comment produire l'animation. A étape régulière, il faut :
  • mettre à jour l'angle de rotation β, le facteur de zoom Z et les composantes du vecteur de translation de chaque "pixels" ;
  • alimenter les shaders avec les données des points auxquelles ces données relatives à la transformation sont annexées ;
  • commander la transformation et le rendu des "pixels".

Continuer la lecture de "Shader d’explosion de pixels avec WebGL (2/2)" →

Shader d’explosion de pixels avec WebGL (2/2)

Shader d’explosion de pixels avec WebGL (1/2)

SoC, , , , ,
En s'appuyant sur les shaders - le vertex shader (VS) et le fragment shader (FS) - de WebGL, produire une animation de "pixels" s'éloignant d'un point d'origine en tournoyant (autour de leurs centres et autour du centre de l'écran), en grossissant et devenant toujours plus transparents jusqu'à disparaître de l'écran, comme sur la figure suivante qui reprend quatre étapes :
Quatre étapes de l'explosion de "pixels"
WebGL est simple à utiliser. La difficulté réside dans un dilemme auquel le développeur est inévitablement confronté dès qu'il s'attaque à des effets un peu compliqués :
  • déporter la transformation des points dans les shaders si bien qu'il suffit d'appeler une fois drawElements () pour rendre tous les éléments lors d'une étape de l'animation, mais c'est au prix d'une inflation du buffer des points et d'une mise à jour fréquente de ce dernier ;
  • déporter la transformation des points dans le programme principal (ie : le programme JavaScript) si bien qu'il est possible de créer une fois pour toutes le buffer des points, mais c'est au prix d'autant d'appels à drawElements () qu'il y a d'éléments à rendre lors d'une étape de l'animation.
Pour être complet, il faut évoquer une troisième solution qui consiste à déporter la transformation des points dans le programme principal, lequel met à jour le buffer des points avec les résultats de cette transformation avant d'appeler une seule fois drawElements (), et ce à chaque étape de l'animation. Toutefois, cette solution doit être écartée, car elle revient à réduire le VS au rang de passe-plat entre le programme principal et le FS puisque le VS est alimenté avec des points déjà transformés. Or si le GPU peut assurer la transformation des points, autant l'utiliser, car cela libère le CPU pour d'autres tâches.
Cet article est le premier d'une série de deux. Il est consacré à la logique générale du programme et à l'initialisation de WebGL incluant l'écriture du code des shaders. Le second article sera consacré à la boucle d'animation. Les deux articles ne rentreront pas dans le détail d'un commentaire ligne par ligne du code de l'exemple mis à disposition, mais rien de ce qui concerne WebGL ne sera ignoré.
Continuer la lecture de "Shader d’explosion de pixels avec WebGL (1/2)" →
Shader d’explosion de pixels avec WebGL (1/2)

Enveloppe régulière d’un polygone quelconque

SoC, , ,
Comment calculer les coordonnées des points formant une enveloppe régulière d'un polygone quelconque, c'est-à-dire une version plus grande ou plus petite du polygone qui semble parfaitement s'emboîter avec ce dernier (enveloppe homothétique) ? :
Enveloppe homothétique d'un polygone
Le parfait emboîtage de l'enveloppe et du polygone tient au fait que la distance entre un sommet du polygone et le sommet correspondant de l'enveloppe est constante.
Calculer les coordonnées des sommets de l'enveloppe par simple application d'un facteur d'agrandissement aux coordonnées des sommest du polygone ne permet pas de parvenir au résultat souhaité. En effet, un tel facteur ne pourrait s'appliquer qu'autour d'un centre, c'est-à-dire un point qui devrait se trouver à égale distance de tous les sommets du polygone pour entraîner un éloignement ou un rapprochement de la distance attendue des sommets correspondants de l'enveloppe.
Or l'existence d'un ensemble de cercles de même rayon, centrés sur chacun des sommets du polygone, qui se recoupent en un unique point constituant ce centre, n'a rien de systématique. En fait, ce n'est le cas que pour des polygones très particuliers :
Possibilité d'enveloppe homothétique par agrandissement
Dans les autres cas, on constate en pratique qu'il est impossible de trouver ce jeu de cercles qui se recoupent en un même point. Ainsi, sur cet exemple, il serait impossible de positionner l'enveloppe résultant de la simple application d'un facteur d'agrandissement de sorte que les sommets de l'enveloppe se trouvent même à une distance constante des sommets du polygone auxquels ils correspondent :
Impossibilité d'enveloppe homothétique d'un polygone par agrandissement
Continuer la lecture de "Enveloppe régulière d’un polygone quelconque" →
Enveloppe régulière d’un polygone quelconque