DEMOS ET MERVEILLES
[Article Toxic Mag]
Une introduction au petit monde de la démo
A l'origine était le piratage.
Au départ, quand un groupe de pirates crackait un nouveau jeu, son nom était affiché à l'écran durant le chargement. Les pirates sont des gens très mégalomanes. Lorsqu'ils déplombent un soft, il y a deux motivations principales:
- l'exploit technique, car il s'agit de partir en croisade contre l'auteur de la protection, d'infiltrer son code, de contourner ses sentinelles, de tromper sa vigilance pour finalement se retrouver maître des lieux et y planter son drapeau. Faire sauter la protection de tel ou tel auteur réputé "coriace" devient un défi fabuleux auquel peu de pirates résistent, et de véritables bras-de-fer virtuels s'organisent dans les profondeurs méconnues du programme à cracker.
- la reconnaissance de ses pairs, car il s'agit en cas de victoire de faire savoir à tout le monde - et j'utilise cette expression à dessein - qu'Untel a réussi à triompher de la fameuse protection de tel programme. Le pirate est mégalomane, car il vise une renommée internationale, et pas uniquement limitée à son pays d'origine, voire - horreur! - à sa ville ou à son quartier. D'où les messages "Cracked by..." inscrits sur la page de présentation du soft avant de le relancer dans le réseau. D'où l'emploi de pseudonymes, puisqu'il est évidemment hors de questions de signer de son vrai nom un acte tout ce qu'il y a de plus illégal.
Puis, un jour, une idée émerge de l'esprit d'un pirate encore un peu plus mégalomane que les autres. C'est bien, un message "Cracked by...", mais il est un peu statique. Pour faire mieux - mieux que le voisin s'entend - on pourrait par exemple le faire rebondir en dessous du nom du jeu, non? Oh! Et puis on pourrait faire défiler un texte en bas de l'écran pour présenter les membres du groupe et leurs fonctions! Et puis si on mettait une musique en même temps? Et de jolies fontes pour le texte plutôt que les moches fontes système! Etc..
...la machine était lancée...
A partir de ce jour, on vit se greffer en préambule de chaque jeu cracké un petit bout de programme appelé assez judicieusement intro, dont le but était bien entendu d'introduire le groupe responsable du crack, le jeu piraté, voire quelques détails techniques sur les conditions de réalisation du méfait - véridiques ou non, parfois assez folkloriques ("This game was cracked in 1'28"), le but du jeu étant encore une fois d'en mettre plein la vue au reste du monde.
En mettre plein la vue? Le mot est faible. La compétition qui existait entre les crackers en ce qui concernait les protections n'était rien, rien du tout, à côté de celle qui fit par la suite rage entre les coders des intros! – le cracker et le responsable de l'intro n'étant pas toujours une seule et même personne.
Chaque groupe veut toujours surpasser les intros des autres, en y rajoutant tel ou tel effet graphique inédit, des logos du groupe de plus en plus beaux, des textes défilants (scrolltexts!) de plus en plus gros, de plus en plus imposants, l'idée générale étant toujours la même: faire mieux que le voisin, faire plus joli, plus rapide, de préférence en donnant dans la démesure et le grand spectacle. Qu'on ne s'y trompe pas: la compétition qui existe n'a rien de malsaine, la jalousie est au contraire le meilleur des carburants. (dixit "E", chanteur du groupe Eels, qui sait de quoi il parle!)
Et un beau jour, ce qui devait arriver arriva: la programmation de ces intros étant de plus en plus longue, et par ailleurs aussi intéressante, sinon plus, que le crack de protections de plus en plus lamentables, un groupe décida d'abandonner définitivement le déplombage pour se consacrer exclusivement à la création de ces petites intros si prisées par les utilisateurs. Ceci appelle quelques explications:
- rares sont les éditeurs qui développent des protections sérieuses. La plupart du temps une même protection est utilisée d'un soft à l'autre pour une société d'édition donnée, ce qui fait qu'une fois le premier cracké, s'occuper du suivant ne demande plus aucune recherche ni aucun effort puisque la protection est la même. En d'autres termes, l'exploit n'en est plus un, il n'y a plus aucune saveur dans le plat, et le tout devient vite lassant. Les éditeurs quant à eux ne développent pas de nouvelles protections, ou très rarement, pour de simples raisons de temps (c'est long à faire!) et d'utilité (quelle que soit la complexité de la protection, elle ne sera jamais inviolable). Le seul facteur limitant est le temps mis par le cracker pour la déplomber. Citons pour mémoire à ce sujet le célèbre Dungeon Master qui ne fut jamais complètement déplombé. (Aparté: on n'a jamais fait un jeu aussi fabuleux!!!)
- les utilisateurs aiment ces intros car elles sont souvent de petits bijoux de programmation, et ils s'en rendent compte, particulièrement lorsque le jeu qui suit l'intro est nul, ce qui arrive souvent!
Cette dernière remarque est très importante et déterminante pour la suite: les coders qui produisent ces intros sont souvent bien meilleurs, infiniment meilleurs que les programmeurs du jeu cracké. Mais pourquoi donc ne font-ils alors pas de jeux à leur tour?! Bien souvent, ils hésitent à contacter une société d'édition à cause de leurs antécédents - n'oublions pas que ce sont d'anciens pirates, et qu'à l'époque les rumeurs allaient bon train à propos de pirates appréhendés et condamnés, d'autant plus que l'APP - Agence pour la Protection des Programmes - était très active en ce temps là. Signalons tout de même que par la suite furent créées des sociétés d'édition entièrement dirigées par d'anciens pirates/demomakers - Thalion Software sur Atari ST - ou plus tard par de purs demomakers fraîchement arrivés dans le monde de la démo – Scavenger notamment, dont on attend beaucoup sur PC. Mais nous n'en sommes pas là. Pour l'heure, les coders d'intros pirates tiennent à leur anonymat - un comble pour des gens visant une renommée internationale!
C'est, entre autres, pour remédier à cet inconvénient que furent créés par la suite ces fameuses démos. Une démo, à la base, n'est ni plus ni moins qu'une version un peu plus évoluée, plus élaborée, plus poussée, d'une intro. Ce n'est plus une intro - il n'y a plus de jeu derrière à introduire, après tout! – mais ça y ressemble beaucoup. Une démo, c'est une démonstration. De quoi? Deux réponses possibles... D'abord des qualités de chacun. Des capacités du coder, de ce qu'il sait faire. Des œuvres du graphiste, de sa maîtrise des couleurs, de l'utilisation des trames. Des compositions du musiciens, enfin, la dimension sonore étant un élément essentiel à l'ensemble du programme ainsi obtenu. On a vu, dans ce cadre, des groupes créer des démos dans le seul but d'être repérés et engagés par la suite dans une boîte de jeux - exemple trivial et inévitable: les légendaires Cuddly Demos des Carebears en 1989...
Une démo, c'est aussi une démonstration des capacités de la machine. La compétition entre groupes existe. Celle entre machines également. Les premières intros ont sans doute vu le jour sur C64, dont le concurrent direct vers 1985 était le CPC 464. Par la suite, les intros ont été exportées sur Amiga et Atari ST. La guerre ST/Amiga qui s'en suivit se prolongea pendant une dizaine d'années...Ce sont sur ces deux machines, aujourd'hui dépassées, que l'histoire des démos se mit en place.
Car les démos ont vécu. Les démos actuelles n'ont rien, rien à voir avec les démos initiales.
EXTREME LIMITE
On a déjà signalé le fait que les coders de démos étaient souvent incomparablement meilleurs que les programmeurs habituels - j'allais dire normaux... On peut expliquer ce fait de plusieurs manières.
Le coder ne programme pas parce que c'est son travail ou parce qu'il a besoin de l'informatique pour réaliser un projet annexe, le coder programme parce qu'il aime ça. Le coder de démos, particulièrement, n'hésite pas à passer une ou plusieurs nuits blanches sur un bout de code particulièrement tordu - et je n'ai pas dit un programme, mais un bout de code! Il pense à son code en permanence. Il est particulièrement têtu. Et également très patient. Lorsqu'il a une idée en tête, il ne la lâche pas. Il l'analyse sous tous ses angles, il en fait le tour, il en extirpe la moelle, ronge les os, et ne l'abandonne qu'une fois que, du statut d'idée, elle est passée à celui de programme concret! Le coder finit toujours par gagner, à l'usure, là où un autre aurait depuis longtemps laissé tomber. Par ailleurs, le coder est très naïf, ou peut être simplement n'a t-il confiance en personne. Toujours est-il qu'il lui arrive de se lancer dans des entreprises impossibles, uniquement pour voir si ça l'est réellement, ou juste dans le but avoué de réussir, lui, l'impossible - toujours la même politique de dépassement de soi et de recherche de l'exploit technique.
Ne bougez-pas, les choses deviennent magiques ici. Vous vous en doutiez peut être: à force de persévérance, d'obstination un peu bornée et d'ingéniosité, il arrive bien souvent que l'"impossible" se produise et devienne réalité, il arrive bien souvent que le demomaker malin arrive à repousser complètement les limites de sa machine, bien au delà des possibilités que lui prête la croyance populaire. ("Conventional wisdom is stupid", you know...)
L'exemple qui suit concerne l'Atari ST - ma machine de prédilection - et le fullscreen, encore appelé overscan, technique de programmation permettant d'agrandir logiciellement la taille de l'écran, c'est-à-dire réussir à écrire dans les bordures qui entouraient les 320*200 pixels utilisables du ST. Typiquement une démarche de demomaker. Qui serait assez idiot pour envisager ne serait-ce qu'une seule seconde - quant à essayer, n'en parlons pas! - d'aller mettre des choses "en dehors de l'écran", donc faire tracer au ST plus de pixels que ce pour quoi il a été prévu, avec tout ce que ça implique au niveau hardware? Parce qu'évidemment, le ST n'est absolument pas capable de réaliser cela à la base, et a priori c'était aussi faisable que, mettons, faire voler une voiture.
Et pourtant...
Oh, ça n'a pas été simple! Ca a même demandé près de deux années de recherche, de travail et de réflexion, d'essais, de succès et d'échecs à plusieurs groupes de coders dans plusieurs pays différents. Notons que ces recherches s'effectuaient dans le cadre de leurs loisirs, ils n'étaient absolument pas payés pour faire ça. D'une manière générale, l'argent n'a rien à voir avec le monde de la démo. Bien au contraire, l'éthique du Bidouilleur prône la libre circulation gratuite des informations. Le sens de l'honneur, dans le même ordre d'idées, a encore de la valeur dans ce monde. Mais revenons à nos petits coders de fullscreen. Petit à petit, à force de coopération, de hargne, ils y sont arrivés. D'abord un petit succès - suppression de la bordure bas -, puis un autre - "Death Of The Left Border" par TNT Crew -, puis un autre... et enfin, un beau jour, le miracle, accompli par Level16 - groupe légendaire - dans la Union Demo - démo tout aussi légendaire, sinon plus! -, soit un overscan total permettant d'utiliser 448*274 pixels en lieu et place des 320*200 habituels...
Irréel.
Il faut avoir vu une fois dans sa vie se décomposer le visage d'un programmeur normal face à un fullscreen pour apprécier et savourer à sa juste valeur l'exploit réalisé. Je peux décrire parfaitement le phénomène pour l'avoir moi même subi... Il y a une micro-fraction de seconde qui semble durer une éternité, pendant laquelle le cerveau n'enregistre vraisemblablement pas ce que les yeux lui envoient. Il refuse de valider, donc cautionner, une information pareille: c'est impossible, ça n'existe pas, ça ne peut pas être. Le cerveau, c'est le cas de le dire, n'en croit pas ses yeux. Puis c'est le déclic. Le moment horrible de l'histoire, où on réalise que, si, si, on a beau dire et penser ce qu'on veut, on a beau maîtriser parfaitement la machine posée en face de nous et croire, assez naïvement, qu'on en a fait le tour, on a beau refuser d'admettre ce qu'on voit, bordel, merde, ils l'ont vraiment fait ces cons!! Mais alors je ne suis pas si bon que ça? Je ne connais pas tout ce qu'il est humainement possible de connaître sur un ST? Je... je... mais bordel ça n'existe pas, ça, non...!!
Suit une période de déprime assez gigantesque, où l'estomac se noue, où se forme une méchante petite boule dans la gorge, où la panique s'installe et où le doute revient en force.
Cette période dure à peu près trois minutes.
N'oubliez pas, un coder est avant tout un acharné. Soit. Ca existe. D'accord. Ils l'ont fait. Donc c'est possible. Y'a pas de raison, je ferai pareil, et je ferai même mieux. La target est lockée, la proie identifiée, plus question de la lâcher. Dorénavant, toute l'énergie du coder sera entièrement dévouée à cette tâche: rabattre le caquet de cette bande de guignols qui s'imaginent qu'ils vont impunément ridiculiser l'ensemble des coders de la planète!
Et c'est reparti. A grands coups de désassembleur s'il le faut, l'offensé va y passer une nuit, deux nuits, tout son temps, mais il n'est pas question de dormir ou d'aller manger avant d'avoir compris comment ça marchait!
...vous avez compris maintenant les règles de ce jeu étrange, je pense.
Etrange, ai-je dis? Pas si sûr. Cela peut paraître étrange, certes, pour des personnes normales. Il est bien évident que le comportement décrit ici est au contraire horriblement banal pour un demomaker, et que cette situation n'est pas inhérente au fullscreen, même si c'est un exemple qui s'y prête bien. Nous reviendrons à cette différence fondamentale de comportement par la suite.
Pour le moment, revenons à notre question initiale: pourquoi le coder de démos réussit-il à faire des programmes plus jolis, plus rapides et plus fiables que les autres? Les éléments de réponses ont été donnés. Il réagit en chasseur, d'instinct: il fixe lui même sa proie - le fait qu'elle soit réputée insaisissable ne le dérange pas - et sait s'y tenir - il la traquera jusqu'à la mort de l'un ou de l'autre. De plus, en cas d'échec individuel, le loup solitaire qu'est le coder agit comme son alter ego animal, appelle sa horde à l'aide et unit ses forces à celles des siens, vers un objectif commun. Le fullscreen n'a pas été trouvé par le coder de Level16. Sa version finale, seule, a été synthétisée par ce dernier, grâce à l'aide et à l'expérience de tous les coders précédents, et ce, qui plus est, de manière internationale, grâce aux contributions de programmeurs allemands, anglo-saxons, scandinaves... En matière de démos, l'Europe existe depuis longtemps!
Les adeptes de l'intelligence artificielle savent très bien quels sont les avantages d'une intelligence collective. Le coder bénéficie justement de ce type de conscience et d'expérience collective. Là où un programmeur de jeu est seul face à un problème, le demomaker peut lui opposer l'expérience et la richesse de tous les coders qui l'ont précédé. Cette expérience, il en a hérité à travers tous les désassemblages successifs du code des autres - un passé de pirate est ici très utile! -, ou en rencontrant et en parlant avec d'autres coders. Il existe des réunions, régulières, des conventions organisées dans tel ou tel pays, appelées coding party (ou "CP") pendant lesquelles les demomakers se regroupent pour dialoguer, discuter, parler de code, échanger des trucs et astuces de programmation, mettre au point un projet commun - il arrive fréquemment qu'un groupe soit composé de trois personnes habitant trois pays différents! - ou tout simplement rencontrer "en vrai" la personne avec laquelle ils discutent depuis six mois via la télématique. Attention! Il ne faut surtout pas confondre les CP (Coding Party) avec les...CP (Copy Party)! Les Copy Party, c'est de l'histoire ancienne... du temps des pirates. Au contraire, tout est fait dans les Coding Party pour respecter la plus stricte légalité. Interdiction formelle de déplomber le plus petit soft, ce n'est pas le but. On a même vu des CP interdire l'alcool, même la moindre petite bière pour être sûr que tout se déroule correctement. Inutile de parler des drogues. Le but avoué, c'est l'échange d'information et la mise en place de nouveaux contacts. Pour le reste, y'a les boîtes de nuit!
La Coding Party permet donc de se tenir au courant. Croyez-moi, une bonne idée n'est jamais perdue. Elle est vite récupérée par quelqu'un, optimisée, améliorée jusqu'à l'extrême, modifiée, retouchée, transformée... Elle passe de main en main et on ne l'abandonne qu'après overdose. Si ça ne suffit pas, le coder n'hésite pas à inventer lui même de nouvelles techniques de programmation quand les techniques disponibles ne sont plus assez rapides. C'est ainsi que l'on obtient ensuite des articles aux titres accrocheurs - "Plus rapide que l'assembleur!" - lorsque, bien plus tard, un journaliste un peu curieux découvre que, tiens, voilà un programme qui fait des choses inédites...
Que peut bien produire, à côté, un programmeur isolé, gavé d'articles techniques obsolètes et incomplets?
DE L'INVENTION DU SYNC-SCROLLING
On a pu lire dans des journaux très sérieux et très compétents des choses totalement fausses à propos du ST. Personne ne les blâme. Tout change. Et on ne peut pas tout savoir. Malheureusement les gens ont tendance à prendre ce qui est inscrit dans les magazines pour des vérités absolues et immuables. Une erreur cruciale, à n'en pas douter. Lorsque le ST est sorti, par exemple, tout le monde était d'accord pour dire que "faire un scrolling fluide sur cette machine" était impossible. Evidemment, dans ces conditions, le programmeur de jeux qui voit son scrolling ramer ne s'inquiète pas outre mesure puisque même "ceux qui savent" sont supposés obtenir un code lent.
Sur ces entrefaites, bien sûr, arrive quelqu'un pour faire bouger un peu toutes les mentalités: Steve Bak, loué soit son nom. Ce monsieur n'est pas du tout un demomaker, bien qu'il utilise certaines techniques issues du monde de la démo. Son jeu, Goldrunner - le jeu qui le rendra célèbre auprès des ST-Users, qui l'appelleront modestement par la suite "Monsieur Scrolling" - est une merveille de rapidité et de fluidité. Du jamais vu à l'époque sur un ST. Et tous les "spécialistes" de ne pas en croire leurs yeux, de tomber des nues, et d'écrire des choses comme "bien des programmeurs paieraient cher pour connaître les secrets que contiennent les kilos de code machine de ce jeu."
Mais il y a plus.
Goldrunner, c'est bien. Mais - les détails techniques importent peu - la chose n'est pas parfaite, et certaines limitations subsistent au niveau du nombre de couleurs utilisables, de la taille de la zone à scroller, etc – limitations parfaitement invisibles pour le grand public, qui s'inquiète peu de savoir si le soft scrolle "deux plans" ou "quatre plans", il ne sait même pas ce que c'est.
Disons pour simplifier que le demomaker de base, jamais satisfait, avait encore du pain sur la planche au niveau des scrollings d'écrans.
A ce moment du récit, il convient de rappeler la compétition existante entre le ST d'Atari et son concurrent direct, le Commodore Amiga. Ce dernier possède la faculté de réaliser des scrollings d'écrans hardware, c'est-à-dire sans consommer de temps machine, c'est-à-dire de manière fluide et lisse sans aucune difficulté, pour le plus grand bonheur des programmeurs de jeu sur Amiga qui ne manquèrent pas d'utiliser toutes ces possibilités à bon escient.
Sur ST, c'est plutôt le désert. Il y a un 68000 au milieu, et grosso modo pas grand chose autour. Pas de registres hardware pour faire des scrollings (le scrolling hardware étant appelé hardscroll), pas de Blitter pour afficher des sprites rapidement ou faire du remplissage 3D, pas de Copper pour faire des effets de couleur dans tous les sens - autant de processeurs qui firent la joie des coders sur Amiga, rendant leurs démos certes plus jolies, mais incomparablement moins impressionnantes que sur Atari où tout devait être fait par le programmeur.
En d'autres termes, quand il s'agit de réaliser un scrolling sur Amiga, il n'y a pas de problèmes, on fait du hardscroll, ça ne consomme aucun temps machine.
Quand il s'agit de le faire sur un ST, la seule manière est de le faire à la main, c'est-à-dire recopier tout l'écran avec le 68000 à chaque fois que c'est nécessaire. Inutile de dire que le programme qui en résulte n'est pas des plus rapides. Une vraie plaie. Une plaie qui ne manquait pas de faire doucement rigoler les possesseurs d'Amiga lorsqu'un Atariste osait prétendre que "sa machine était la meilleure" - ce qui se faisait beaucoup...
Seulement voilà, c'était compter sans le génie - oui! le génie! - des coders ST.
Tous les domaines ont leurs héros... Et ce jour là, le héros s'appelait Nick. Il allait, du jour au lendemain, devenir le coder le plus connu, le plus envié, sans doute également le plus maudit de la planète ST. L’idole absolue de tous les amateurs de démos, l'homme à abattre pour tous les coders. Bref: le "coder le plus Dieu". Il avait, tout simplement, fait du hardscroll sur un ST. Un scrolling hardware. Sans scrolling hardware. Mais qui prenait autant de temps machine qu'un vrai. Soit rien du tout. Incompréhensible. Comment? Le mystère est resté entier pendant des mois et des mois, au fur et à mesure que la cote de popularité de Nick grimpait en flèche. Le "hardscroll ST" était devenu le centre de toutes les recherches, la routine mythique dont tout le monde rêvait. Aller regarder le source dans la Cuddly? Facile à dire. S'il y a quelqu'un capable de développer une protection valable, c'est bien un ex pirate. Les Carebears en étaient, et autant vous dire que la protection mise en place tenait la route! Ce qui nous laissait avec un hardscroll moqueur, narguant ouvertement le spectateur, comme pour lui dire "tu ne me comprendras jamais"...
Même schéma de principe que pour le fullscreen: devant la chose, soit vous vous tirez une balle dans la tête tout de suite, soit vous êtes parti pour de longues, très longues, très très longues nuits passées à pester, à désassembler, à maudire, à frapper le ST de rage après le 542ème plantage de la journée.
La programmation d'un "hardscroll" ST - qui n'a de hard que le nom, puisqu'il est fait en soft... - est à la fois très compliquée et merveilleusement simple. En fait, elle est tout simplement géniale!! Un bijou ciselé à l'or fin comme on n'en fait plus - comme on n'en a jamais fait! Elle est très simple parce que l'idée de base est supérieurement idiote, tellement bête qu'une fois qu'on a la solution on a besoin de trois jours pour s'en remettre de ne pas y avoir pensé plus tôt. Elle est très compliquée parce qu'elle utilise comme point de départ - et non plus d'arrivée - le fullscreen déjà évoqué! Je n'en ai pas parlé auparavant, mais le code d'un fullscreen est tout simplement le code le plus tordu que je connaisse - et le code tordu est un domaine dans lequel je suis passé maître! Il n'a aucun équivalent sur les machines actuelles, et je doute qu'il en ait jamais un vu la politique de développement de nos jours à l'égard des nouveaux langages et compilateurs. Un fullscreen, c'est unique. ("Un fullscreen dans ma vie, ça suffit" dixit le coder de Level16 qui a réalisé le premier!) Difficile d'en parler sans entrer dans les détails techniques qui ennuieraient le lecteur, mais disons qu'il implique une parfaite synchronisation avec le faisceau d'électrons qui balaie l'écran - c'est-à-dire, lors de l'exécution d'une instruction, qu'il faut savoir précisément quel pixel le faisceau est en train de tracer! - suivi d'un travail d'horloger suisse – au cycle près - sur chaque ligne de l'écran, travail à base de changements de fréquence (50/60 Hz) et de résolution (couleur/monochrome) histoire de tromper le contrôleur vidéo... Un cycle de retard ou de trop dans l'exécution, et tout plante - plantages assez spectaculaires d'ailleurs. D'autre part, le processus initial n'est pas stable, et il faut en plus prévoir de quoi le stabiliser. Enfin, et surtout, il fallait avoir l'idée de faire tout ça. Le fullscreen, je maîtrise. J'en ai codé des dizaines parmi les plus réussis de l'histoire du ST. Et je suis toujours incapable de dire pourquoi ça marche!!!! On peut aussi noter, pour voir à quel point les journaux et les docs peuvent être trompeurs, que dans toutes ces docs, dans tous les manuels, de la "Bible du ST" au "Livre du Développeur" en passant par les autres, il est écrit, noir sur blanc, que le passage en monochrome sur un écran couleur provoque... un reset! Gag: dans un fullscreen, on doit faire un switch monochrome/couleur à chaque ligne de l’écran ! Sans commentaires!
Bref, tout ça pour dire que, partant de cette base assez complexe, Nick, coder principal de chez TCB, corse encore un peu le tout (si!) et jette une bombe dans l'univers tranquille de l'Atari avec son hardscroll, appelé sync-scroll pour ne pas le confondre avec un hardscroll classique.
Apocalyptique!
C'est l'état du cerveau d'un coder moyen après la vue du fullscreen des Cuddly Demos! J'ai beau chercher, je ne trouve pas de mots assez forts pour décrire ce qu'on peut ressentir à ce moment là. Relisez ce qui arrive aux gens à la vue d'un fullscreen classique, multipliez par 10, ça vous donnera toujours l'impression de comprendre!
La légende veut que même l'un des concepteurs de l'Atari en soit resté comme deux ronds de flan, planté stupidement la bouche ouverte devant son écran. C'est dire! Même eux ils ne l'auraient jamais cru!
Accrochez-vous, on passe un cran plus loin: tout ceci se passait en 1989... Les démos de 1995 RI-DI-CU-LI-SAIENT les démos de 1989! Je vous laisse imaginer. Mais on en reparle plus loin.
Pour l'heure, pas question de laisser tomber le petit Nick. Le petit Nick? Oui...car l'histoire n'est pas finie. C'est même ici qu'elle devient fabuleuse et se met à dépasser le cadre d'un simple exploit technique supplémentaire. Autant Steve Bak était un père de famille ayant déjà bien vécu à l'époque de Goldrunner, autant Nick, le héros des héros, l'homme qui avait à ses pieds la quasi-totalité des coders d'Europe....se révéla par la suite n'être qu'un adolescent d'une quinzaine d'années tout timide! Incroyable! Ce gars là, qui n'avait qu'à claquer des doigts pour que tous viennent lui manger dans la main, n'avait dans la vie rien d'un meneur d'hommes - je ne sais pas ce qu'il est devenu, il a peut être changé. Et grâce au code, voilà, qu'en deux jours il devient un Dieu. Que voulez-vous répondre après ça à ceux qui viennent vous voir, ricanant, en affirmant que "les démos ça sert à rien"?!
INUTILES, MES DEMOS?!
Laissons parler "ceux qui savent" - rires! Bien sûr, bien sûr. Ca ne sert à rien puisque ça ne se vend pas, allons!
Comment expliquer alors l'engouement qu'elles suscitent? Osons: je dirais qu'elles présentent le même type d'intérêt - et donc, fatalement, le même type d'incompréhension - que la toile d'un peintre ou que le roman d'un écrivain. Dans les deux cas on y considère la forme - maîtrise des couleurs, maîtrise de la langue, maîtrise du code - et le fond - ce qu'il y a derrière la toile, ce qui est dit dans le roman, parfois entre les lignes, messages encore un peu grossiers mais existants dans les démos. Les démos actuelles sont de moins en moins basées sur la technique - c'était inévitable, nous le verrons plus tard - et de plus en plus sur l'aspect esthétique et visuel de l'ensemble qui doit se marier parfaitement avec les graphismes - qui sont loin des grafitis des débuts! - et la musique - même remarque. Les capacités des micro-ordinateurs augmentant sans cesse, les dessins des graphistes se rapprochent de plus en plus de ce qu'ils peuvent faire sur papier, et les musiques de plus en plus de ce qui peut exister par ailleurs.
L'outil a changé, ce n'est plus un crayon, un pinceau, un synthé ou une basse, c'est tout à la fois, un "multi-outil" cher au concept polluant de multimedia, la forme a changé... mais pas le fond. L'idée reste la même. Et comme, après tout, les artistes ont toujours été des incompris, pourquoi s'étonner du manque de compréhension que subissent les demomakers chaque fois qu'ils essayent d'expliquer ce qu'ils font à des gens qui n'ont jamais et qui ne seront jamais sur la même longueur d'onde qu'eux?
Soyons réalistes. Nous avons déjà évoqué ce comportement un peu étrange des demomakers. Il est clair qu'il y a une réelle difficulté de communication entre eux et le reste du monde. Le test psychologique de Myers-Briggs basé sur les travaux de Jung est bien connu des psychologues américains. Ce test explique ces difficultés en classant les gens en quatre types fondamentaux de personnalité. Ce genre de classement ne signifie rien, bien entendu. Pourtant, en l'appliquant à bon nombre de programmeurs, il est apparu qu'ils appartenaient tous, sans exception, à un même type donné. Ce type ne représente que 20% de la population totale. Et il est accepté le fait que les motivations de ces 20% ci sont strictement incompréhensibles pour les 80% restants. Voilà peut être un début de réponse.
Les CP, notamment, paraissent en général sordides au non-initié. Imaginez un peu... une grande salle de type gymnase ou salle des fêtes, remplie, bourrée à craquer avec des machines, des écrans, des claviers, des disques durs, des disquettes, des multi-prises, un chaos innommable dans lequel les enceintes crachent leurs décibels 24h/24 pendant un, deux, trois jours, parfois plus! Et devant les écrans, des gens. Des zombies qui tapotent les yeux fermés, plus vite que la lumière, doigts précis, gestes mesurés. D'autres parlent à bâtons rompus, se lancent corps et âmes dans des discussions passionnées qui n'en finissent pas. Dormir? Pourquoi faire? Pour une fois qu'ils sont entre eux, pour une fois qu'ils peuvent parler à quelqu'un de sujets qui les passionnent, hors de question! Manger? Un sandwich dans l'urgence, un Coca, et c'est reparti. L'énergie dépensée dans une CP est incroyable! Certaines sont des épreuves de longue durée dans laquelle on se découvre une résistance dont on ne se serait jamais cru capable. Aller au bout de la CP sans dormir, c'est un peu comme aller jusqu'au bout de sa dernière routine... on puise dans des ressources inconnues, on se met à bâtir des théories intéressantes sur le sommeil...La première nuit blanche, ça va. La deuxième est la plus dure, une lutte permanente où on sombre à la moindre inattention. Comme si on pouvait avoir un moment d'inattention dans une CP. Par la suite, on se rend compte que les choses deviennent moins difficiles. Il y a une espèce d'accoutumance qui fait que, même si on travaille en permanence au ralenti, la troisième et la quatrième nuit blanche passent comme des lettres à la poste. Et ainsi de suite pour la théorie! Manger, boire? Pour beaucoup de coders, c'est utilitaire. Manger pour vivre. Pas le contraire. Boire? Pas d'alcool. Sûrement pas. Pas pour un coder. Eventuellement pour un graphiste ou un musicien. Les paradis artificiels et le rock, ça a toujours fait bon ménage. Mais un programme n'a rien d'étrange ou de décalé. Si on veut qu'il tourne, il doit au contraire être issu de l'esprit le plus vif qui soit, issu de la rigueur mathématique la plus froide. Un coder ivre, ça ne marche pas. Beaucoup de coders sont au contraire de grands consommateurs de lait. Ce qui ne manque pas d'attirer des remarques désobligeantes de la part des beaufs de base pour qui l'homme, le vrai, ne consomme que de la tequila dans les raves le samedi. Vous parliez d'incompréhension? De la même manière, le coder n'attache pas beaucoup d'importance à l'apparence. La forme, ça ne compte pas! Seul le fond est important! ...si ils ne dorment pas pendant 3 ou 4 jours, vous croyez qu'ils vont prendre la peine de se laver? Les fins de CP, c'est toujours assez surprenant quand on a jamais vu ça... Ce problème du fond contre la forme est assez classique. En matière de démos, il oppose également les adeptes des démos comme on les concevait à l'origine - seul l'exploit technique, le fond, est important - et les nouveaux venus, qui découvrent généralement les démos sur PC, et qui attachent beaucoup plus d'importance au design, à l'aspect visuel des choses, à la forme. Ils rejoignent un peu, dans ce sens, les gens extérieurs à "la scène".
Une personne extérieure au monde de la démo ne voit que la surface de ce qu'on peut lui présenter. Et encore. Elle ne pourra jamais imaginer tout ce que cela implique derrière, le sync-scrolling de Nick ne lui fera ni chaud ni froid, et pour lui faire comprendre dans quelles proportions ça a changé la vie de son auteur, il faudra se lever tôt!
A tous les détracteurs de la démo, on pourra toujours jeter en pâture quelques exemples bien sentis, bien concrets, à leur niveau:
- ça fait devenir bon en Anglais! La langue de l'informatique c'est l'Anglais. Et comme dans les Coding Party qui se passent en Finlande, au Danemark ou en Allemagne on ne risque pas de choisir le Français comme langue commune de dialogue, y'a pas de mystère: les coders deviennent bons en Anglais! Et d'une!
- ça fait devenir bon en informatique!...argument fallacieux, puisqu'en général les coders commencent par programmer des choses normales avant de passer à la démo. Ils sont donc déjà bons en info quand ils commencent. Disons que ça les fait devenir meilleurs. Voire meilleurs que tout le monde, rappelez-vous Nick. C'est un exemple extrême mais il y en a d'autres tout aussi aptes à déstabiliser le détracteur de base: je connais par exemple des gens qui n'ont même pas encore le niveau Terminale - ils sont en première - et qui programment du Phong plus rapide que celui de 3DS. Bon à savoir: le lissage de Phong est au programme... de dernière année d'école d'ingénieurs! Heureusement les éditeurs ne s'y trompent pas. Quand ils cherchent un programmeur de jeu, ils vont dans les CP. Il n'y a pas de meilleur CV qu'une bonne démo!
- ça entraîne à travailler comme dans le monde réel: en groupe, chacun ayant sa propre tâche, sous pression et avec des délais! - délais imposés par le fait que dans telle Coding Party il y a tel concours de démo et qu'il s'agit de le gagner!
- ça donne une bonne vue d'ensemble du paysage informatique actuel. Ca donne de la marge, un peu de recul, histoire de ne pas accepter sans discuter les stupidités entendues sans arrêt à propos de tout ce qu'on veut nous vendre en matière de programme, accessoire, etc. Je me rappellerai toujours des publicités vantant les mérites du Handy Scanner sur ST: "en 16 niveaux de gris".. N'importe quel coder sait qu'il n'y a que 8 teintes de gris dans toute la gamme de couleurs des STF!! Et de fait, ce scanner utilisait en fait deux fois ces mêmes 8 couleurs....Dommage!
Autre intérêt non négligeable: la volonté et la confiance en soi. Un coder n'en manque pas. De la volonté, il en a en général dès le début. Il faut en avoir pour se lancer dans la programmation en assembleur alors que tout le monde répète que "C'est trop dur", "Tout faire en assembleur c'est impossible" et patati et patata. Bien entendu, ceux qui parlent ne répètent que ce qu'ils ont entendu et ils n'ont jamais vu ne serait-ce qu'une ligne d'assembleur de leur vie. De plus, ils raisonnent en commerciaux. Ils raisonnent en temps qu'utilisateurs dont le but est de créer un programme qui soit opérationnel rapidement, de préférence portable sur d'autres machines facilement, etc. Ils ne leur viendrait jamais à l'esprit qu'on puisse faire de l'assembleur par pur plaisir, sans but particulier, juste pour le plaisir de coder, le plaisir de créer, l'assembleur étant pour eux une torture masochiste insoutenable, pour les coders un moyen - le seul moyen -d'arriver au but recherché: le programme parfait, maîtrisé de A à Z, qui ne gaspille pas un seul cycle, juste pour la beauté du code. Oui, la beauté!
Pourquoi croyez-vous qu'un peintre dessine? Qu'un écrivain prenne sa plume pour griffonner quelques petits brouillons tout de suite détruits? Les artistes sont des incompris. Et je le répète, le demomaker n'est rien de plus, ni rien de moins que l'artiste de l'an 2000. Un peintre, un sculpteur, un écrivain ne vit que parce qu'il crée, peu importe le sujet, l'important est de produire quelque chose. Il ne vit qu'à travers ses créations. Relisez Kant! Où donc étiez-vous lors de vos cours de philo? Lorsqu'il ne produit rien, il se sent inutile. Exaspérant. Désespérant. Pour le coder, c'est pareil, c'est sa manière à lui d'exister, de montrer au monde qu'il est là, de vivre. Et tout l'intérêt de la chose, ce que peu de gens ont compris, c'est que pour la première fois, grâce à ces machines tant décriées par les gens normaux comme des monstres froids vecteurs d'isolement, le coder peut à son tour se sentir utile et important. Peindre? Il faut être un minimum doué en dessin. Ecrire? Idem, il faut savoir manier le verbe, et la virtuosité épistolaire n'est pas la plus répandue, loin de là! Que reste t-il à un coder dont l'esprit structuré est naturellement doué pour les mathématiques et l'abstraction? Pas grand chose pour toucher le grand public, j'en ai peur. La démo, c'est un remède miracle. Un vecteur d'isolement?! Ce sont toujours ceux qui ne savent rien qui parlent... sans sa machine, oh oui, ça oui, je connais plus d'un coder qui serait resté seul dans son univers, incapable de s'adapter aux modes de pensée couramment acceptés comme étant les modèles standard: pas faire de vague, penser comme tout le monde, aimer l'alcool et les grosses voitures, aller hurler au Parc, "s'éclater" en boîte et accessoirement sortir avec n'importe qui de peur de rester seul plus d'une semaine ou, pire, passer pour un plouc. NO WAY!!
Quant à la confiance en soi, elle s'acquiert par la suite, après les premiers succès en matière de code. Les musiciens et les écrivains savent bien que tous les artistes passent par une phase de doute dans laquelle ils se mettent à se poser beaucoup de questions, à s'interroger sur la légitimité de leur démarche, sur l'utilité de leurs créations... Pour le coder, la confiance en soi est déjà présente dès le départ. Souvenir de vieux pirate mégalomane. Par la suite, comment ne pas se sentir fier de son œuvre lorsqu'on reçoit du courrier des quatre coins de l'Europe - il parait qu'on est isolé, c'est ça? - et qu'on voit monter son pseudonyme dans les charts officiels qui sont régulièrement mis à jour?...une illusion, peut être...Chacun comble son vide à sa manière... (Relisez Breillat!) Toujours est-il qu'il vaut mieux partir trop confiant plutôt que pas assez. Vous pouvez toujours répondre qu'une démo sert à se sentir bien. Vous n'imaginez pas le bien fou que ça peut procurer lorsqu'une centaine de personnes se lèvent de leurs chaises pour vous applaudir après la projection sur écran géant de votre démo... Inoubliable! C'est une récompense qui justifie à elle seule tous les sacrifices effectués, toutes les nuits passées à débugguer son code, tout. C'est à ce moment là que tous les doutes s'envolent, et que le coder se dit que, oui, décidément, ça en valait la peine!
NO FUTURE
Malgré tout, le temps des démos est révolu. Pas forcément pour le graphiste, ou pour le musicien, qui pourront toujours s'exprimer, avec de plus en plus d'outils, de plus en plus performants, quoi qu'il arrive. Mais la situation est plus délicate pour le coder. On l'a vu... le coder ne jure que par l'assembleur. C'est le seul langage "moralement satisfaisant". Tous ces problèmes de portabilité, de vitesse de développement, le coder n'en a cure! Ce sont des problèmes de commerciaux. Le coder, lui, veut quelque chose de beau, on l'a dit! Quelque chose de parfait. Son code, c'est sa création, son fils, sa vie, une partie de lui même - Kant, Kant, relisez Kant! Il est hors de question de ne pas donner le meilleur de lui même à sa création, hors de question de faire confiance à un compilateur crétin totalement dénué de la moindre souplesse. C'est une traîtrise parfaite de tous les fondements de la démo. Toute la partie "exploit technique" part en fumée, les compilateurs du futur tendant au contraire à guider au maximum le programmeur, à lui simplifier au maximum la tâche pour qu'il ait le moins de travail possible à fournir. Strictement aucun intérêt pour le coder. Ce genre de soft ne s'adresse qu'à des gens normaux. Flemmards. Pas à des gens qui ont passé trois jours sur une boucle de calcul pour y gagner quatre malheureux cycles. Pas à des chercheurs en herbe dont le seul but dans la vie a été, à une époque, de percer le secret du Sync-Scrolling. Les compilateurs futurs, tournant sur des environnements multi-utilisateurs et établissant des protections, des barrières, des interdictions à tous les niveaux, ne permettront jamais le développement de ce genre de bidouille un peu tordue, un peu géniale. Il n'y a pas de place dans le futur pour les coders. C'est aussi simple que ça.
Fini les exploits techniques! J'ai signalé un peu plus haut que les démos de 1995 sur ST ridiculisaient celles de 1989. C'est évident. Le ST est né en 1985, soit DIX ANS avant! 10 ans! C'est énorme en informatique, jamais vu! Et en dix années les gens ont eu le temps de développer, d'apprendre, de maîtriser la bête, de lui faire cracher ses derniers bits, de la pousser dans ses derniers retranchements... Les dernières démos sur ST atteignaient un degré de technicité hors de portée de tous les Nick du monde. Tout était maîtrisé jusque dans les moindres petits détails, tout était contrôlé, le moindre cycle machine avait été traqué et utilisé, synchronisé, fignolé, des merveilles! Il n'y a pas de comparaison possible avec les démos actuelles. Comment? Comment arriver à maîtriser un processeur de nos jours? Il y en a un nouveau chaque année. Alors on apprend. Oh, oui, toujours! Et on codouille. Mais il reste toujours un domaine inexploré, une interruption vierge, une instruction méconnue...rien à voir, rien à voir avec l'hallucinante précision des connaissances des coders ST sur la fin de la vie de cette machine. On a vu, d'ailleurs, plus d'une fois, des programmes ST (8 Mhz!) ridiculiser en vitesse des programmes équivalents tournant sur des 486DX33. La structure du PC n'y est pas pour rien. L'assembleur non plus. Mais la nullité des programmeurs non plus!
Le commerce, l'argent est venu mettre un terme à ce joli rêve. Dans les CP où l'on gagnait un trophée symbolique, on gagne maintenant un Pentium et 5000 dollars. En toute hypocrisie d'ailleurs, étant donné la "qualité" des codes mis en jeu.
Et les gens ne savent pas. Les nouveaux venus ne peuvent pas savoir. Ils ne sauront sans doute jamais. On oubliera tous ces noms de légende...Nick, The CareBears...The Lost Boys..Mad Max..The Exceptions...Overlanders...qui s'en souvient?
....Future Crew?!....pauvres de nous.
Zappy/SCOOPEX
