Interview : l'équipe de Batman Forever

— Initialement publié sur Push'n'Pop, par Hicks, le 15 Avril 2011. Traduit de l'anglais par Roudoudou.

Salut à toute l'équipe de Batman Forever, je veux dire Rhino, Arnoldemu, Factor6, Yzi, Dadman, Mac et Paulbrk! Tout d'abord je pense qu'il serait intéressant de vous présenter vous même en expliquant qui vous êtes, quand vous avez commencé le CPC et ce que vous avez déjà fait dessus?

Yzi: Salut, je suis Yzi, coder et musicien du groupe Fit and Lieves!Tuore. Avant Batman Forever, je n'avais rien fait pour le CPC. J'étais en relation avec les autres via le forum MSX.org où Paulbrk cherchait un musicien qui utilisait Arkos Tracker. Je venais tout juste de basculer de mon système de musique archaique vers le super Tracker de Targhan. Avant je devais éditer les morceaux en texte, directement dans le code source assembleur. Mon vieux système était un peu plus compact et offrait plus de liberté, par exemple attribuer une vitesse de déroulement différente à chacune des pistes, mais composer des musiques était super long car je devais recompiler à chaque fois pour tester la modification. Avec l'Arkos Tracker j'ai créé plus de musiques en un an qu'en treize ans avec mon système.

Factor6: Salut, moi être humain de la Terre :) Mon nom est Alan Petrik et j'habite en République Tchèque, qui est un petit pays à l'est de l'Allemagne. Tout d'abord je dois dire que je ne suis pas à 100% CPC -Ma plateforme de cœur est le ZX Spectrum et je fais aussi des petites choses pour d'autres 8-bits comme l'Atari 8-bits, le C64, Sharp MZ, PMD-85, ZX81, CPC, etc. Mon premier travail sur CPC était quelques dessins pour Optimus, AFAIK. Je me rappelle d'autres dessins et d'essais musicaux à la Forever Party. J'ai aussi dessiné et fait une musique pour la CPCtro de Zeroteam. Après sa diffusion, la scène CPC a découvert une nouvelle “source de musique” :) et on me demanda alors de faire la musique de Plasmorphy et Batman Forever. La musique de Plasmorphy fût réalisée sur ZX, mais c'est difficile de convertir sur CPC à cause de la différence de fréquence entre leurs AY respectifs. C'était pénible de faire quelque chose d'écoutable sur le CPC. Du coup, j'ai décidé de faire la suivante, celle de Batman Forever, sur l'Arkos Tracker qui est un des trackers les plus confortables que j'ai utilisés. C'est vraiment un plaisir de bosser sur le CPC, en comparaison du C64 qui a d'exécrables éditeurs de musique.

Mac: Salut, mon nom est Marco, je suis le frère de Rhino et un membre de Batman Group depuis le début, quand on se concentrait sur l'Amiga. Je connais le CPC depuis 1987, quand mon père l'a acheté et c'était pour moi, simplement, un ordinateur pour jouer et bricoler en Basic. Mais honnêtement, j'ai toujours aimé le Spectrum. Batman Forever est ma première contribution à la scène CPC.

Paulbrk: Je suis artiste pro, vous pouvez jeter un œil à Mobygames “Antonio Galvez Alcazar”. Depuis mon plus jeune âge, je suis impressionné par tout ce qu'un ordinateur peut faire. J'ai grandi avec les 8, 16 et systèmes 32 bits. J'aime toutes les machines, chacune a ses avantages et ses inconvénients. Depuis 2005 je m'intéresse à la scène rétro, en particulier les machines 8 et 16 bits.

DaDMaN: Heu, mes surnoms sont DaDMan et DaDoS et mon introduction officielle à la scène CPC fût en 2005 avec un remake pour PC de Street fighter II qui utilisait des sons et graphismes à la sauce CPC. Ce furent les premiers graphismes que j'ai converti pour CPC après une grosse période d'inactivité depuis 1992. Grâce au projet Street fighter II CPC Edition, j'ai rejoint le groupe de programmeurs ESP pour qui j'ai fait la jaquette du jeu Panthom Saga Infinity et j'ai collaboré aux GFX. J'ai aussi participé à Mariano the dragon, iLogicAll, Smart Games for Smart Minds, Paciente 106 et la réédition de Columns pour CPC.

Peu après j'ai rejoint le groupe CEZ Games Studio où j'ai fait tous les graphismes de BETILED! pour CPC, collaboré à la version MSX, participé aux jaquettes de Aqua et Nanako: The Japanese Monster Castle et le menu de la compilation CEZ Collection Vol 1 pour CPC (GFX+code).

