Un niveau à cheval, avec de la profondeur

Un niveau à cheval

Je voulais un niveau qui défile vite, façon chevauchée comme sur Ivanhoe, avec de la profondeur. Un ciel en fond, puis des montagnes lointaines, une mer, et un premier plan d'herbe qui file sous les sabots. Chaque plan bouge à sa propre vitesse : le sol scrolle vite, la mer suit plus calmement, les montagnes bougent à peine. C'est l'effet de parallax, celui qui donne l'illusion qu'on traverse vraiment un paysage, et je voulais le pousser à fond sur mes deux machines cibles, le STe et le STf.

Sur le papier, c'est de la profondeur empilée. En pratique, sur Atari ST, faire glisser plusieurs plans à des vitesses différentes sans casser l'image est tout le sujet. J'ai donc commencé par un proto isolé, hors du jeu, pour valider l'idée avant de l'intégrer. C'est de ce proto que parle ce post.

Le réflexe matériel, et son piège

Le STe sait décaler son affichage de quelques pixels tout seul, sans effort, grâce à son scroll matériel. L'idée évidente : donner à chaque plan son propre décalage et laisser la machine faire. Zéro mémoire en plus, parfaitement fluide.

Je l'ai écrit. Dans l'émulateur, c'était parfait. Scroll au pixel sur tous les plans, fluide, rien à redire.

Sauf que pousser ce scroll matériel à ce point, en plein affichage, c'est du terrain miné. J'avais le souvenir d'un ancien clignotement, alors avant d'aller plus loin j'ai vérifié de vraies démos et de vrais jeux pour trancher. La réponse la plus nette vient d'une démo réputée de 1990 : son auteur écrit, mot pour mot, qu'il n'a jamais vu ce type de scroll marcher correctement sur tous les ST, qu'il a croisé une bonne quinzaine de configurations de machines différentes, et que si on voit un clignotement c'est qu'on a un modèle qu'il n'a pas pu tester.

Voilà le verdict, par un pro : ce scroll matériel poussé dépend des minuscules variations entre les exemplaires d'Atari ST. Ça marche sur ma machine, ça marchera mal sur d'autres. L'émulateur ne reproduit pas ces variations, donc il me mentait par omission. Pour un jeu qui doit tourner partout, ce raccourci était à jeter.

Préparer les images à l'avance, mais pas toute la scène

La technique fiable, celle des vrais jeux qui scrollent proprement, c'est de préparer les versions décalées du décor une fois pour toutes, au lancement, puis de ne plus faire que des copies, bien moins chères. Le scroll fin devient un simple choix d'image déjà prête. Aucune acrobatie matérielle.

Mon premier jet a préparé la scène entière dans toutes ses positions décalées. Fluide, fiable, et un mégaoctet de mémoire à lui tout seul. Sur une machine d'un seul mégaoctet, c'est mort.

La leçon des vrais jeux, c'est qu'on ne prépare jamais une scène plein écran : on prépare le strict minimum. D'où le vrai correctif : préparer chaque plan séparément, avec juste la finesse qu'il lui faut. Un plan lent a besoin d'une granularité fine, parce que l'oeil fige chaque petite marche. Un plan rapide non, parce que l'oeil ne fige pas une image qui file. Le ciel, lui, est un dégradé : le faire défiler ne change rien à l'écran, une seule copie suffit.

En adaptant ainsi la finesse à la vitesse de chaque plan, je suis passé d'un mégaoctet à un peu plus de la moitié, et il reste de la place pour le reste du jeu.

STe et STf : les mêmes images, deux façons de les poser

Sur STe, je laisse la machine pointer chaque plan vers la bonne image déjà préparée, plan par plan, en cours d'affichage. Trois plans qui bougent par-dessus un ciel fixe, fluide à pleine vitesse.

Un défaut est apparu en découpant la scène en bandes : une fine ligne parasite au raccord entre deux plans. C'était un débordement d'une ligne au moment où la machine change de plan. En scène unique il tombait sur le décor voisin, invisible. En bandes séparées il se voyait. J'ai prolongé chaque image de quelques lignes de marge pour que ce débordement montre une simple continuation du décor, et la ligne parasite a disparu.

Le STf, lui, ne sait pas décaler son image tout seul : il faut la recomposer à la main, chaque frame. Mais les images préparées à l'avance sont déjà là, exactement les mêmes que sur STe. Le STf n'a donc qu'à recopier la bonne image au bon endroit, sans rien recalculer.

Recomposer tous les plans pleine largeur à chaque frame, c'est cependant trop lourd pour le STf, qui retomberait à mi-vitesse. J'ai donc fait un choix de game design assumé : sur STf, je fige les deux plans les plus lents, le ciel et la montagne, et je ne laisse bouger que la mer et le sol. Deux plans de profondeur au lieu de trois, mais une vitesse pleine. Le STf tourne ainsi à la même cadence que le STe.

Le bilan

Ce qui est livré : un proto de niveau à cheval avec de la profondeur, qui tient sur STe et STf, à pleine vitesse des deux côtés, sans clignotement et sans déchirure. Le code est solide, et surtout fiable sur le vrai matériel, pas seulement dans l'émulateur.

La morale rejoint celle du portage STf : sur Atari ST, le matériel offre des raccourcis magnifiques qui ne tiennent pas toujours leurs promesses sur toutes les versions. La voie sûre est souvent la plus terre à terre, ici recopier des images préparées à l'avance plutôt que de demander à la machine un tour de force en plein affichage.

Le proto est téléchargeable ici en disquette .st. Monte-la comme disquette A dans Hatari, en mode STe pour voir les trois plans défiler, ou en mode STf pour la version à deux plans mobiles : c'est le même fichier, il détecte la machine tout seul. Une touche quitte. Pour la version courante du jeu, voir la page d'accueil.