Historiks #03 : Ludicks ?
TL;DR
Cet article, dans la continuité du précédent, fait l'étude de "Memory Full", un livre qui prétend décrire l'histoire de la demoscene CPC.
L'auteur a pris pour parti d'analyser les techniques classiques utilisées dans le domaine des jeux pour faire des comparaisons plutôt douteuses avec le domaine des démos, et ce sans réellement tenir compte de ce qui sépare ces mondes.
A force d'adjectifs et superlatifs, de prouesses et d'exploits, il encense des briques d'architecture standards et s'égare souvent dans le temps... Nous allons étudier quelques unes de ces briques (rasters, scrollings, ...) et voir ce que cache le caractère excessif des propos tenus dans l'ouvrage.
Enfin, je vais vous présenter un demomaker de base de la fin des années 80.
Lustrage Ludique !
On se demande bien ce qui a amené l'auteur à poser cette question ?
Il parait que cela dépend principalement du produit lustrant qui a été utilisé pour obtenir le meilleur brillant. Certains produits rendent fluorescents les codeurs de démos, mais ça ne compte pas vraiment (et ils ne font pas de jeux).
Non, on ne me l'a fait pas!
Plus sérieusement, si l'inventaire de jeux réalisés entre 1984 et 1991 utilisant certaines "techniques" présente un grand intérêt, il est absurde d'en faire un tel lustrage et comparer ça avec les démos si c'est pour émettre des jugements de valeur.
Sur le plan des techniques dites "hardware", l'auteur croit qu'il était hors norme de modifier les palettes de couleurs ou le mode graphique, de faire des scrollings hardware, de redimensionner des écrans.
Il ne tarit donc pas d'éloges et de superlatifs divers en utilisant des dizaines de fois les mots prouesses, astuces, exploits, découvertes, trouvailles, innovations, révélations, extrême onction, oignons, etc...
Je pense utile de tempérer son enthousiasme en rappelant ici que les techniques devant lesquelles il s'émerveille étaient des briques d'architecture classiques pour la plupart des micro-ordinateurs familiaux de l'époque.
L'architecture système du CPC en tenait d'ailleurs compte, contrairement à beaucoup de plateformes de même génération, et c'est sans doute pour ça que les programmeurs ont attaqué la programmation directe du "hardware" moins vite que sur beaucoup d'autres machines.
En effet, à l'instar de Direct X sur PC, le firmware vectorisé du CPC permettait de garder la compatibilité en cas d'évolution du code en rom ou du hardware (par exemple correction d'un bug dans un circuit propriétaire).
Quitte à évoquer les techniques utilisées par les jeux, une investigation plus sérieuse sur les "attentes" des développeurs sur ces fonctions classiques aurait sans doute été bien plus pertinente que de comparer deux mondes différents en mode dépréciatif.
Ce n'est pas pour rien si la rupture ou les interruptions à la ligne sont des caractéristiques standard sur les modèles CPC+.
La société Ocean, par exemple, avait exprimé des attentes sur les fonctions standards relatives aux scrollings matériels, ayant même un moment suggéré de retourner le moniteur...
Comparer une démo et un jeu est aussi inutile que de comparer un tableur avec une démo ou un jeu . Ces domaines n'ont pas les mêmes objectifs, les mêmes contraintes et les mêmes motivations.
Quitte à faire des comparaisons sur ces deux domaines, il aurait été préférable de s'attarder sur ce qui sépare un jeu d'une démo, et ne pas ergoter sur les personnes !
Une démo n'étant pas un jeu, ces dernières étaient développées assez rapidement puisqu'il s'agissait souvent d'une boucle "infinie" avec un code assez limité, avec peu de contraintes en relation avec l'espace mémoire utilisé.Elles n'avaient pas non plus besoin de tenir compte de l'utilisateur pour fonctionner.
Pour l'auteur, tout devient "prouesse et exploit" dès que le CRTC est mis à jour. Pourquoi s'arrêter en si bon chemin et ne pas s'extasier devant le premier usage du Z80A dans un jeu puisque les premiers étaient écrits entièrement en Basic ? Pourquoi ne pas s'étonner de l'usage de la pile comme pointeur de données, tant qu'on y est ? 🙄 (oups)
Au début du chapitre "Les prémices", page 7, il est ainsi question des "premières routines de jeux qui deviendront classiques dans les démos par la suite". Pour les profanes, les "routines" sont des morceaux de code déjà écrits. Si l'auteur n'a pas fait de confusion, c'est qu'il insinue ici qu'elles seront réutilisées telles quelles dans des démos, et on se demande bien de quelles démos il parle ?
Entre les pages 7 et 23, le livre énumère quelques jeux pour lesquels les programmeurs ont eu le temps d'exploiter les spécificités propres du CPC. L'auteur a fait un très gros travail en regroupant ces jeux par techniques et en les triant chronologiquement.
Si le talent de tous ces pionniers de la micro-informatique des années 80 n'est pas du tout à remettre en question, il est nécessaire de clarifier certaines choses au vu des comparaisons qui sont réalisées entre les jeux et les démos.
Les standards de développement des jeux !
Pour définir pourquoi les programmeurs de certains de ces jeux ont utilisé les capacités spécifiques du CPC, l'auteur livre l'explication suivante :
C'est très exactement l'inverse.
Lorsqu'un programmeur de jeu avait l'obligation de respecter un calendrier serré, et plus particulièrement pour les premières sociétés d'édition pour de classiques portages de ZX vers CPC, il était bien plus rapide et facile pour lui de ne pas tenir compte des spécificités hardware propres à la plateforme de portage, quitte à avoir un jeu plus lent ou moins joli.
Cela permettait en effet de reprendre le code d'origine en limitant ainsi les risques de bugs, de minimiser les coûts de développement et notamment lorsque le portage avait lieu avec une machine disposant du même processeur.
Si de très nombreux jeux sur CPC (Dun darach, Alien 8, Knight lore, Way of the tiger, ...) sont monochromes sans utiliser la palette du CPC ou n'utilisent pas les capacités du GATE ARRAY ou du CRTC, ce n'est pas une question de compétences, mais de budget et donc de "frigo à remplir et de loyer à payer" à la fin du mois.
Il était bien plus simple de reprendre tel quel le code d'un ZX SPECTRUM et d'adapter le code d'affichage au plus rapide, au détriment de la qualité du jeu. Même chose également lorsqu'il était question d'algorithmes software complexes manipulant des objets 3D.
Programmer un scrolling hardware demandait juste un peu plus de temps de développement car cela obligeait le développeur à s'affranchir du code préexistant pour les portages, mais rien de bien dramatique en soi. L'utilisation des capacités propres du CPC a donc eu lieu principalement sur des jeux spécifiquement conçus pour le CPC.
La seule technique hardware qui a réellement outrepassé les limites des spécifications fonctionnelles du CRTC est la rupture. Ce contournement des limites du CRTC demandait un temps de recherche complémentaire dont peu de développeurs disposaient. On imagine également sans peine les problèmes posés par certains jeux qui ont souffert des problèmes de compatibilité, comme le jeu "007 The Living DayLights" sorti en 1987 et qui buggait sur le CRTC 1.
Il n'est d'ailleurs pas exclu qu'il puisse exister en circulation une version du jeu "Crafton & Xunk" sans test CRTC qui crashe sur certains CPC, puisqu'il était courant que des révisions fleurissent en cours de route au fur et à mesure de la remontée de bugs à l'éditeur. Et ce d'autant que la technique utilisée ne posait problème que sur le CRTC 2 (un circuit ingrat et rare selon certains). Ce sont donc des choses qui auraient pu être demandées à Rémi Herbulot en personne.
Rasters Hardware 😱
L'auteur évoque la "découverte" des changements de mode graphique ou de palettes de couleurs, et prétend que pour parvenir à cet exploit, les codeurs devaient contourner le système.
C'est inexact.
Il est parfaitement possible de faire des rasters ou changer de mode à partir du système. Le vecteur #BD1C (MC SET MODE) du firmware permet de changer de mode en cours de balayage. Le vecteur #BD25 (MC SET INKS) permet de changer les 17 couleurs d'un coup. Ils ont été créés pour ça! Il est par ailleurs parfaitement possible de se synchroniser sur l'écran via une interruption système, comme l'ont fait de nombreux jeux, dont Genocide.
Le système sur CPC a été conçu pour offrir ce genre possibilités, qui existaient déjà sur d'autres plateformes plus anciennes.
On peut citer l'Enterprise 64/128 qui permet de modifier pour chaque ligne l'adresse de la ligne et sa palette sans que le processeur ait besoin de s'en occuper. Le MSX pouvait vectoriser sa palette à chaque ligne, comme l'a démontré Overflow dans sa démo IO que je vous remet pour le plaisir :
Scrollings Hardware 😱
Lorsque l'auteur évoque les "exploits" de scrolling hardware, on peut lire:
Les comparaisons sont pour le moins... péjoratives!
L'auteur semble croire que réaliser un scrolling hardware est une "prouesse" sur CPC, et que les demomakers n'étaient pas très malins pour ne "redécouvrir (que) des années plus tard" qu'on pouvait déplacer l'écran avec le CRTC !
C'est ballot personne ne s'en était aperçu.... 😂
Le CPC est livré de base avec le Basic Locomotive du CPC qui utilise constamment le scrolling hardware. Il suffit de taper l'instruction basic "LIST" pour déclencher cette magie.
Toute personne sur un CPC qui a déjà chargé une image dans la mémoire vidéo sait que l'adresse du début de l'image se "balade" continuellement et qu'il est préférable de faire une instruction basic "MODE" pour repositionner "l'adresse au début".
Ce n'est donc pas parce qu'on peut faire une chose qu'on veut la faire.
Il est donc utile ici de revenir sur la raison majeure pour laquelle peu de monde a utilisé ce type de scrollings dans les jeux. Un scrolling hardware standard sur le CPC pose un gros problème :
Verticalement, un déplacement a lieu 8 lignes à la fois, et horizontalement, le déplacement a lieu 16 pixels mode 2 à la fois.
Si ce déplacement a lieu à une fréquence de 50 images par seconde, le scrolling est parfaitement fluide car le cerveau reconstitue le "gap" entre les 2 images (en langage technique, on dit que le scrolling est "smooth"). Mais le scrolling est alors si rapide que cela nuit au gameplay.
Si le scrolling est ralenti à 25 images par seconde ou moins, le cerveau humain perçoit alors le gap entre 2 images. Plus le "gap" est important, plus l'effet visuel est désastreux. Et sur CPC, 16 pixels mode 2 représente un énorme gap.
Pour un développeur de jeu utilisant ce gap, une des rares options viable est de donner le contrôle du scrolling au joueur avec peu de choses à bouger. Les jeux Titan, Roland in the cave et Prohibition en sont de parfaits exemples. Ce principe atténue nettement le problème de jouabilité mais cela reste néanmoins assez déplaisant. Si la gestion des sprites, du gameplay, du son et du scroll peuvent être gérés au frame, le jeu sera fluide mais souvent très ou trop rapide. Si le framerate est trop ralenti c'est alors un carnage.
Une autre option consiste à faire scroller l'écran par "étapes" en "stoppant" le jeu, à la façon de certains jeux "beat'em'up". C'est le principe que j'ai adopté dans SKATEBALL sur PC, par exemple, car le jeu était juste injouable sinon.
Pour revenir au CPC, énormément de personnes ont joué à décaler leur écran horizontalement avec le CRTC en Basic car c'est enfantin à faire. Et ce d'autant plus que le Basic Locomotive intègre nativement une instruction d'attente de début de frame (FRAME) pour faciliter les choses. Que ce soit avec la mise à jour de R2 ou R12/R13 du CRTC, le résultat est toujours un déplacement d'un gap minimum mais conséquent de 16 pixels mode 2 en horizontal et de 8 lignes en vertical.
Trick en X ! (Episode 1) 😱
L'auteur évoque une technique de réduction du gap évoqué précédemment pour "ralentir" les scrollings horizontaux :
Une découverte impressionnante car il s'agit ici d'un usage totalement détourné du registre en question, et qu'il fallait bien toute l'astuce et l'expérimentation d'un programmeur de jeu pour imaginer ça." Memory Full, page 14
Il croit que modifier le registre R3 du CRTC pour diviser par deux le gap horizontal est une "découverte impressionnante", "étonnante", "astucieuse". 😆
Il va sans dire que beaucoup de programmeurs sur CPC ont bidouillé la valeur des registres CRTC permettant de bouger l'écran (R2, R3, R7) et de le redimensionner (R1, R6).
Il est "cocasse" de constater que l'auteur n'imagine pas qu'une personne allumant un CPC qui affiche "Ready" ne tente pas de tester diverses petites choses rapides de ce genre.
Le Basic Locomotive intègre nativement l'instruction OUT qui permet de modifier et de voir instantanément le résultat d'une modification de registre.
Si peu de développeurs de jeux ont utilisé la méthode R3, ce n'est pas car c'était difficile à trouver, mais uniquement car le gap n'était pas exact, et provoquait un effet "vibrato" plus ou moins conséquent en fonction du CRTC ou de l'écran utilisé (et sur les écrans monochromes GT65, c'était assez terrible).
De plus, sans "planquer les bords" (en fullscreen horizontal) ce décalage "hardware analogique" devait tout de même être masqué en soft pour éviter un effet stroboscopique de part et d'autres de l'écran de jeu, comme on peut le voir sur deux des trois jeux cités.
Enfin, cerise sur le gâteau, cela pouvait entraîner des conséquences colorimétriques fâcheuses sur d'autres écrans que l'écran standard du CPC puisqu'il existe une interface spécifique pour le brancher sur une télé.
Depuis le début des années 80 lorsque l'IBM PC est sorti, de nombreux magazines évoquaient le CRTC 6845. C'est le cas du magazine Elektor N°76 (octobre 1984).
Les magazines CPC n'étaient pas en reste, puisqu'on trouve des articles expliquant comment bidouiller le CRTC simplement en Basic (Amstrad Magazine hs 1 de février 1987), comment utiliser le firmware pour faire un scrolling hardware vertical (vecteurs SCR HW ROLL=#BC4D et SCR SW ROLL=#BC50) (Amstrad Magazine 27 de octobre 1987) ou même de petites routines de scrollings hardware horizontal (Am Mag 35 de juin 1988).
Finalement, pas besoin d'aller fouiller dans les coffres de Ubi Soft...
Elektor N°76 (octobre 1984) / Amstrad magazine Hs 1 (février 1987)
Amstrad Magazine 27 page 52 (oct 87) / Ammag 35 page 72.73 (juin 1988)
Un scrolling hardware, qu'il soit ralenti ou pas via R3, n'était pas un "exploit", et même si l'effet produit reste discutable, il a sans doute sa place dans un jeu....car un jeu n'est pas une démo : les contraintes et les attentes ne sont pas les mêmes !
On peut donc comprendre sans difficulté pourquoi ce n'est pas une technique ragoutante pour un demomaker, surtout sans un masquage software.
Trick en X (Episode 2) 😱
Il existe une autre manière de ralentir un scrolling hardware sans les contraintes posées par le registre R3 évoqué plus haut.
Cette méthode consiste à utiliser le principe de "switching de page".
Derrière ce terme barbare, il s'agit pour le programme de travailler sur 2 zones distinctes : travailler sur A lorsqu'on affiche B, et travailler sur B lorsqu'on affiche A. Avant que l'auteur ne se réveille en criant "prouesse", je précise que cette technique était un des b.a.-ba pour tout programmeur de jeu. En bref, cette méthode permet d'utiliser toute la CPU de la machine pour simplifier l'affichage de sprites et objets en évitant les glitchs visuels. Il existe d'autres méthodes, mais ce n'est pas l'objet de ce billet.
Les jeux qui utilisaient cette technique devaient "concéder" de disposer en mémoire de deux fois la taille de la page vidéo. C'était très contraignant car cela pouvait représenter la moitié de la RAM d'un CPC 464/664, puisque les jeux utilisaient rarement les 128 k d'un CPC.
Une démo n'ayant pas les mêmes "objectifs" et "contraintes" qu'un jeu, c'est pour ces raisons que mon premier scrolling hardware dans la démo "Longshot" est ralenti avec un gap de 4 pixels mode 2, qui suppose l'utilisation de 4 "switching de page", et consomme donc plus de mémoire.
Parmi les retours les plus nombreux que j'ai eu sur cette démo, c'est bien le côté "inhabituel" de cette vitesse "lente" pour un scrolling hardware qui est revenu souvent. Ce fut la première remarque de Digit par exemple, et Shap ne s'en est toujours pas remis 😄.
Il est "cocasse" que l'auteur ne l'ait pas remarqué tout de suite en évoquant ma démo en page 33/34. Il va cependant "très honnêtement" corriger le tir en page 52, non sans ré-évoquer les paternités et légendes urbaines.
En conclusion, beaucoup d'utilisateurs, programmeurs et/ou futurs "demomakers" connaissaient les scrollings hardware "non ralentis" mais les jugeaient juste inesthétiques et peu intéressants.
Trick en Y ! 😱
Comme je l'ai écrit plus haut, la seule technique vraiment "ingénieuse" sur un CPC était la rupture. D'autres plateformes le permettaient mais sur CPC, il fallait avoir bien compris certains principes du CRTC et de synchronisation vidéo pour y parvenir.
Il existe plusieurs méthodes pour "ralentir" un scrolling vertical. Si on sait aujourd'hui faire des scrolling verticaux au 1/64ème de pixels (enfin pour ceux qui ont lu le Compendium), à l'époque une méthode pour ralentir un scrolling ligne par ligne consistait à jouer avec le registre CRTC R5. C'est une méthode ingénieuse qui a été utilisée en conjonction avec une rupture dans deux jeux (Génocide et Warhawk).
L'auteur croit que ces scrolling verticaux à la ligne dans les jeux étaient rares car il fallait obligatoirement maîtriser la technique de rupture:
C'est techniquement inexact.
Un scrolling vertical hardware à la ligne peut parfaitement être réalisé en utilisant une autre technique qui ne nécessite pas de rupture. Il suffit par exemple d'utiliser le registre 9 du CRTC au lieu du registre 5.
Des jeux sans HUD séparé (sprites superposés) auraient très bien pu utiliser ce principe sans que la technique de rupture soit trouvée.
C'est bien la technique de rupture qui était astucieuse, car tout comme les futurs démomakers, la plupart des programmeurs de jeux n'avaient pas de machine temporelle pour remonter le temps, ni le temps d'éplucher tous les jeux de la "concurrence".
3D STRIKE !
Même lorsqu'il est question de routines 3D, l'auteur trouve le moyen de tacler ces demomakers si aveugles...
Bref, rien n'avait existé en DEMO !
Ludick Reverse
Après avoir copié comme des ingrats sur les jeux ou avoir été assez aveugles pour ne pas avoir vu le génie des "demomakers qui s'ignoraient", l'histoire reboucle quand ces demomakers se sentent désormais capables de réaliser un jeu...
Cette seule phrase suffit à résumer la vacuité de la comparaison entre ces domaines, au regard des compétences initiales des premiers demomakers.
Elmsoft, ayant gagné en expérience de développement, utilisera ses connaissances techniques approfondies de la machine pour développer un jeu. Il n'est pas question ici de "techniques de jeu" ou de "techniques de démo".
Chassez le naturel....
Codeurs préhistoriques !
Les programmeurs de la Rom Basic étaient "sans doute des demomakers qui s'ignoraient" ! 😆
Les concepteurs du CRTC et du GATE ARRAY aussi sans doute...
Mais alors ? Certains futurs demomakers étaient peut-être déjà sans le savoir des auteurs de jeux qui s'ignoraient et qui rêvaient, sans le savoir, qu'ils faisaient des démos ? Peut-être aussi étaient ils aussi des boulangers ou des écrivains de roman à succès qui s'ignoraient, qui sait ?
Cette dernière citation résume bien ce qui est développé dans ce chapitre sur les jeux. La notion même de démomaking est réduite au seul contenu technique des démos. Rappelons juste que....
Les programmeurs de jeux étaient ... des programmeurs de jeux.
Les programmeurs de démos étaient... des programmeurs de démos.
C'étaient qui les demomakers des années 80 ?
En 1987, la plupart des futurs demomakers sont encore au collège ou au lycée. Certains étaient déjà pratiquement dans la vie active. Un des points communs, c'est qu'ils avaient tous du temps et pas encore trop d'obligations.
Pour les plus jeunes, lorsque leur CPC flambant neuf est arrivé dans le cercle familial entre 1984 et 1987, il arrivait au mieux dans la chambre du futur démomaker, au pire dans le salon en "partage familial".
Souvent, ce jouet fort cher avait été acheté sous la promesse qu'il allait permettre d'améliorer les notes via des logiciels "éducatifs" 🤣. Une fois le pot aux roses découvert, les parents parvenaient parfois à obtenir de meilleurs résultats scolaires en soumettant le "jouet" à des restrictions d'usage.
Sans disposer de la "De Lorean" de Doc X, aucun de ces "jeunes" n'avait la possibilité de connaître même 10% de la logithèque du CPC. Les "crackers" les plus avancés devaient se procurer des originaux pour pouvoir exercer leur talent naissant et ce n'était pas une chose aisée. Encore aujourd'hui je continue à découvrir des jeux (et des démos) dont je ne soupçonnais même pas l'existence.
Le crack d'une protection n'a souvent rien de créatif. Il s'agit souvent d'extraire chirurgicalement un système de cryptage qui masque un code de vérification du support physique.
Ce sport a permis à une première génération de personnes diverses de se familiariser avec les arcanes du Z80A. Les protections empêchaient certes la copie et de tricher, mais elles présentaient surtout un "défi" intellectuel.
Je pense ne pas être le seul cracker à l'époque qui ne jouait pas du tout avec les jeux qu'il "déplombait". Le jeu "Le passagers du temps" est d'ailleurs assez révélateur de cette mentalité globale, car la protection se déclenchait après une certaine étape dans le jeu, et il fallait donc y avoir joué sérieusement pour s'en rendre compte. On ne compte pas le nombre de jeux qui souffraient de bugs divers liés à de mauvais cracks et incomplets car ils n'avaient pas été testés.
Bref, si les demomakers en 1987 profitaient encore principalement de leur machine pour jouer, certains vont progressivement se mettre à programmer et ceux qui vont créer les premières démos vont engendrer un nouveau phénomène culturel sur CPC, qui n'a rien à voir avec les jeux. L'entraide et la transmission rapide des connaissances sur le CPC ont favorisé le développement et la connexion des scènes démo en Europe.
Avec un recul de plus de 30 ans, il est bien sûr assez aisé de "constater" l'usage de telle ou telle technique dans un jeu, surtout lorsque le travail a déjà été fait par d'autres (notamment sur le portail CPC-POWER).
Il est un peu "facile" pour une personne qui a mis plus de 10 ans à apprendre ces techniques (de ses aînés) de se livrer à des comparaisons techniques péjoratives en s'étonnant benoîtement que ces premiers demomakers n'avaient vraiment rien inventé. 🙄
On verra au prochain épisode l'absurdité de ce type de comparaison, surtout lorsqu'elles dérivent sur des classements au "mérite" et amènent des "suspicions" douteuses et déplacées.
Longshot / Logon System