En ce moment, je fais partie du groupe de programmeurs RetroWorks (mais nous n'avons rien fait pour le CPC) et du groupe RetroFactory, avec Syx et moi, et sous ce label, nous avons programmé les versions CPC de UWOL: Quest for Money, King's Valley I & II.

Je suis l'auteur du blog: www.ladrillopixeles.blogspot.com où j'essaie de commenter l'actualité rétro d'un point de vue précis et technique.

Concernant le matériel, j'ai plusieurs projets sur le feu mais le plus connu est le VDRIVE Host USB pour CPC. Il y a plusieurs vidéos youtube à ce sujet.

Arnoldemu: Salut, mon nom est Kevin Thacker et je viens du Royaume Uni. J'ai un 6128 depuis 1986 et je suis actif dans le monde CPC avec mon émulateur Arnold et mon site web www.cpctech.org.uk J'ai aussi sorti quelques previews comme la démo 4096 couleurs. Il y a longtemps, j'ai aussi sorti des music-disks de conversion Atari ST. Plus récemment je me concentre sur des jeux et j'aide les autres quand je le peux. Le système de chargement musical était quelque chose que j'ai toujours voulu faire.

Rhino: Salut, mon nom est Alejandro et je suis de Séville en Espagne. Concernant la scène démo, j'étais programmeur sur Amiga de 1992 à 1995. Ensuite j'ai été inactif jusqu'à aujourd'hui. À propos du CPC, j'avais fait quelques routines Basic et assembleur quand j'étais enfant donc on peut dire que Batman Forever est ma première production CPC.

Est-ce que les réactions à votre démo correspondent à ce que vous vous attendiez? Vous avez mis quelques blagues à propos de la scène CPC et C64 mais derrière ces blagues, que pensez-vous vraiment de ces deux scènes? Qu'est-ce que vous prévoyez quand Booze Design et Vanity répondent à vos attaques? :)

Factor6: Oui, c'est exactement ce que j'attendais :) À propos des attaques, je pense que ce n'est pas mauvais de le faire avec parcimonie. Bien sûr, quand j'ai vu la beta de la démo, mon premier sentiment était que ça avait quelque chose de mauvais mais en y repensant un peu plus, je n'ai pas obligé Rhino à les enlever. Je n'ai rien contre le C64, j'aime l'ordinateur (c'est ma seconde machine après le Speccy) et sa scène. Je pense que Booze Design pourrait répondre à ces attaques parce que c'est le C64 qui avait commencé dans les années 80, contre l'Atari. Donc c'est plutôt une tradition gentille du C64 en référence à cette époque. Booze fait des démos fantastiques alors si il y avait mention du Batman Group ou de la Batman Forever, ça ne serait pas une surprise pour moi. Mais la plus grosse surprise serait si Vanity ou quelqu'un d'autre qui fait des démos qui déchirent sur CPC. Parce que le CPC a simplement besoin de plus de démos et BF montre clairement que le potentiel démo de la machine est plus grand qu'on ne le pense.

Mac: Je savais que BF serait très bien reçue parce que c'est un travail attentionné sur tous les aspects mais je pense que l'accueil a été meilleur que ce à quoi je m'attendais. Pour les vannes à propos de Booze, Vanity ou le C64, je trouve marrant ce style vain et arrogant et je suis ravi que ça n'ait pas été mal interprété. Je me rappelle que la scène des années 90 était toujours comme ça. La vanité n'est pas un défaut si c'est accompagné par le talent et l'humour.

Je connais peu de choses de la scène rétro mais il me semble que la scène C64 est aussi grande que le fût la scène Amiga.

Paulbrk: Je pense seulement à faire bouger les gens, pour maintenir la scène en vie et que ça s'améliore chaque année. Content que personne n'ai été énervé par ces commentaires. Restez positif.

DaDMaN: La chose la plus importante c'est de parler, en bien ou en mal. Quand on parle de quelque chose ou de quelqu'un, c'est qu'il n'y a pas d'indifférence. Je suis très fier d'avoir participé à cette démo, d'avoir bousculé le socle des anciens et contribué à changer certaines attitudes.

Arnoldemu: Quand j'ai vu les premières previews de Rhino j'étais soufflé. La version finale est grande et c'est toujours un plaisir de la regarder encore et encore. Je savais que le résultat serait une tempête dans la scène Amstrad. Je savais qu'il y aurait des réactions positives et négatives aussi. Je crois que certains voudront critiquer négativement le projet pour des raisons personnelles. J'étais particulièrement intéressé par la réaction de la scène C64. La scène C64 est énorme, ils sont actifs et produisent d'intéressantes et bonnes productions. Dans le passé j'ai eu un C64 et regardé beaucoup de démos dont j'appréciais le design et le travail qu'il y avait dedans et je pense que cette démo est proche du sentiment que j'avais en les regardant. Alors c'était intéressant de voir la première réponse (une version C64 du batlogo en rotozoom). Je pense que nous avons beaucoup à apprendre d'eux car nous aussi nous pouvons faire des productions de qualité en plus grand nombre. Je ne me suis jamais considéré comme faisant partie de la scène CPC. J'ai regardé des démos depuis 1989 et j'ai vu beaucoup de belles et impressionnantes démos mais plus récemment, j'ai eu le sentiment qu'il fallait faire partie d'un gang pour être accepté. Je pense que c'est dommageable, que nous devons encourager les anciens et les nouveaux et j'espère que ça arrivera. J'espère une réponse de Vanity et Booze et j'attends ça de pied ferme. Ça sera amusant à regarder et apprendre. Est-ce que le résultat aura la même saveur que notre production?

Rhino: Absolument pas, Batman Vuelve a eu seulement 80 thumbs up on Pouet quand BF est sortie (80 au bout de 10 ans)et je pense que c'était un succès! Aujourd'hui, BF en a 280. Je ne pensais pas du tout qu'une démo CPC aurait un tel accueil et je suis content de ça :)

À propos de la scène C64, je pense qu'ils ont la meilleure rétro-scène. Ils ont plein de groupes actifs, de gens et c'est la clef pour avoir plein de productions de qualité. Mais les resources humaines ne sont pas la seule chose qui permettent le demomaking. Les capacités de la machine sont aussi importantes!

La scène CPC est petite mais je pense qu'elle va grandir à nouveau. Sa plus grande attractivité est à mon sens qu'il y a beaucoup de nouvelles choses à y faire. Et le CPC est le meilleur ordinateur 8-bits pour moi. À propos des gens, c'est comme partout, il y a de tout. J'ai trouvé des gens super sympas et des petits détails que je n'aime pas, comme la controverse après la sortie de Phreaks.

Les attaques? Héhé, ben si je me rappelle bien, le zoomscroll de Booze disait quelque chose comme “Beat this!”. Son zoomscroll a seulement 3 couleurs et est tout petit, je pense que j'ai juste fait ce qu'ils ont demandé :) Et j'ai pensé que “regarde et apprends” serait une bonne méthode pour vous non? :) Plus sérieusement, je pense qu'une compétition saine et les défis sont de bonnes choses pour progresser et se motiver. Alors si vous vous attaquez à l'élite, c'est un acte de valeur. Attaquer le faible est lâche. Bien sûr, Booze et Vanity seront défiés à nouveau si ils osent attaquer le chevalier noir, héhé.

