Vomitiks #06 : Mauvais ?
L'article présent dans 64NOP numéro 2, pages 36 à 38, est classé dans une catégorie "polémique". On se demanderait presque pourquoi...
L'auteur livre de nouveau une vision à spectre large de ce qui est facile et de ce qui ne l'est pas. Pour faire disparaitre l'octet de border situé à la fin d'une ligne sur le CRTC 0, il est seulement nécessaire d'écrire trois instructions au bon moment, ce qui est donc simple et très loin d'être insurmontable pour un programmeur CPC, surtout si ce dernier prétend être capable de faire de "petites RVI" sur CRTC 2.
L'auteur affirme que Madram a découvert une solution en 1927 que je me suis contenté de "reprendre récemment" dans le Compendium. Je ne me permettrais jamais de remettre en question les travaux de Madram. Si ce dernier a montré une solution à quelques privilégiés, c'est que c'est très certainement vrai. Je n'ai aucun problème avec ça. Cependant, Madram ne me l'a jamais dit, montré, et ne l'a expliqué nulle part publiquement, tout comme il ne l'a jamais utilisé dans une production dont j'ai connaissance. Hicks s'est bien gardé de préciser ce détail afin de laisser croire à ses lecteurs qu'une solution était connue de tous.
Je n'ai donc pas "repris" une solution comme il l'affirme. J'ai découvert une solution. C'est peut-être la même que celle de Madram mais il est impossible de le savoir sans disposer du code qu'il aurait (conditionnel) partagé avec Hicks. Bref, le seul code actuellement disponible publiquement et qui exploite cette solution est contenu dans un des modules de test de SHAKER. L'image ci-dessous montre la disparition de 5 "artefacts" de border (le border est la couleur jaune entre les bandes de couleur) sur une même ligne :
Shaker Module A Test 2 (Screenshot Amspirit)
Le compendium explique de manière détaillée la logique de cette technique démontrée dans SHAKER :
L'auteur est bien entendu libre de ne pas utiliser les techniques décrites dans le Compendium si il croit que ça ne concerne que des "effets très basiques". Il fait cependant un amalgame douteux entre "timing serrés" et "qualité de l'effet". Et par ricoché, il insinue que l'usage de cette technique réduirait la "qualité" des effets. On peut se demander pour quelle raison l'auteur essaie de nouveau dans son article de dévaloriser une nouvelle technique présentée dans mon document. La notion de "timing serrés" est également très subjective. Il suffit d'étudier le code de quelques démos qui croient exploiter au mieux chaque NOP d'une ligne pour se rendre compte que c'est à géométrie variable, étant donné qu'il est possible de faire une même chose de plusieurs façons différentes.
En réalité, cette technique est utilisable dans une multitude de contextes sans préjuger de l'effet obtenu. Dès lors qu'une "ligne" se termine dans l'espace visible, elle peut servir à gérer une compatibilité avec le CRTC 0 si cela s'avère possible. Les "timings serrés" d'une ligne n'ont pas de rapport avec la sophistication d'un "effet".
On a vraiment du mal à croire que ces propos sont tenus par une personne qui se revendique "demomaker". L'auteur a-t-il ainsi chouiné lorsqu'il a appris qu'il fallait "manipuler de nombreux registres" quand Shap lui a enseigné comment programmer des ruptures complexes ? Pas si inexploitable que ça!
Il est bien évident que dans certaines circonstances, perdre des NOPs pour gérer la compatibilité entre différents CRTCs est impossible ou très difficile.
A ce titre, l'auteur va ensuite disserter sur quelques démos qui ne fonctionnent que sur CRTC 1 pour justifier de leur incompatibilité avec les autres CRTCs.
Il ne sert pourtant à rien de pousser des cris d'orfraie ("Pourquoi sont-ils aussi mauvais ?") pour enfoncer une porte ouverte. Chacun est libre de tenter (ou pas) d'adapter son code pour le rendre compatible, voire dégrader un effet (ou l'améliorer sur un CPC+). Personne ne sera hué pour ça, et encore moins pour avoir essayé. Peut-être que Hicks pense qu'une démo devrait fonctionner sur tous les CRTCs de la même manière...Heureusement, tout le monde n'a pas la même opinion.
Hicks évoque ici une autre démo incompatible dont il est le programmeur. Personne ne lui en aurait voulu si il avait remplacé la musique "samplée" par une autre musique rythmée sur les autres CRTCs pour que cette démo soit visible sur tous les CPCs, puisqu'il affirme être en mesure d'en adapter l'effet sur CRTC 0. Il faut néanmoins respecter la vision absolue de l'artiste qui ne souhaite pas dénaturer l'essence même de son oeuvre intemporelle 🤪.
Là ou le bât blesse, c'est que ce qu'il prétend faire est impossible sans utiliser la technique RVLL décrite dans le Compendium, et utilisée par la démo DSC#4 sur CRTC 0 et 2.
Offset, l'auteur de la démo en question, et auteur de l'émulateur ACE, a cependant l'air de penser le contraire... Lui non plus ne semblait pas connaitre l'existence de la méthode de Madram pour faire disparaitre l'artefact de border, car il n'y fait pas référence (la technique n'était pas si connue que ça finalement). D'ailleurs, en novembre 2022, sur CpcWiki, il a admis s'être servi du Compendium et de Shaker pour faire évoluer son émulateur ACE (version 1.25, septembre 2022). Cette intégration de sous-fonctions du registre CRTC R8, bien que très incomplète, a été réalisée dans l'objectif d'adapter sa démo, comme il l'explique lui-même ici:
On peut saluer ici la volonté de Offset d'envisager l'adaptation totale ou partielle de sa démo au CRTC 0. Encore une fois, personne ne lui jettera un jambonneau cuit si il n'y arrive pas. Par contre, il serait respectable qu'à l'avenir, il ait la gentillesse de citer ses sources lorsqu'il exploite le travail d'autrui.
S&KOH (Left) / OUT(DATED) (right)
Hicks feint d'ignorer que cette démo (à droite) à été critiquée non pas pour son incompatibilité, mais car elle plagiait de manière peu sympathique la démo S&KOH (à gauche), réalisée par Overflow en 1991.
En effet, on peut lire dans les textes contenus dans cette démo (OUT)DATED que Overflow se contente de faire des démos "faciles" ("easy-made demo" dans le texte). Il faudrait sans doute demander à son auteur Grim (alias MrEarWig) si il le pense toujours et si il s'est finalement détaché du pilori.
Il se disait effrayé ("scared") de la voir prise comme modèle technique encore en 2008 par des "moutons". Au détour de textes condescendants, il indiquera que dans S&KOH, ce ne sont finalement que des additions et des boucles de 64 µsec faciles à faire (sic). La démo de Grim sera diffusée comme une "hidden part" (partie cachée) à l'insu même des auteurs de la démo principale (qui en rient encore...).
Pour les profanes, une partie cachée implique que le spectateur trouve une séquence "secrète" de touches afin de pouvoir accéder à une démo de second rang. Il s'agissait par ce biais d'accentuer le côté "obsolète" supposé des techniques découvertes par Overflow.
De nos jours on peut encore trouver ce type de séquence secrète dans un émulateur pour faire apparaitre des textes "sympathiques", comme on peut le découvrir ici.
L'auteur de l'article, qui professait ce type de discours à l'époque, va déclarer récemment, dans une histoire toute personnelle de la demoscène CPC, que la démo OUT(DATED) est un hommage à S&KOH. On ne doit pas avoir la même conception de ce mot et un des relecteurs a du louper quelques pages.
Ce relecteur n'a d'ailleurs pas signalé 2 fois l'erreur sur la date de parution de sa propre démo. En effet, dans son roman, le justicier du datage au carbone 14 des démos CPC indique qu'elle est réalisée en 2006, puis une autre fois en 2007, alors que les textes et les commentaires du source public de la démo indiquent qu'elle est de 2008. Une amnésie collective peut-être ?
J'en profite pour rectifier une autre erreur malencontreuse dans la citation ci-dessus. L'introduction de la démo S&KOH occupe plus de 312 lignes, mais sa rupture verticale est parfaitement exécutée sur les CRTC 0 et 1 : Autrement dit, il y a une seule HSYNC par ligne de 64 µsec, toujours située à la même place. Elle elle juste plus courte sur CRTC 1 que sur CRTC 0, et donc l'image est décalée à droite sur CRTC 1, comme on peut le voir ci-dessous :
Introduction démo S&KOH. A gauche CRTC 0. A Droite CRTC 1
Hicks semble avoir oublié qu'il évoque dans son livre les "previews diffusées par Overflow mi-1994" (page 166 de MF) et dont "la seconde preview était l'écran « High Technology», un déluge de ruptures diverses, dont des ruptures verticales" (page 105 de MF). Ces previews, présentées en 1992 lors de l'Euromeeting 2, étaient pourtant "exécutées proprement" :
Selon Hicks, il faudra attendre 2006 pour qu'enfin, en avant-première mondiale, les spectateurs (médusés !) admirent la première rupture verticale parfaite montrée dans la démo cachée OUT(DATED).
Il faudra néanmoins attendre 2018 pour que ce dernier démontre qu'il est encore possible de bidouiller empiriquement avec les tailles de HSYNC dans sa démo DenScreen, évoquée dans un précédent billet. Du coup, est-il vraiment bien placé pour juger si un code ou un effet est propre ou sale ? Il devrait peut-être réellement lire le Compendium plutôt que de passer son temps à le déprécier.
Pour revenir sur le sujet de la compatibilité, on observe que Grim s'est livré à un exercice extraordinaire. Il a critiqué d'une part la technique de RVI mise au point par Overflow à cause de ses problèmes de compatibilité, et ce afin de promotionner la technique de RVMB qu'il emploie (au titre de calculs réalisables dynamiquement durant la ligne).
Il explique ensuite après qu'il n'a pas (encore) réussi à enlever les octets de border sur CRTC 0 (mais semble alors déterminé à le faire) et qu'il n'a pas eu le temps de l'adapter sur CRTC 2 (...).
Si on résume la petite affaire, on a une démo "hommage-plagiat" faite rapidement, et tellement simple qu'elle est modestement intégrée en douce comme partie cachée dans une méga démo. Elle exploite une technique RVMB qui était connue depuis au moins 1992 (voir encart ci-dessous) et l'auteur critique la technique RVI de la version originale à cause de ses problèmes de compatibilité.
admin
Sauf qu'à y regarder de près, la démo S&KOH fonctionne sans artefact visuel sur 4 des 5 CRTCs et pourrait même aujourd'hui fonctionner sur l'intégralité des CPCs sans problème, moyennant une adaptation au CRTC 2.
La démo S&KOH bouge également un sprite animé sur le dessin central. Le plagiat de (OUT)DATED n'a malheureusement pas été poussé jusque là. Cette démo aurait peut-être du plutôt s'appeler (SUB)PRODUCT ?
Pour réaliser peu ou prou les mêmes effets, on a ici l'exemple de 2 techniques différentes utilisées. L'une présente des problèmes de compatibilité que Overflow a réussi à régler en grande partie en 1991. L'autre est plus simple a mettre en oeuvre, surtout en 2008, mais reste à priori incompatible avec les autres CRTCs.
Enfin, la technique RVMB complique un peu les choses si il fallait pousser l'exercice jusqu'au bout et bouger le sprite animé que j'ai mentionné dans le paragraphe précédent, car la mémoire d'une ligne n'est plus linéaire et l'adresse change tous les 16 octets. Rien d'insurmontable cependant pour quiconque est capable d'avoir un tel recul sur ces techniques dépassées ("outdated") 😅.
Ce ne sont que des additions, voyons! On me souffle aussi que ce ne sont que des octets ! Bigre !
Heureusement que Overflow avait un CRTC 0... On a eu chaud, Marcel !
Longshot / Logon System