[RMXP] Faire défiler un panorama

Si un maker passe de rm2003 à rmXP, il constatera très probablement que, malgré quelques nouveautés pratiques comme les interrupteurs locaux, beaucoup de petites fonctionnalités auront disparu, entres autres les options de gestion des panoramas. RPG Maker XP, à ce sujet, ne permet pratiquement que d'afficher un panorama... alors comment diable faire défiler un panorama sous ce logiciel ?
La solution : en passant par les scripts. Comme beaucoup d'autres choses (la gestion des messages, par exemple), on peut "remettre" les options disparues de rm2003 grâce aux scripts, y compris la gestion avancée des panoramas.
Ce qui est dommage, c'est que, même si avec les scripts, on peut faire pas mal de choses, on n'aura peut-être pas forcément envie d'apprendre le ruby juste pour pouvoir gérer rmXP comme rm2003... alors pas de panique, je vais tenter de vous expliquer comment faire, sans trop entrer dans les détails, en expliquant juste ce qu'il faudra pour que tout le monde puisse faire défiler ses panoramas sans trop de difficultés.

Si vraiment vous ne voulez rien comprendre au ruby ou si la partie théorique ne vous intéresse pas (ou si vous connaissez déjà le ruby), passez directement à la partie III.


I - Du 2003 au XP : de l'événementiel au script

Comme je le disais dans l'introduction, on veut faire défiler un panorama (ou arrière-plan) sous rmXP, par exemple pour faire un ciel mobile un peu moins morne qu'un ciel fixe, ou pour donner une impression de déplacement. Par exemple, si votre personnage fait une chute dans le ciel, celle-ci sera plus réaliste si le ciel bouge avec lui...

Sous rm2003, c'est facile : on accède aux commandes d'événement, à la section "Modifier un arrière-plan" (même s'il y a une faute de frappe, ne faites pas exprès de ne pas l'avoir trouvée ), on choisit son panorama, on coche les sections "Défilement..." et "Auto-défilement...", et on précise les vitesses horizontales et verticales de déplacement.



Sous rm2003, c'est donc très simple, car on y a accès à partir des événements.
Sous rmXP, en revanche... pas moyen de trouver une option dans la gestion des arrière-plans qui permette de les faire défiler. Tout ce qu'il propose, c'est d'afficher un panorama, et on dirait que c'est déjà trop lui demander, car il ne sait rien faire d'autre à ce sujet. Bon, je vous l'accorde, on peut quand même gérer les couleurs un chouïa, mais à part ça...



Qu'à cela ne tienne, puisqu'on ne peut pas arranger ça avec des events, on va le faire avec des scripts !


II - La classe Spriteset_Map

Ouvrez donc l'éditeur de scripts (F11 ou l'icône à côté de l'importation de ressources) et cherchez le script Spriteset_Map.
Je ne vais pas expliquer dans le détail son fonctionnement, car c'est quand même un peu imbuvable quand on ne parle pas le ruby (et surtout parce que je ne saurais pas le faire ) ; toutefois, je vais quand même vous expliquer quelques petites choses nécessaires à savoir pour comprendre comment on peut résoudre notre problème.

a) Mais où se trouvent ces #2{~#é@ de panoramas ?

Tout ce qui concerne les panoramas est géré par la variable @panorama.
Si vous lisez le script en diagonale, vous devriez d'ailleurs trouver quelques endroits qui en font mention, par exemple la ligne 29 :

Code:

@panorama = Plane.new(@viewport1)
@panorama.z = -1000

Cette portion de code se trouve dans la méthode "Initialize", qui permet d'initialiser les variables. Si vous n'avez pas touché au script auparavant, celle-ci est définie entre les lignes 12 et 53.
Rassurez-vous, je ne vous demanderai pas de retenir ça, toutefois on reviendra à la méthode "Initialize" tout à l'heure, vous verrez pourquoi.

Vous pouvez ensuite voir la ligne 65 :

Code:

@panorama.dispose

On... dispose le panorama. Rien de bien passionnant encore.
Rendez-vous plutôt lignes 121 et 122, c'est là que ça devient intéressant :

Code:

@panorama.ox = $game_map.display_x / 8
@panorama.oy = $game_map.display_y / 8

Pourquoi donc ? Eh bien on verra ça après un peu de baratin, théorique mais nécessaire pour comprendre ce que nous allons faire.


b) Un peu de théorie

Je vais devoir vous sortir un petit paragraphe théorique pour que vous puissiez comprendre ce qu'on va faire (vous ne pouviez pas y échapper de toute façon !).