Batman Forever est bien sûr, très impressionnante visuellement, comme l'utilisation fûtée des animations et rasters mais quelques personnes ont été frustrées du manque de technique. Qu'avez-vous à répondre à ça? Donnez-vous de l'importance au temps réel ou à la compacité d'une démo?

Rhino: Le manque d'approche technique? Heu, je pense que ceux qui disent ça devraient expliquer pourquoi… Je dois dire que je n'aime pas les jugements techniques à propos des démos et encore moins à propos de mon travail. Mais pour une fois que le CPC a une démo que la scène C64 envie, je pense que ce n'est pas intelligent du tout pour un amoureux du CPC de répendre de fausses rumeurs ou de dénigrer le travail. Donc je vais donner quelques éclaircissement à propos du niveau technique de BF.

Tout d'abord, j'aimerai bien savoir ce que tu entends par animations? Je pense que le terme est inapproprié. L'animation est un concept général et par essence imprécis. Une animation, par définition est une séquence d'images qui donnent la sensation de mouvement et de ce point de vue, toutes les démos sont des animations après tout, parce qu'il n'y a pas d'interaction. En ce sens, si vous dites que votre partie favorite de la démo sont les animations, peut-être que quelques personnes savent de quoi vous parlez mais si vous dites par exemples, les dots, le zoom, les objets 3D, tout le monde saura de quoi vous parlez.

Ceci étant dit, la discussion technique portait sur comment chaque image de la démo est générée. Et je pense qu'on ne sera pas très précis, encore une fois, si nous faisons de la classification manichéenne à propos de temps-réel ou précalculé, parce que du moment où on utilise une table de sinus, on utilise des données pré-calculées. On peut dire que tous les effets d'une démo ont un certain nombre de données pré-calculées, qui sont utilisées en temps réel pour générer chaque image d'animation qui compose la démo. Pour être précis, techniquement, on devrait parler en proportion de précalculs vs temps réel et évaluer tous les aspects (qualité visuelle, vitesse, technique, originalité, innovation, …) ce qui serait un bien difficile et subjectif exercice. Donc je n'essaie pas de changer les avis de chacun, mais si un puriste qui n'aime que le temps réel peut enlever tous les effets avec beaucoup de pré-calculs et conserver une démo longue…

