Par Zappy/BomB
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:
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 *8) )
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
exlusivement à la création de ces petites intros si prisées
par les utilisateurs. Ceci appelle quelques explications :
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éte
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 renomé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 oeuvres 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 boût 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 moëlle, ronge les os, et ne l'abandonne qu'une fois
que, du statut d'idée, elle est passé à 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é,
pen- dant 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 entrefaits, 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.
Une démo.
LA démo, plutôt.
La "Cuddly Demo", déjà mentionnée ici.
Origine: Suède.
Groupe: The Carebears (TCB)
Signe particulier: plus grand groupe de tous les temps.
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'idôle 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 côte 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é 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 ennuiraient 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 video... 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 A
CHAQUE LIGNE DE L'ECRAN! 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 reparlera
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 assez 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 en- tendu. 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 boût 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
syncscrolling 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 :
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
CREER, 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 griffoner 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! Ou 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é
epistolaire 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 standards : 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 oeuvre 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/Bomb