Parlons d'abord de ces étranges symboles qui signalent la présence de variables : @ et $.
Certes, ce sont toutes les deux des variables, mais il y a une différence entre les deux :
- $ indique une variable globale. Autrement dit, elle est accessible absolument partout, dans tous les scripts, donc vous pouvez la consulter ou la modifier où bon vous semble (mais faites quand même attention à ne pas tout faire péter, notamment si vous ne savez pas à quoi servent certaines de ces variables...)
- @ indique une variable de classe, que vous ne pouvez utiliser que dans la classe où elle est définie. Je ne vais pas expliquer ce qu'est une classe (sinon je serais bien parti pour vous faire un cours de ruby et de RGSS, et c'est justement pas mon but), mais sachez que dans notre cas, elle n'est accessible que depuis le script où elle est définie.

Attention : ne confondez pas avec les variables que vous utilisez pour les événements ! Ca n'a rien à voir sur ce coup-là, même si le fonctionnement est à peu près le même. D'ailleurs, vous n'avez pas vu de variable nommée "game_map" ou "panorama" quand vous gérez les variables via les events, non ?

Ensuite, le point indique la présence d'une sous-variable dans notre cas. En clair, @panorama est notre variable, et elle possède des champs ox et oy.
L'intérêt ? Eh bien comme ça on peut positionner notre panorama.

Maintenant, vous devriez comprendre la fonction des lignes 121 et 122. Je les remets, d'ailleurs, vu que c'est sur celles-ci que nous allons travailler :

Code:

@panorama.ox = $game_map.display_x / 8
@panorama.oy = $game_map.display_y / 8

III - Gérer le déplacement des panoramas

Si vous avez bien compris ces fameuses lignes, vous devriez alors savoir comment positionner votre panorama.
En effet, la position horizontale du panorama est donnée par $game_map.display_x / 8, de même pour la position verticale donnée par $game_map.display_y / 8.

a) Gérer le déplacement via le script Spriteset_Map

Il vous suffit donc de remplacer $game_map.display_x / 8 et $game_map.display_y / 8 par... ce que vous voulez.
Par exemple, si vous mettez :

Code:

@panorama.ox = @tilemap.ox
@panorama.oy = @tilemap.oy

Ceci fera en sorte que les panoramas suivront les cartes.

Mais ce qui nous intéresse, c'est de faire défiler ces panoramas.
Pour cela, on va utiliser une astuce fréquemment utilisée en programmation, qui consiste à ajouter à la variable elle-même une certaine valeur.

Code:

@panorama.ox = @panorama.ox + 1
@panorama.oy = @panorama.oy + 1

Avec ce code, les panoramas défileront donc vers la droite (1re ligne) et vers le bas (2e ligne). Vous pouvez les faire défiler plus ou moins vite en mettant une autre valeur que 1. Pour les faire défiler vers la gauche ou vers le haut, mettez un signe - (négatif) au lieu du signe +.

Maintenant, si vous testez ceci sous rmXP, vous constaterez que vous panoramas défilent comme vous le souhaitez ! Enfin !

Cependant, on n'est pas encore sortis de l'auberge.
En effet, avec ce que vous avez appris dans le paragraphe précédent, vous pouvez faire défiler les panoramas, certes... mais c'est valable pour tous les panoramas, sans exception. Or, si vous voulez que quelques arrière-plans restent immobiles, ou si vous voulez faire défiler ces arrière-plans avec des vitesses différentes, il va falloir revoir nos plans...


b) Le problème des variables locales

Théoriquement, ce qu'il faudrait faire, c'est pouvoir modifier la variable @panorama et ses champs ox et oy quand on le souhaite, au lieu de leur mettre des valeurs fixées dès le départ dans le script.

Heureusement, il est possible de modifier ces variables même via des commandes événementielles. Pour cela, dans les commandes de l'événement, cherchez "Insérer un script..." et tapez votre code.

Intuitivement, vous devriez avoir fait quelque chose comme ça dans la commande "Insérer un script" :



Sauf que, si vous avez bonne mémoire, le @ indique que la variable est locale au script dans lequel elle est utilisée. Il n'y a donc pas moyen de changer ça comme ça !
La solution ? Eh bien, puisque les variables locales ne nous permettent pas de faire ce qu'on veut, on va passer aux variables globales.

Retournons un instant à notre script Spriteset_Map. Dans l'Initialize, il faudra déclarer deux variables globales. Leur nom importe peu, mais pour des raisons de clarté, il vaut mieux prendre des noms évocateurs, par exemple on prendra $pano_x et $pano_y.