Bien sûr, je désapprouve ceux qui disent que BF manque d'approche technique et je vais expliquer pourquoi. Tout d'abord, une trackmo est, techniquement, un concept supérieur à une démo à chargement unique car vous n'exploitez pas toutes les capacités matérielles de la machine en faisant un chargement unique (le lecteur de disquette). Et en conséquence vous avez une sévère restriction mémoire qui affecte la qualité visuelle et la longueur de la démo, avec évidemment à la clef, une production moins bonne.

Un autre détail à garder en mémoire à propos du niveau technique peut-être la compatibilité, les bugs… J'aurais aimé être plus attentionné à propos des temps de chargement et alors que je n'avais observé aucun problème avec mes disquettes, j'ai reçu des commentaires de gens qui avaient des soucis de synchronisation après un petit chargement. De plus, BF tourne sur tous les CRTC (sauf le CRTC 2) et conserve le 50Hz tout le temps, malgré l'usage continu de techniques CRTC, ce qui permet de la regarder sur n'importe quel projecteur, télévision ou moniteur sans problème.

À propos de la taille, elle est logiquement liée à la durée, le nombre d'effets, les graphismes, les musiques, la bande son. BF dure 11 minutes et utilise 3 faces, ce qui correspond à peu près à 4 minutes de démo par face, considérant la quantité de graphismes, musiques, samples, effets, je pense que c'est une taille appropriée pour ça.

Je pense aussi dans le cadre d'une analyse et évaluation technique, qu'il serait honnête de considérer l'innovation et la capacité à faire des choses difficiles de façon facile. Par exemple, les rasters. C'est correct de dire que l'elastic zoom est en temps réel parce que la déformation X et Y est calculée à chaque image sans précalcul (d'ailleurs il n'est pas appelé zoom élastique en temps réel dans les crédits) et qu'il utilise le CRTC plus des rasters sur tout l'écran à 50Hz. Je pense que les rasters sont un effet courant sur CPC mais pourquoi personne n'avait jamais fait un zoomer comme celui-ci avant? La même chose peut s'appliquer à ce que vous appelez animations. Chacun sait comment programmer une animation. Si quelqu'un sait techniquement comment la faire à 50 images par seconde et en plein écran, pourquoi personne ne l'a fait? Est-ce que quelqu'un a calculé combien de mémoire serait nécessaire pour stocker plus de 800 images d'objets complexes en 3D sans perte de qualité, en haute résolution, plein de couleurs et sur la totalité de l'écran? Si c'était simplement une animation non compressée cela prendrait plus de 20Mo! Et combien de MHz sont nécessaires pour afficher à 50 images par seconde une animation? Je crois que récemment certaines personnes ont essayé de refaire mon bat-logo 3D sur C64 en utilisant des techniques optimisées de compression. Sans succès. Peut-être qu'il y a autre chose que des rasters et une simple animation avec un peu de technique après tout. La vérité c'est que j'ai utilisé des techniques innovantes pour exploiter simultanément le Z80, le CRTC et le gate array pour faire un effet d'une taille à une vitesse jamais vue sur CPC, en combinant des algorithmes logiciels optimisés mélangés à des techniques matérielles pour augmenter les performances. Si quelqu'un pense qu'il y a un manque d'approche technique, je respecte son opinion et le félicite d'être quelqu'un de plus exigeant que moi, mais je ne suis pas d'accord. Et bien sûr, pour dire que From Scratch est techniquement supérieur à BF, comme Longshot dit, n'est pas acceptable d'un point de vue objectif.

