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:
...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 :
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 :
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.