Copiez ce code ligne 51 (copiez-le avant "update" et "end", autrement dit avant la fin de l'Initialize) :

Code:

$pano_x = @panorama.ox
$pano_y = @panorama.oy

Et modifiez les lignes 121 et 122 (leurs numéros auront sans doute changé par contre) pour y mettre :

Code:

@panorama.ox = $pano_x
@panorama.oy = $pano_y

Voilà, maintenant la position du panorama est définie par les variables globales $pano_x et $pano_y.


c) Gérer le déplacement via les événements

Maintenant que vous avez modifié le script pour définir la position avec des variables globales, vous pourrez maintenant, sans problème, utiliser la commande événementielle "Insérer un script..." et mettre ce code :

Code:

$pano_x = $pano_x + 1
$pano_y = $pano_y + 1

Pour la vitesse et la direction, c'est pareil que via le script, modifiez le nombre pour aller plus ou moins vite et changez le signe pour changer la direction.

Et voilà ! Maintenant il est possible de gérer le déplacement des panoramas comme sur rm2003 ! (bon je vous l'accorde, la commande n'est pas la même, mais elles s'utilise presque de la même façon).
Notez d'ailleurs que rien ne vous empêche de mettre autre chose après le signe =. Si vous voulez mettre le panorama à une position précise, il faudra par exemple mettre :

Code:

$pano_x = 10
$pano_y = 6

d) Au secours, le jeu plante !

J'en suis désolé , mais on a encore un problème (mais promis, j'espère que c'est bel et bien le dernier ).
Dans la plupart des cas, ce qui est proposé marche, mais ça peut arriver qu'en lançant le jeu (que vous commenciez une nouvelle partie ou que vous en chargiez une), celui-ci se mette à planter si vous lancez directement un event ayant une commande de script comme celle-ci :

Code:

$pano_x = $pano_x + 1
$pano_y = $pano_y + 1

En effet, RM n'aime pas que vous utilisiez ce genre de subterfuge si les variables $pano_x et $pano_y n'ont pas eu de valeur préalable...
Pour pallier à ce défaut, il faut tout simplement attendre un peu, par sécurité, pour faire défiler le panorama.

Par exemple, vous avez une map avec un panorama que vous aimeriez faire défiler sans que le héros ne fasse quoi que ce soit. Intuitivement, vous mettriez donc un event en processus parallèle contenant la portion de script que j'ai redonnée tout de suite.
Mais au lieu de le mettre en première page, mettez-le plutôt en deuxième page, avec comme condition "Interrupteur local activé". En première page, mettez un démarrage automatique, une commande "Attendre... 2 frames" et une commande "Activer interrupteur local".
Même si ça peut paraître un peu moins intuitif comme méthode, ça vous évitera néanmoins un plantage incompréhensible lorsque vous lancerez une partie.



Pfiou !
Tout ça pour faire défiler un panorama quand même... enfin, vous me direz qu'en pratique, ça nécessite juste de bidouiller un peu un script, et d'appeler une commande événementielle à chaque fois qu'on veut faire défiler quelque chose.
En fait, je tenais quand même à vous sortir un peu de baratin théorique pour comprendre ce que vous faisiez et pour vous guider un peu au travers du script : quand on ne comprend pas très bien le ruby, je suppose que ce n'est pas de refus.

D'ailleurs, si vous avez compris le principe, vous pouvez toujours vous amuser à bidouiller un peu le script "Spriteset_Map" (mais pas trop quand même...) ; si vous voulez, il est possible de faire défiler par la même occasion les couches de mapping ! :lol: La variable concernée est dans ce cas @tilemap. Certes, ce n'est pas très utile (à moins que vous ne trouviez une utilité, par exemple un niveau tordu...), mais c'est toujours amusant à voir.


Sources

Les explications sur les variables en ruby proviennent du guide sur le ruby de Fabien et celles sur la gestion des panoramas en ruby du tutoriel de Fabien. On pourrait considérer mon tutoriel un peu comme une suite de celui-ci, qui se terminait justement sur le défilement des panoramas sans trop expliquer comment ne pas le généraliser. Néanmoins, un grand merci à lui pour son tuto car il m'a quand même permis d'y voir plus clair et de rédiger ce tutoriel.

J'ai lu en diagonale, c'est sympa comme tuto, bien expliqué.^^

Good.
Tu cites des sources en plus, sympa.
Pas grand chose à dire, ça passe en officiels.

+5 points instructeur.