J'ai aussi lu que Longshot disait que mon rotozoom était une animation compressée et je dois dire que ce n'est pas vrai. Si quelqu'un veut savoir comment un effet est fait, demandez moi, s'il vous plait. Je veux que la scène CPC grandisse et ça sera toujours meilleur que répandre des conneries ou dénigrer le travail. Je fais un zoom temps réel et une rotation de 1450 pixels par image, à partir d'une rotation précalculée de seulement 3 vecteurs qui représentent la fenêtre du rotozoom (algo typique de rotozoom). Vous pouvez noter le ratio faible entre le précalculé/temps-réel et la raison de ce précalcul est que précalculer une table de sinus aurait une taille similaire. De toutes façons, la théorie de l'animation ne tient pas la route, le rotozoom dure 20 secondes et n'a pas de répétition donc ce sont 1000 images uniques à 50 images par seconde. La résolution réelle est 50×29 pixels donc chaque image fait 1450 pixels en 16 couleurs ce qui fait 725.000 octets de graphismes complexes. Même avec un ratio de compression de 2/10 on serait encore à 145.000 octets. D'un autre côté, si il y avait une animation vidéo, je n'aurais pas simulé un simple rotozoom, j'aurais mis une scène complexe en ray-tracing ou quelque chose dans le genre. Mais je pense que dire qu'à peu près toute la démo est une vidéo :) C'est marrant! Je suis très surpris de ce que certaines personnes pensent des capacités de stockage d'une disquette 3 pouces et de mes compétences en compression de données :) Plus sérieusement, je ne connais pas Longshot mais je pense qu'il fût un codeur connu sur CPC et j'aimerai penser que ce qu'il dit est plus dû à de l'ignorance que pour discréditer mon travail. De toutes façons ça serait bien qu'il arrête de l'ouvrir sur ce qu'il ne connait pas.

Mais plus important que les discussions techniques et explications théoriques, le ressenti et l'impact d'une démo sur le public. Est-ce que quelqu'un trouve raisonnable de demander à Juan Maria Arzak d'écrire trois pages d'arguments techniques pour nous convaincre de pourquoi nous devrions aimer la cuisine de son restaurant? C'est ce qui arrive souvent dans les discussions techniques où certains veulent nous apprendre ce qui est important, comment on doit faire et nous faire des reproches si on ose douter de leurs critères. Je pense qu'une démo, si elle ne produit pas d'impact ou de ressenti, n'est pas de l'art. Mais plus que des théories pour justifier la qualité d'une démo, elle devrait le faire d'elle même.

Bien sûr, la capacité d'une démo à impressionner décroit grandement quand les effets ne sont pas nouveaux, donc j'espère que vous n'allez pas copier les techniques de BF dans votre prochaine démo pour impressionner le public à nouveau, héhé (blague) :)

Il semblerait que vous avez essayé d'attirer l'attention sur le CPC avec votre démo, par exemple, en exagérant certaines informations (seulement 6% des capacités du CPC exploitées par les logiciels commerciaux), ou multiplié par 4 ou 6 le nombre réel de dots affichées à l'écran. Quel était votre but en faisant ça? Donner le message “tout est possible” sur CPC aux autres scènes?

Rhino: Tu as raison, je pense que beaucoup de gens ont remarqué que mon but était d'attirer l'attention sur les capacités du CPC, en particulier pour impressionner la scène C64. Le choix des effets était conditionné par l'idée de montrer que le CPC est meilleur que le C64 sur à peu près tous les plans. Par exemple, color (partie en 703 couleurs), résolution et mode texte en 192×54, puissance brute (zoomers, objets 3D, dots…)

Bien sûr, le texte de la phrase que tu mentionnes n'est pas la première version. Dans l'original, la fin dit “ce que vous allez voir est seulement 17%…” :) À propos d'exagération, et bien, j'ai utilisé chaque astuce pour donner l'impression que ce sont des choses impossibles à faire pour un 8-bits. Multiplier par 4 ou 6 le nombre de dots est aussi une astuce pour donner un meilleur rendu visuel. Après tout, si vous avez vu des objets 3D tourner sur tous les axes en plein écran à 50 images par seconde, pourquoi 4000, 6000 ou 60.000 dots ne serait pas possible sur CPC? Mon opinion est que le demomaking est de rendre possible ce qui est impossible. Créer des illusions. Comme j'ai dit dans ma réponse précédente, je pense que donner ce sentiment au public est plus transcendant que battre un record mathématique.

Arnold, tu es l'auteur du chargement musical. Peux-tu nous donner des détails techniques à propos de ton travail? Taux de transfert, gestion d'erreur, etc. Qu'est-ce que tu penses des précédents chargements musicaux sur CPC? Tu parlais de diffuser ton code source, quand prévois-tu de le faire?

Arnoldemu: Créer un chargement musical n'est pas facile. J'ai créé et fait beaucoup de tests sur le contrôleur de disque avec différentes configurations de lecteurs. Rhino m'a bien aidé pour les tests. Ma conclusion est de ne pas se fier aux timing précis, en particulier avec les disquettes 3 pouces.

Le chargement utilise un format Amsdos standard avec 9 secteurs par piste, 512 octets par secteur, à part que les secteurs ne sont pas entrelacés et la GAP est différente.

