|
Comme toute religion qui se respecte, la pratique de l'Amstrad CPC s'appuie sur des dogmes. De la même façon que 2 et 2 ne font 4 que sur la base de l'hypothèse que 1 et 1 feraient 2, on n'a pas le droit de pratiquer le CPC sans un minimum de croyances. Les prières se font chez soi dans l'intimité, les cantiques se chantent sur les forums, et les pèlerinages se font occasionnellement lors des meetings, entre croyants, parfois mélangés avec d'autres religions proches (8 bits, 16 bits...), mais toujours sur la foi d'un monde meilleur.
Je propose dans cette page de résumer des différences imperceptibles vu de l'extérieur. Ces petits rien qui peuvent soulever des empires, ces schismes religieux qui vus de l'intérieur sont autant de montagnes infranchissables, faisant passer des croyants pour des impies, selon qu'on adhère ou non à la musique jouée (des quintes justes et c'est marre !).
Marche pas chez moi !
Le premier regret pourra venir d'une démo qui ne fonctionne pas sur le CPC qu'on a sous les yeux. Il est vrai que normalement, une production "CPC" se doit de tourner sur un CPC quel qu'il soit. Donc "mon CPC" devrait pouvoir faire tourner tout ce qui sort. Cela complique parfois la tâche des programmeurs qui se démènent pour pousser les composants de l'ordinateur dans leurs derniers retranchements, et qui deviennent alors incompatibles entre eux du fait de séries différentes. Notamment, un programme en BASIC réalisé sur le 6128 peut très bien ne pas fonctionner sur le 464 si certaines précautions n'ont pas été prises.
Le CRTC
Parmi le plus connu des schismes, on a les ayatollahs de la compatibilité CRTC. Là où certains revendiquent la recherche absolue sur les possibilités du CPC, d'autres estiment que si le programme ne s'adapte pas aux différents CRTC des machines, c'est alors un programme mal ficelé. C'est s'affranchir d'une contrainte qui unit les fidèles sous un même toit. Il faut bien reconnaître que respecter cette règle interdit certains effets que les CRTC1 peuvent faire et pas les autres par exemple.
La RAM
J'ai un 464, c'est un CPC, ça devrait marcher chez moi ! Admettons qu'on peut tout autant accepter la contrainte des 128k dont peuvent d'ailleurs s'équiper le 464 ou le 664. Un autre cas est celui de la RAMcard (ou équivalent). L'utilisation de RSX abaisse le HIMEM. Lorsque les programmes utilisent toute la mémoire en gardant le système (notamment en BASIC), ils ne tiennent alors plus en mémoire sitôt qu'une RAMcard est branchée (et que des ROMs sont activées, naturellement).
Appels directs en ROM
Ce cas peu fréquent dans les jeux commerciaux est nettement plus courant dans le cas de jeux ou démos arrivés après. Une même fonction n'est pas toujours située au même endroit de la mémoire d'un CPC à l'autre (entre un 464 et un 6128). Pour éviter des problèmes de compatibilité, des adresses "standard" ont été mises en place renvoyant au bon endroit. Ce qu'on appelle "vecteurs système". On a vu certains programmes qui faisaient appel au système sans passer par ces vecteurs, rendant alors le programme incompatible entre le 464 et le 6128.
CAT du teaser d'OP sur 464 :
Je n'assume toujours pas... |
BASIC 1.1 vs BASIC 1.0
Un autre cas peut être lors de l'utilisation d'instructions BASIC qui ne sont pas reconnues par le 464. Il est généralement possible de rendre un code compatible avec le 464 en utilisant des astuces (comme remplacer FRAME du 6128 par un CALL &BD19 par exemple). Cela peut sembler un peu périlleux dans certains cas, mais mon avis est que cela se justifie pleinement si on fait le choix d'une production fonctionnant en 64k.
Les CAT'arts
C'est un cas un peu particulier, mais on peut observer des catalogues décorés qui ne fonctionnent pas sur 464. Des petites différences d'interprétation de certains caractères de contrôle peuvent amener dans de nombreux cas d'optimisation à un fonctionnement différent entre un 464 et un 6128. Si cela ne peut pas amener de "plantage", cela peut toujours poser des problèmes d'affichage. Les catalogues décorés fonctionnent aussi différemment selon le mode affiché à l'écran. Cela peut notamment faire grogner certains utilisateurs de RAMcard qui démarrent leur CPC par défaut en mode 2. Il est possible de faire un catalogue qui fonctionne dans tous les cas, mais cela réduit considérablement les possibilités offertes par ce vecteur de créativité. Voir ma série d'articles techniques sur le sujet.
Librement inspiré de
Dream End (Chany) :
 |
