On a fait grosso modo le tour de tout ce qui était utilisation normale de Mugen : installations de composants et réglages. J’entre donc dans une partie qui devrait prendre beaucoup plus de temps : la création.

Car si Mugen est déjà attrayant par le fait de pouvoir mélanger des éléments issus de jeux et d’univers différents, son véritable but est de permettre à l’utilisateur de créer ses propres éléments, pour obtenir un jeu original.

Toute création se décompose en 2 parties : d’un côté, la partie « média » (images & son) et de l’autre, la partie code. La partie media fait bien sûr appel à des talents d’artiste. Ce n’est donc pas un domaine où on peut véritablement expliquer comment s’y prendre, et en tout cas, ce n’est pas le but de ce site. En outre, la majeure partie des créateurs reprennent des graphismes et des sons pré-existants en les extrayant notamment des jeux consoles/arcade. C’est ce qu’on appelle le rip, et on aura l’occasion d’en développer les grandes lignes ultérieurement.

Ce qui va nous intéresser dans la partie media, c’est la façon de l’intégrer dans Mugen. Aujourd’hui, nous allons notamment nous intéresser aux traitements des images.

Dans Mugen, les images d’un élément, quel qu’il soit, sont regroupées dans un fichier SFF (et ce même s’il n’y a qu’une seule image). Donc une fois qu’on a réuni les images à utiliser (qu’on les ait crées ou ripées), il faut les « compiler » dans un fichier SFF afin que Mugen puisse les exploiter. Pour cela, nos images doivent respecter certaines petites conditions.

Deux conditions incontournables

Tout d’abord, les images doivent être en 256 couleurs indexées (ou 8-bits). C’est une opération que la plupart des logiciels de dessin, même les plus simples, savent faire. Un exemple avec Irfan View (gratuit) :

La seconde condition, c’est que ces images doivent être au format PCX. Là encore, nombre de logiciels permettent de convertir des images JPG ou BMP (par exemple) au format voulu. A nouveau, Irfan View fait cela très bien :

A savoir : Depuis l’arrivée de la version Windows 1.0 de Mugen, Elecbyte a mis à jour son format SFF. L’ancienne version du SFF est maintenant dénommée « SFFv1″, et la nouvelle « SFFv2″, lorsqu’il y a besoin de les distinguer. Pour des raisons de rétro-compatibilité avec les milliers de créations existantes, la version 1.0 lit aussi bien les SFFv1 que les SFFv2. En revanche, les anciennes versions de Mugen ne liront, bien sûr, que les SFFv2. On peut également penser que dans un futur plus ou moins lointain, lorsque le SFFv2 se sera généralisé, le SFFv1 ne sera plus supporté.

Quelles sont les différences entre les SFFv1 et v2 ? Ce sont surtout beaucoup de points de détails qu’on ne va pas présenter ici. Retenez, pour le sujet du jour, que le SFFv2 supporte également le format PNG en plus du PCX.

Histoire de palettes

A partir du moment où vous vous lancez dans la création, vous allez souvent entendre parler de « palettes ». Qu’est-ce donc ? Les palettes sont en fait un tableau listant les couleurs (avec leurs valeurs RVB) utilisées dans l’image (ou pas, d’ailleurs !). Dès que vous passez à 256 couleurs (ou moins), votre image aura une palette. Là encore, la plupart des logiciels de dessin sont en mesure d’afficher la palette d’une image, voire de l’éditer :

Pour expliquer rapidement les palettes : chaque couleur dans la palette possède un numéro d’index (de 0 à 255), et chaque pixel dans l’image est associé à un numéro d’index. En conséquence, si on modifie la couleur d’un index, ça modifie la couleur de tous les pixels qui utilise cet index. En outre, il est possible d’enregistrer et de charger des palettes. Si on charge une palette qui utilise des couleurs différentes de la palette d’origine de l’image, on change les couleurs dans l’image. C’est sur ce principe que fonctionnent les différentes tenues des personnages dans Mugen.

La couleur « transparente »

Les deux conditions ci-dessus sont le B.A.BA de la création Mugen. Si elles sont respectées, vos images pourront être lues dans un SFF. Mais on peut trouver d’autres subtilités dans l’utilisation des images, et l’une d’entre elles est la notion de « couleur transparente ».

A retenir : La notion de « transparence » est assez floue dans Mugen, car elle désigne abusivement deux notions. La première se rapproche du concept « d’opacité partielle », c’est à dire que l’on voit un objet, mais que l’on peut également voir au travers pour distinguer ce qui se trouve dessous (comme par exemple lorsque vous regardez à travers une vitre colorée). La seconde notion, celle que nous allons voir ici, est celle de « l’invisibilité » (c’est à dire qu’une partie de l’image n’est pas affichée à l’écran). Attention de bien les distinguer selon le contexte…

Une image est toujours un rectangle, faisant X pixels de large et Y pixels de haut. Ceci est fondamentalement vrai, et ne souffre aucune exception. Mais alors, comment se fait-il qu’en jeu, nous ayons l’image de gauche, et non pas celle de droite ?

En fait, on utilise la même image, mais à droite, on a l’image « brute », alors qu’à gauche, la couleur de fond n’est pas affichée, ce qui donne l’illusion que l’image n’est pas un simple rectangle.

Pour pouvoir utiliser cette fonctionnalité dans Mugen, la couleur de fond doit être celle en index 0 (ou pour reprendre l’explication donnée avant, les pixels que l’on veut rendre invisibles doivent être associés à l’index n°0). Si vous regardez l’image précédente de Link, vous verrez que la couleur de fond (rose bonbon) correspond à l’index 0 dans la palette, et donc tous ces pixels roses ne seront pas affichés dans le jeu.

Le rognage : un gain de place, une manipulation plus facile

Le rognage consiste à découper l’image sur l’un de ses côtés. Lorsqu’on travaille sur les images (rip ou création), on part souvent d’une image large, et on enlève en fin d’opération les éléments superflus. Il se peut alors que votre image soit complètement entourée de fond. Dans ce cas, il faut rogner l’image sur les côtés de façon à ce qu’il y ait au moins un pixel « utile » sur chaque bord. L’intérêt, c’est que vos images seront plus petites et prendront moins de place, et qu’en outre, sprmaker rognera de toute façon vos images, ce qui risque alors de vous poser des problèmes pour placer votre image dans le SFF (on verra ça une prochaine fois).

Laisser un commentaire

Vous devez être connecté pour laisser un commentaire. Connexion »