Les secteurs sont réglés pour que dans des conditions idéales et avec une rotation parfaite, le transfert d'un secteur prenne moins de 1/50s sans erreur. En réalité ça n'arrive pas souvent, surtout avec les disquettes 3 pouces donc j'ai besoin de gérer les erreurs et les retries. La seule partie du chargement qui a besoin de timings précis est la lecture des données du secteur. Tout le reste peut-être fait avec les interruptions activées sans que le FDC ne renvoie d'erreur. Le chargement recommence si il y a une erreur. La plupart du temps il s'agit de rendre compte d'un dépassement de capacité du contrôleur mais il recommencera à lire pour n'importe quelle erreur. La musique est jouée entre le lancement de la commande de lecture au FDC et avant que les données soient lues. Il y a suffisament de temps pour jouer une musique AYC. Avec l'Arkos Player ça devrait être possible aussi mais ça serait juste et il y aurait plus d'erreurs.

Je n'ai pas d'informations à propos du taux de transfert mais je donnerai le détail quand je publierai les sources.

À propos des autres chargements, j'ai une grande admiration et j'apprécie le travail de programmation des chargements musicaux sur Amstrad. Ce n'est pas facile et chacun est bien réalisé. Bien sûr, j'ai jeté un œil à leur code et analysé ce qu'ils faisaient mais autant regarder dans leur code peut aider, autant ça n'aide pas à comprendre le pourquoi et le comment.

Le premier chargement musical que j'ai vu était dans The Demo. Très impressionnant à l'époque mais lent. Plus récemment, ils ont été de mieux en mieux. Je pense que mon chargement musical n'est pas tellement différent des autres. L'astuce c'est ce que Rhino en a fait pour la démo. Si ce chargement musical avait été utilisé pour une autre démo, ça n'aurait probablement pas été si impressionnant.

Oui, je vais publier le code source, mais pas avant quelques mois à cause de projets que j'ai à terminer dont une démo musicale. Ensuite je sortirai le code et les outils avec toutes les informations que j'ai trouvées à propos du FDC et des autres chargements musicaux.

Une question à l'équipe des graphistes. Pouvez-vous expliquer quel fût votre rôle et comment avez-vous procédé pour faire votre travail? Il semble qu'il y ait beaucoup de transferts de GFX, pourquoi n'avez-vous pas créé vos écrans de zéro? À votre avis, existe-t'il une différence entre un transfert retouché et une création originale?

Mac: J'ai quitté la scène démo après la sortie de Batman Vuelve sur Amiga en 1995. Et là, je n'avais pas grand intérêt à faire partie du retour du chevalier noir sur CPC. BF a été orchestrée un peu uniquement par Rhino, qui avait déjà contacté d'autres graphistes (Eldrik, Paulbrkn Dadman), et il en a même fait quelques uns lui même. Ce qui s'est passé, c'est qu'en voyant la démo avancer, je n'ai pas pu résister à y participer. J'aime bien faire des dessins sur 8-bits parce que la technique minimaliste met en relief les choses importantes, je veux dire par là, la patte propre à chaque graphiste ressort bien. C'est comme les échecs ou le billard. Les règles sont simples, tout le monde les connait alors on essaie juste de bien faire les choses. À propos des outils, je ne suis pas puriste donc je dois admettre que j'ai utilisé Photoshop pour travailler car c'est plus confortable qu'Art Studio pour moi.

Mais à la seconde question, je dois répondre par une question: Comment tu sais que les dessins sont des versions retouchées? XD Honnêtement c'est difficile de savoir si un dessins est basé sur une version transférée ou faite de zéro. Je pense qu'il y a un cliché à propos des graphistes qui est d'identifier certaines trames dans des dessins faits de zéros qu'on retrouve moins dans les conversions. Pourtant ce n'est pas tout le temps vrai. Parfois j'ai entendu que j'utilisais un peu d'anti-aliasing par exemple mais certaines astuces doivent être utilisées avec discrétion et parfois ce n'est pas nécessaire. Pour moi la technique du pixel n'est pas importante et je pense que ça ne doit pas prévaloir sur l'aspect général, les formes bien définies, l'atmosphère, etc. N'importe qui peut apprendre la technique. Être un bon graphiste est une autre paire de manches.

Donc, en effet, certains dessins sont des retouches de conversions, mais c'est simplement un gain de temps. Comme je l'ai dit, j'ai commencé à travailler sur BF sur le tard et je m'y attelais occasionnellement. Pas comme pour Batman Vuelve par exemple, où mon enthousiasme pour les démos était plus grand et où je faisais à peu près tout de zéro.

En résumé, si on parle d'un certain niveau de qualité, ce n'est pas la différence entre une conversion et un dessin fait de zéro mais faire quelque chose de 100% original ou basé sur le travail de personne d'autre que soi.