Code pas propre
Il est certain que si l'écran saute (symptôme d'un problème de synchro avec l'écran, donc de fréquence), on aura tendance à parler d'un code "pas propre". Mais il existe de nombreuses autres raisons qui peuvent amener à cette intolérance.
50Hz
La contrainte qui est à la fois la plus noble et la plus crétine, c'est le respect du 50Hz. Elle a la double particularité de ne pas être très utile, puisqu'il est possible de sortir assez généreusement de ce 50Hz sans que cela n'empêche son fonctionnement sur un CPC lambda, puisque la tolérance de l'écran est immense. Toutefois, on peut comprendre qu'une démo tournant à 49Hz au lieu de 50Hz triche un peu sur ce qu'il est possible de faire dans un cadre défini. En fait, pour beaucoup, ce 50Hz est une ligne rouge à respecter. Il est certain que c'est le seul moyen d'être certain que la démo passera sur tous les écrans quel que soit leur réglage.
C'est parfois un peu compliqué pour les bidouilleurs débutants ; mais cela reste une contrainte touffue dans le cas de transitions visuelles d'un écran à un autre, même pour les experts. Et là, la qualité de l'environnement de développement peut parfois être déterminante.
D'un autre côté, il ne faut pas confondre "respect des règles du jeu" et "expérimentations" qui visent des objectifs différents. Chacun a sa particularité, et il peut exister un espace de compréhension entre les 2 univers. Pour exemple cette très courte intro en BASIC qui supprime la V-sync pour utiliser un scrolling naturel de l'écran, scrollant, perdu et sans repère. C'est pas "propre", mais diantre, que c'est classe...
64 NOPs
Dans le même registre, le respect d'un tempo de 64µs entre 2 synchronisations horizontales est une règle à ne pas négliger. Au-delà de l'aspect suivant ("c'est l'écran qui travaille"), il faut voir que cet aspect joue sur une zone où la tolérance de l'écran est plus faible. Si l'écran supporte généralement une largeur de 65µs entre 2 lignes, de nombreuses démos exigeant 66µs et plus ne passent absolument pas sur la plupart des écrans (voir frise ci-contre à droite). Dans tous les cas, il semblerait que cela puisse amener une usure prématurée de l'écran.
|
Mise en garde !
Les aspects suivants intègrent une nouvelle dimension religieuse : on quitte l'argument factuel et cartésien du simple bon fonctionnement d'un programme pour arriver à des aspects plus moraux sur la façon d'obtenir un résultat, quel que soit le résultat en question.
|
C'est l'écran qui travaille !
Certains effets (notamment les scrollings au registre 3 du CRTC ou le "flipping hexagonal" utilisant R2) envoient des informations "parasites" à l'écran de façon à bénéficier d'effets secondaires. En l'occurrence, des déplacements de l'affichage parfois impossibles à obtenir autrement. Ces effets sont tributaires de ce que fera l'écran, jugé incontrôlable. En effet, on peut imaginer brancher un moniteur avec des tolérances différentes et des effets altérés à l'écran. Dans certains cas, en utilisant un moniteur complètement différent (soit une télévision, un écran plat ou un vidéoprojecteur), on a des effets absolument fantaisistes. Le tout est de décider si la démo est censée se lancer uniquement sur le moniteur d'origine ou non. Reste donc à savoir si l'écran du CPC fait partie de l'équation.
Le C, c'est sale...
D'autres puristes jugent la façon de programmer, l'optimisation choisie. Ils programment en assembleur, nécessairement très optimisé (si le programmeur est compétent) dans la mesure où on décide octet après octet de ce qu'on exécute et met en mémoire. Ils rejettent par exemple la génération de code à partir de compilateur C, nécessairement moins optimisé, puisque les instructions sont générées par un compilateur. Nul doute que l'optimisation est le maître mot du développement de projets ambitieux. Mais il ne faut pas pour autant dénigrer les possibilités offertes par le C, ne serait-ce que pour tester des effets. Après tout, c'est peut-être pas pire que du BASIC. Mais on reproche peut-être aussi au C de venir d'une autre machine...
Pas un vrai graphiste
Cette partie aura un petit relent de cet article que j'ai écrit il y a un moment déjà. Mais remettre une petite couche là où c'est le sujet n'est pas nécessairement une mauvaise idée. Cette partie redonnera un peu de mesure au flou complet qui entoure ce qu'on a le droit ou non de faire selon les principes moraux de chacun.
En exclusivité, ce dessin préliminaire du Mahjong ! |
100% original
Il est difficile de dénigrer la plus grande valeur d'un dessin dont on est auteur à 100% (composition, idée, réalisation, couleurs, traitement...). Toutefois, au-delà de la rareté de ce genre de réalisation, certains cas semblent ne pas entrer dans les grilles de l'évaluation. Par exemple le cas de la photographie "personnelle" : si ces photographies ne sont pas ouvertement dénigrées, elle ne sont jamais encensées. Il est vrai qu'elles ont rarement été utilisées jusqu'à aujourd'hui. Mais on y voit une forme de facilité. C'est perçu comme moins laborieux qu'un dessin, mais aucun dogme n'a encore tranché ce point sulfureux. Ce genre de photo doit pourtant être largement travaillée pour qu'un résultat intéressant en ressorte sur un écran de CPC. Il n'y a qu'à voir les transferts au dartscan des années 90 pour se faire une idée. J'ai le pressentiment que ce thème sera à nouveau soulevé... ce sera peut-être enfin le jour où on assumera la partie du travail qui consiste à "travailler" une image.
Travailler sur OCP
L'un des dogmes les plus puissants du puriste, et qui est justifié par le "100% original" consiste à dire que tout doit être fait de A à Z sur OCP ou tout autre logiciel de dessin sur CPC (mais on a le droit à un croquis préparatoire). On est ici clairement dans un procès d'intention, dans la mesure où on impose non pas un résultat, mais une façon de faire, une façon de travailler. C'est quand même mieux quand c'est tricoté à la main ma bonne dame ! Mais n'oublions pas que ce procédé interdit toute innovation : aucune image en flipping n'aurait existé sur CPC sans le soutien d'autres ordinateurs. Face Hugger a probablement utilisé un Amiga, et aucun logiciel dédié n'existe. Créer un tel logiciel suppose qu'il sera réutilisé, et son utilisation sortira à son tour de l'innovation et banalisera l'effet, il faudra défricher ailleurs, là où les logiciels n'existent pas encore. Je me permets de rappeler que Climax ne pourrait être réalisée sur CPC que pour 20% des effets maximum, même aujourd'hui, 12 ans après.
Tout faire au crayon
On a bien souvent tendance à croire qu'un bon graphisme se doit d'être réalisé au crayon d'abord, mais surtout ne jamais inclure d'autres documents qui pourraient venir d'ailleurs. Exit donc des illustrations 100% réalisées sur Photoshop ou Illustrator, logiciels pour lesquels la scène n'a pas une culture très développée. Il semble que l'import de photographies réalisées soi-même (citées ci-dessus) ne bénéficie pas non plus d'un réel enthousiasme, quoique ils soient moins ouvertement décriés. Cet argument religieux retrouve une force nouvelle pour les ayatollah d'OCP qui ont discrètement évolué et assument à présent l'utilisation de Photoshop. Ils prétendent alors que ce qui compte, maintenant, c'est le crayon.
Chacun s'impose ses propres contraintes
Cela m'a pris du temps à le comprendre vraiment. Mais chacun tire la couverture à lui, en disant que ce qu'il fait est dans la droite ligne de la bienséance. En fait, il justifie généralement à postériori ce qu'il aime faire et l'impose aux autres comme règle du jeu. Je ne prétends d'ailleurs pas faire complètement exception à cette règle. C'est sans doute l'une des raisons qui me poussent à dénoncer ici certains dogmes (et amener les miens).
Voilà donc ce que je pense en détail des règles du jeu sur CPC :
La compatibilité :
Je pense que tout ce qui sort sur CPC se doit de fonctionner sur la machine d'origine. Je me fixe comme condition le 6128 (tous CRTC), j'essaie de me limiter au 464 lorsque c'est possible (si cela tient en 64k par exemple), et tolère de ne pas fonctionner sur CRTC2 dans la mesure où il est rare et si l'effet ne le permet pas.
Toutefois, je trouve intéressant d'explorer d'autres limites :
- les limites du CRTC1 sont différentes et intéressantes à exploiter, pourquoi ne pas tenter une fois de temps en temps.
- le branchement d'un ampli ne doit pas être nécessaire, mais peut permettre de bénéficier de la stéréo (spécificité CPC) et de fréquences plus larges. Le CPC ciné en a été la grand messe.
- l'utilisation non exclusive d'extensions (les RAMcards se démocratisent, elles peuvent être exploitées si elles restent optionnelles). Il faut bien voir que l'utilisation des ROMs fait partie de la panoplie de départ du CPC, comme la RAM.
- lecteur 3"5 (et formats de 800k) si ce n'est pas nécessaire (si une version 3" existe).
En revanche, j'exige d'une démo que son rendu soit optimal sur l'écran d'origine du CPC (couleur ou monochrome, au choix) et sur l'ordinateur d'origine (pas le Plus ou je ne sais quel émulateur). Le support d'origine (disquette 3" ou cassette) doit être supporté de façon impérative.
Que le programme plante carrément sur émulateur ou Plus m'importe peu. Que l'image soit horrible sur une télévision ou un écran LCD n'est pas un problème, pourvu que la réalisation soit compatible avec ce que l'on achetait en 1985.
Le jour où le dernier écran CPC aura lâché, vous ne me verrez plus sur CPC.
Les outils :
Pour ce qui est des outils utilisés, je suis plutôt permissif. Pour moi, seul le résultat importe. On peut brancher une centrale nucléaire et tous les supercalculateurs du monde pour gagner 5 NOPs, je n'en déplore que la gabegie énergétique.
Je ne suis pas sévère avec tout ce qui est complètement désynchro si ça tourne sur un écran "normal". Je considère qu'une désynchro est un bon moyen d'utiliser un périphérique (l'écran) tout comme l'utilisation du Z80 du 1541 sur C64. Mais si ce n'est pas intentionnel, j'appellerai ça une "erreur de débutant".
J'admire qu'une réalisation soit complètement originale, mais je considère avec tous les égards chaque élément nouveau. Et chacun connaît ma position sur les transferts, qui ne sont pas à mes yeux une maladie honteuse, mais simplement un moyen de travailler sur le rendu et non la composition originale. Le tout étant d'être clair sur cette position. Ce qui m'importe ici, c'est que l'objet travaillé le soit avec soin (transfert ou œuvre originale).
Saint Taxerror, priez pour nous...
Les éléments religieux mis en avant dans cet article ne sont pas exhaustifs. D'autres prétextes à chamaillerie existent, notamment les écoles entre DAMS ou Maxam, avec ou sans fond noir, DSK ou HFE, RAM ou trackload, CAT'art en séquentiel ou multimodes, Lipton yellow ou Bergamote... la liste est infinie. J'ai juste tenté d'attirer votre attention sur les éléments les plus courants qui ressortent sur le jugement dernier d'une release. Et c'est un potentiel sujet de troll vraiment jouissif. Si vous êtes nouveau venu sur la scène, sachez que vous devrez nécessairement un jour ou l'autre vous justifier sur l'un des points cités. Mais regrettons déjà que les acteurs de la scène vieillissant, ces débats puérils s'étioleront pour atteindre la sagesse. Le CPC gagnera en karma, mais la passion ne sera plus la même.
|