Paulbrk: J'aime faire des dessins de zéro mais cette fois, Rhino voulait quelque chose de spécifique à partir d'un original trouvé sur le net. J'ai converti l'image mais il y eu énormément de travail pour le rendu final. C'était pour l'image en mode 1 avec le changement de couleurs en rasters. Ce n'est possible qu'avec un travail manuel. Sur cette image finale on devait faire une animation mais on a dû arrêter et s'en servir uniquement comme image fixe parce que nous n'avions plus de place. Mélanger le 6128 avec le logo Batman pour faire un Amstrad Begins était mon idée.

DaDMaN: Ma contribution a été l'écran qui montre le Joker et Batman en plein combat. Dans mon cas, j'aimerai expliquer pourquoi j'ai utilisé une conversion au lieu d'une création originale. J'ai été le dernier à participer, et à la dernière minute. Une jour, Rhino me contacte via mon blog pour me demander un GFX pour sa démo en tant que contribution. La démo était quasi bouclée et elle devait être prête pour la Forever C 2011, donc on n'avait pas de temps. D'un autre côté, je suis un homme occupé :) et une conversion est plus rapide qu'une création. Dans tous les cas, j'avais perdu assez de temps avec ma contribution car le premier écran que j'avais fait était finalement remplacé par le combat Joker vs Batman.

Ma méthode de travail est simple. J'utilise Microsoft Pain pour Windows, rien de plus, aussi simple que ça.

Un des meilleur aspects de la démo est la grande synchronisation entre le visuel et la musique. Comment avez-vous travaillé ensemble sur ce point? Qui a créé les samples? Que dire à propos du player de musique, qui semble être une version stabilisée de l'AYC de Madram?

Yzi: Je n'ai fait que la musique du prologue et de l'introduction, mais rien que cete partie contient beaucoup de points de synchronisation. Quand j'ai commencé à travailler, Rhino avait quasiment terminé le visuel d'intro donc tout ce que j'ai eu à faire était de synchroniser la musique sur la démo. Il y a eu très peu d'ajustements à la démo pour faire que les transitions soient synchronisées au bon tempo, donc j'ai pu conserver la mélodie telle quelle. Rhino a fait les effets sonores digitalisés. Mais j'ai du refaire toute la musique d'introduction parce que ma première idée était trop bourrine pour coller à l'ensemble et les samples ne ressortaient pas bien. J'avais seulement vu la partie d'intro donc je n'avais pas une bonne perception de l'ensemble et maintenant que je vois à quoi ressemble la démo terminée, je suis bien content d'avoir giclé la première version.

À propos du player AYC, il a été utilisé plutôt que la routine du Arkos Tracker parce que Rhino pouvait utiliser le player AYC avec un temps constant et un usage CPU très réduit tout en intercalant à la demande la lecture PCM des samples. D'un point de vue musical, j'aurais préféré utiliser la routine d'Arkos parce qu'on aurait pu conserver une complexité musicale sans se soucier de la mémoire. J'ai dû simplifier mes effets et gruger pas mal pour que le flux AY se compresse suffisament avec la taille qui m'était allouée pour l'AYC. C'est un peu comme le bitmap rapport au dessin vectoriel. Les dessins sont faciles à rendre pour un CPU mais la limitation mémoire est stricte alors que les vecteurs donnent une plus grande liberté artistique. La routine d'Arkos peut, par exemple, jouer les notes d'une portée avec différentes transpositions, donc vous pouvez à partir d'une ligne de basse/batterie dédoubler virtuellement la piste sans que cela augmente la taille du morceau. Mais avec l'AYC, si ça sonne différent, les données ne vont pas se compresser. J'ai passé un temps fou sur la musique à tatonner pour trouver la meilleure façon de compresser au maximum l'AYC. D'ailleurs, je ne trouve pas que le fichier AYC final du prologue de 2679 octets soit super impressionnant pour un petit morceau tout simple de 90s. Longtemps, j'ai cherché plein de façons de gratter des octets par ci et par là mais au final, j'ai surtout renoncé et supprimé toutes les variations pour avoir la même séquence encore et encore et là, ça commençait à compresser suffisament. C'est dur pour un musicien parce qu'on souhaite toujours avoir le plus de variations possibles pour rendre le son intéressant et moins mécanique. Mais bon, ça n'a pas d'importance puisque personne n'avait l'original pour comparer et c'est au final un rouage essentiel de la magie de la démo de faire quelque chose qui semble impossible. Les auditeurs ne sont pas supposés connaitre les restrictions et les contraintes qui sont derrière tout ça.

Factor6: Je ne sais pas qui a fait les samples, je n'ai fait que la musique principale. Quand je l'ai envyée à Rhino, je pensais que mon boulot était terminé mais il m'a obligé à raccourcir/rallonger certaines parties pour rendre la musique plus attractive et le plus dur dans tout ça fût la synchronisation. Il a fait en sorte ensuite de caler la démo sur la musique. J'ai toujours pensé que la musique aurait pu être meilleure, si je n'étais pas si flemmard. :)

Rhino: J'ai fini l'introduction et les effets puis j'ai contacté les musiciens et deux parties furent faites de différente façon. Pour l'intro Yzi a fait la synchro sauf pour les samples qui sont joué par du code (comme j'avais fait les samples, je pouvais les modifier à loisir). Le plus dur pour moi fût dans la partie principale.

Quand j'ai eu la musique de Factor6, j'ai commencé à imaginer comment j'allais dérouler mes effets de façon synchrone avec la musique, raconter une histoire. Je devais songer à l'occupation mémoire, les temps de chargement et c'était difficile. Et pour augmenter la difficulté, j'ai ajouté des flashs synchro en lisant le volume qui sortait sur chaque voie AY.

À propos du player, j'ai demandé à Arnodemu quelle était la façon la plus rapide de jouer une musique sur CPC et il m'a parlé du KitAY. Coup de chance, c'est open-source (merci à Madram) donc j'avais besoin de deux choses: Jouer des samples pendant la musique et une version stable du code (une version stable était nécessaire parce que les techniques que j'utilise nécessitent des timings précis et ils sont à la frame). Mais une version stable n'était pas la meilleure option pour tous les effets donc j'ai ajouté quelques changements pour qu'on puisse activer ou non la fonctionnalité. Pour les samples, j'ai demandé à Targhan qui m'a gentillement aidé.

Je pense que c'est bien d'avoir de l'open-source pour ce genre de routines ainsi les programmeurs peuvent se concentrer sur les effets de leurs démos et je pense qu'Arnoldemu va sortir les sources du chargement musical pour les mêmes raisons.

Afin de conclure cette interview, pouvez-vous nous dire chacun sur quels projet vous vous impliquez maintenant? Merci à tout le monde!

Yzi: Je suppose que tu parles de projets relatifs à la scène démo. Je n'ai rien dont je puisse parler publiquement pour le moment. Ça serait bien de faire quelque chose pour mon groupe MSX Lieves!Tuore cette année, mais comme tout le monde est en plein dans la vie normale plan-plan ça ne sera pas évident.

Factor6: Heu, après plusieurs petites choses sur ZX Spectrum pour la Forever C party, je prépare un petit jeu de rien du tout pour l'Atari 8-bits. Alors je pense faire une démo dotée d'une musique au beeper avec Yerzmyey sur le ZX (code et GFX). Je travaille aussi sur des dessins pour une party Atari (oui je suis assez impliqué sur des projets Atari 8-bits ces derniers temps). Et enfin, je prépare un seconde album de musiques chiptunes, principalement des musiques AY.

Mac: Pour ma part j'ai plusieurs projets mais peu en rapport avec la scène démo: Un jeu de plateau orienté stratégie, une interface utilisateur avec des icones, fenêtres et menus pour Spectrum +3 (aux balbutiements du projet) et des jeux pour téléphones…

Paulbrk: Sur la scène rétro, je suis en train de réaliser un jeu d'action super rapide sur MSX2 et aussi un jeu sur C64 :) avec Lobogris. Niveau professionnel, je participe au développement de jeux mobiles et consoles.

DaDMaN: Comme je l'ai déjà dit, pour le moment, nous (RetroFactory) développons la version CPC du jeu Uwol:Quest for money, Kings Valley I & II. Nous continuons aussi à développer (Syx et moi) le fameux mode 5, une version particulièrement colorée du mode 1. D'autres choses sont en développement mais on ne peut rien dire, héhéhéhéhé, Merci!

Arnoldemu: Je travaille sur 3 projets. Le premier consiste en du code pour une démo musicale. Les autres sont deux jeux. Le premier est terminé à 60%, il reste encore beaucoup de travail de finition mais il promet déjà d'être un jeu fun et entrainant. Ce jeu devait à l'origine être fait sur la Nintendo DS mais il a été modifié et retravaillé pour l'Amstrad. L'autre jeu est complété à 20% et est suspendu. Je ne trouve pas que le gameplay soit fun donc il ne sortira peut⁻être jamais. Bien sûr, si vous voulez en savoir plus sur le CPC, faire des démos ou des jeux dessus, venez donc sur le cpcwiki et je serai ravi de pouvoir vous aider.

Rhino: Je suis en vacances rétro maintenant. Merci! :)

(ndlr: |respect, Grimmy pour les captures d'écran!)