Enfin pas totalement. Ou alors vous pouvez considérer que c’est un zombie, un mort-vivant. Comme vous voulez.

‘fin bref, vu que le dernier article date de 8 mois, on ne peut pas franchement dire que le site est très animé. Il en va de même pour toute la communauté francophone, d’ailleurs.

Au niveau international, pour ceux qui seraient allergique à l’anglais, au site d’Elecbyte ou aux deux réunis, signalons quand même la sortie de la version 1.0 finale de Mugen, théoriquement 100% rétro-compatible avec les créations Mugen existantes. « Théoriquement », car dans les faits, on sait que certaines créations (assez marginales, heureusement) posent des problèmes qui n’ont pu être résolues à cause de certaines spécificités de la version 1.0.

Les changements apportés depuis la RC 8 sont relativement mineurs. On signalera :

  • La possibilité de personnaliser l’écran d’info à l’écran titre, celui qui s’ouvre et se ferme avec la touche F1,
  • Les fichiers SND contenant des sons WAV illisibles provoquent désormais un simple message d’alerte au lieu de faire planter Mugen.
  • Une modification de la licence, qui permet désormais d’inclure l’exécutable de Mugen dans des compilations gratuites et non commerciales.
  • Des corrections d’erreurs :
    • Correction de l’associativité de l’opérateur := pour les variables flottantes (fvars),
    • Correction d’un bug sur les sons (joués sur un mauvais canal ou avec une balance stéréo incorrecte),
    • Storyboards : remplacement des paramètres non fonctionnels « soundX.volume » par « soundX.volumescale ».
    • Correction d’erreur de positionnement des caractères sur les écrans de victoire et de résultat.

C’est à peu près tout. Comme je l’évoquais, toutes les incompatibilités relevées n’ont pas été corrigées, mais on peut penser qu’Elecbyte aura jugé que celles qui restaient étaient suffisamment marginales et/ou anodines pour être laissées de côté, afin d’avancer sur de nouveaux projets (notamment la version 1.1, et à terme, la version 2.0).

Comments Aucun commentaire »

Le 29 juin dernier, Elecbyte a sorti une nouvelle Release Candidate de Mugen, la version 8. Plus de 3 mois après la sortie de la RC 7, et après environ 2 mois de silence radio sur le blog et le forum, le studio de développement prouve qu’il est toujours actif, et poursuit sa route vers la version finale de Mugen 1.00.

Les nouveautés sont assez réduites en nombre, mais très intéressantes sur la qualité. Tout d’abord, on trouve un grand nombre de corrections de bugs :

  • le parallaxe dans les stages,
  • le trigger InGuardDist qui retournait 0 dans certains cas,
  • le sctrl PlayerPush qui contenait un bug dans la gestion de la hauteur des résolutions,
  • une erreur de précision lors de l’application des lois physiques,
  • amélioration du placement des sprites retaillés,
  • mauvais placement des animations retaillées et appelées par SelfState dans un state temporaire,
  • suppression de la détection de Pos Y < 0 dans le state de stance du common1.cns pour des raisons de compatibilité,
  • Fontv2 : utilisation des banques de palettes dans leur ordre d’entrée dans le SFF au lieu de leur numéro,
  • problème de démarrage sur de vieilles installations Windows réglé,
  • problème de curseur n’apparaissant plus après être passé en plein écran via Alt+Entrée,
  • problème de champs bleus et verts du AllPalFX qui étaient ignorés : réglé,
  • problème d’explods système n’étant pas effacés avant la sélection du mode et l’écran de sélection des personnages,
  • problème de chemin des musiques non ajustés si le nom est vide : réglé,
  • réglage du problème de volume sonore et de mouvements,
  • réglage du problème d’échelle sonore,
  • réglage du problème d’affichage de l’écran de victoire après un combat rapide,
  • réglage du problème de répétition du son durant le fondu en apparition.
  • sprmake2 : réglage du problème de plantage quand pal.discardduplicates = 0

Mais la RC8 ne se cantonne pas à ces simples correction. Il y a des modifications majeures qu’il convient de souligner :

  • Tout d’abord, la branche « EX + alpha », offrant une gestion différente des sons, est désormais fusionnée avec la version principale de la RC. Il n’y aura donc plus de version « EX + alpha ».
  • Dans les stages, le tilespacing devient un paramètre obligatoire pour les éléments animés utilisant le tiling. Mettre n’importe quel paramètre du tilespacing à 0 désactivera le tiling sur l’axe concerné (ceci afin d’éviter des problèmes avec des décors prévus pour la version 2002 ayant un paramètre de tilespacing incorrect).
  • Enfin, et surtout, l’apparition d’un trigger StageVar().

Attardons-nous un moment sur cette dernière nouveauté : ce trigger fonctionne un peu sur le modèle de Const() : on entre entre parenthèses le paramètre à vérifier, et on entre de l’autre côté d’un signe « = » (ou « != ») la valeur à comparer. Pour l’instant, seuls les paramètres du groupe [Info] des stages peuvent être vérifier, qui sont tous des chaînes de caractères.

Exemple d’utilisation :

trigger1 = StageVar(info.name) = « Spain »
trigger1 = StageVar(info.author) = « Toto »

Ce qui permet de vérifier qu’on se bat dans un décor nommé « Spain », réalisé par Toto. Les paramètres acceptés (au moins pour l’instant) se limitent à info.name, info.displayname et info.author.

Cet ajout est d’une grande importance, car il va permettre d’identifier beaucoup plus simplement le stage dans lequel le personnage évolue, et il sera ainsi plus simple de générer des interactions entre le décor et les personnages (même si ces interactions devront être codées dans le personnage).

C’est un premier pas vers un meilleur contrôle des stages, réclamé depuis longtemps par les créateurs…

Comments Aucun commentaire »

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).

Comments Aucun commentaire »

Elecbyte a publié il y a une dizaine de jours maintenant un nouvel article sur son blog. Loin des considérations technique des précédents messages, on a eu droit cette fois à un message plus court, mais qui ravira sans doute les fans d’Elecbyte : il est en effet dédié à Suave Dude.

Mais qui est Suave Dude ? Pour ceux qui sont rapidement passé sur la simplicité de KFM en le supprimant de leur « select », il se trouve que KFM est placé dans un mini scénario ; en gros, KFM et sa dulcinée passaient des instants heureux quand ils ont été attaqués par des méchants, dirigés par… Suave Dude ! Celui-ci profite de la bagarre pour kidnappé la jeune femme, et KFM se lance à sa poursuite. Un scénario bien bateau, mais suffisant pour exposer les bases des storyboards de personnages.

Suave Dude est donc l’ennemi juré de KFM. Seulement voilà, Elecbyte ne l’a jamais créé en tant que combattant, si bien que KFM n’a personne à qui botter les fesses. Une situation sur laquelle Elecbyte avait joué de façon un peu humoristique pour créer le storyboard de fin.

Aujourd’hui, on apprend qu’Elecbyte a fait travaillé sur le personnage de Suave. Tout d’abord sur l’histoire (un peu) : SD et KFM se sont déjà croisés, avant que la petite amie de KFM ne se fasse enlevée. L’affrontement avait tourné court, SD se faisant réduire en purée en quelques secondes. C’est donc par vengeance qu’il a kidnappé la petite amie de KFM. Ensuite sur le design (beaucoup plus). A l’origine, Suave Dude se résume à un sprite unique tiré d’un autre projet privé, et destiné à expliquer le fonctionnement de PCXClean (un outil de « nettoyage » de sprite pour les anciennes versions de Mugen). Il revient ensuite en 2001 sous formes de « gribouillis » dans les storyboards de KFM. Mais d’autres sprites ont été refaits depuis, améliorant le design, assez proche d’un KOF, je trouve, dans sa dernière version.

Le message d’Elecbyte propose également une version « screen », digne d’un storyboard qui le mettrait en scène, et où il apparaît souriant dans le pur archétype de la bogossitude (une raison de plus pour vouloir lui en coller une ?).

Tout ce travail, et le message même d’Elecbyte, seraient-ils des signes annonçant le second personnage d’Elecbyte ? Rien n’est moins sûr, en fait. Les dernières phrases de l’article laissent de la place au doute :

L’avancement officiel sur le personnage a été mis de côté, et jusqu’à aujourd’hui, Suave doit encore devenir plus qu’un simple sprite  debout.

A quoi ressemblerait Suave Dude s’il avait été refait en personnage moderne ? Nous laissons ça à votre imagination.

Bref, Elecbyte reste flou. D’un côté, ils ne disent pas que le projet est complètement abandonné, et l’idée de faire de SD un personnage à part entière est  évoquée de façon prononcée. En même temps, il ne s’agit clairement pas d’une priorité d’Elecbyte et le fait de « laisser à notre imagination » ce que donnerait ce personnage indique implicitement qu’il ne verra probablement jamais le jour concrètement. Il s’agit donc probablement d’un article un peu nostalgique, tout en alimentant davantage l’histoire de Mugen…

http://www.elecbyte.com/blog/suaves

Comments Aucun commentaire »

Elecbyte poursuit son « CNS’s Las Hurrah », c’est à dire les améliorations qui vont être apportées au format CNS tout au long de la branche 1.x de Mugen, avant sa disparition annoncée à partir de la version 2.0.

Cette fois, Elecbyte a annoncé sur son blog l’apparition des « variables personnalisées ». Actuellement, Mugen dispose de 100 variables, réparties en 60 variables « entières » (qui ne prennent que des valeurs entières) et 40 « flottantes » (qui prennent donc des nombres à virgule), et nommées de façon uniforme : var(x) pour les variables entières, où x est un numéro allant de 0 à 59, et fvar(x) pour les variables flottantes, où x est un numéro allant de 0 à 39.

Ce système de variables permettait de faire pas mal de choses, mais restait assez limité par plusieurs points. D’une part, le nombre de variables ; si 100 variables, ça peut sembler énorme à première vue, il se trouve qu’à force, on peut rapidement atteindre cette limite, et on se retrouve à trouver des petites astuces pour réduire la consommation de variables pour un personnage (comme celle-ci). L’autre problème, c’est que toutes les variables ayant le même nom, seul l’index (le numéro) changeant, elles ne sont pas très « parlante ». Le développement d’un personnage s’étalant sur plusieurs mois généralement (voire plus, si on compte les updates), il faut soit une très bonne mémoire, soit tenir à jour une liste des variables utilisées pour savoir que var(58) correspond, par exemple, au nombre de rupees de Link tandis que la var(8) correspond au mode « invisible »…

Eh bien il sera prochainement (pas avant la version 1.1, quand même) de définir des variables avec un nom précis (comme en programmation, en fait). Il sera alors possible de mettre par exemple :

$money := 50
$invisibility := 0

Ce qui initierait une variable « money » avec une valeur de 50, et une autre variable « invisibility » à 0. On notera l’utilisation de l’opérateur d’assignation « := », relativement peu utilisé actuellement.

Les variables pourront être de type flottant ou entier, ou « flexible », c’est à dire qu’elles s’adapteront en fonction de la valeur assignée. Elecbyte étudie la possibilité de gérer également des chaînes de caractères (ex : $sex:= « male »). Néanmoins, même si Elecbyte convient de l’utilité de la chose, ce n’est pas une priorité, et cela rendrait obsolète tout ce qui utilise actuellement des chaînes de caractères. Et quid de la persistance de ces variables ? Actuellement, les variables sont remises à zéro à chaque nouveau round/match. On peut contourner ce fonctionnement via les paramètre « Int/FloatPersistIndex » du CNS et via le state 5900. Pour les nouvelles variables, leur persistance sera à définir individuellement, ce qui n’est pas plus mal.

L’autre nouveauté, ce seront des « Player variables », des variables de joueurs. Si j’ai bien compris ce que j’ai lu (désolé, c’est assez pointu pour les non-programmeurs – dont je fais partie – et donc mon interprétation peut être plus ou moins erronée ; n’hésitez pas à me corriger), il s’agirait de « mémoriser » une redirection (ou une série de redirections, puisque les redirections multiples seront alors possibles) en tant que variable pour « pointer » sur un joueur (ou helper) en particulier. Elecbyte explique qu’on peut considérer les redirections de triggers comme des « pointeurs » sur des personnages. Les variables de joueur permettraient donc de sauvegarder ces « pointeurs » afin de retrouver le personnage pointé.

J’imagine que ça pourrait être assez utile pour cibler un personnage qu’une redirection « classique » ne pourrait retrouver à coup sûr (les redirections basées sur « target » par exemple : une fois le coup fini, la redirection « target » est désactivée pour la victime du coup, alors qu’on peut encore avoir besoin d’agir sur ce personnage : on appelle alors notre « pointeur »).

Evidemment, l’utilisation de ces variables de joueur se soumettra à quelques principes de base, et notamment de vérifier si le personnage existe toujours. Car si on pointe un helper et que celui-ci est détruit (par un DestroySelf), il n’existe plus, et donc la variable ne pointera plus sur rien, ce qui provoquerait un bug.

Par défaut, les personnages « extérieurs » n’ont pas accès aux variables du joueur, à moins qu’elles n’aient été rendues « visibles » lors de leur déclaration. L’intérêt, c’est que si certaines variables permettront d’interagir avec les autres personnages, d’autres pourront rester « internes ».

C’est donc une assez grande nouveauté annoncée par Elecbyte, offrant de nouvelles possibilités, et les cas d’applications devraient être assez nombreux…

Comments Aucun commentaire »

Qu’on se rassure, il s’agit toujours de Mugen. Un nouveau billet paru il y a quelques jours sur le blog d’Elecbyte devrait en effet satisfaire nombre de créateurs…

On sait depuis le 1er novembre 2009 que le format CNS tel que nous le connaissons vit ses derniers instants (qui pourraient quand même durer quelques mois, et probablement même quelques années), puisque dans le billet intitulé « Roadmap for M.U.G.E.N », R — un développeur, membre d’Elecbyte — explique ceci à propos de la (très) future version 2.0 :

« we want to look ahead to a less straitjacketed, more general, and ultimately coder-friendlier solution. This means a move away from CNS to something else. »

« nous voulons regarder l’avant vers une solution moins rigide, plus générale, et finalement plus agréable au niveau du code. Ceci implique que nous passions du CNS à quelque chose d’autre. »

Hors le billet qui nous intéresse aujourd’hui est baptisé « CNS’s Las Hurrah, Part 1″, ce qu’on pourrait d’une certaine façon traduire par « Le chant du cygne du CNS, 1ère partie ». Le ton est donné : même si le système de codage tel que nous le connaissons est voué à disparaître pour la version 2.0 de Mugen, Elecbyte compte l’optimiser d’ici là avec les versions 1.x qui sortiront entre la 1.0 (qui a pour but de recréer une rétro compatibilité maximale — on sait aujourd’hui qu’en raison de certains cas particuliers, elle ne pourra pas être totale — avec Linux Mugen) et la 2.0.

Après la mention du trigger StageVar() présenté dans le précédent article, prévu pour la RC8, c’est encore une nouveauté espérée qui a été annoncée (preuve s’il en était besoin, qu’Elecbyte est désormais à l’écoute de ses fans) : rien de moins que les redirections multiples de triggers !

Commençons par le plus simple : qu’est-ce qu’une redirection de trigger ? Voire qu’est-ce qu’un trigger ? Sans entrer dans le détail, un trigger est une fonction d’information, qui retourne donc une valeur donnée. Par exemple, le trigger « StateType » permet de savoir, d’après sa valeur, si le personnage est debout, ou dans les airs, etc.

Mais par défaut, un trigger s’applique au personnage qui l’utilise, or on a parfois besoin de connaître la valeur d’un trigger pour un autre personnage (un helper, le partenaire, l’adversaire, le partenaire de l’adversaire, etc.). Dans ce cas, on peut utiliser ce qu’on appelle la redirection de trigger, qui consiste, donc, à « rediriger » le trigger sur le personnage voulu. Ainsi, « Partner, StateType » nous renseignera sur le StateType de notre partenaire.

Ce système, qui ouvrait pas mal de possibilité, avait toutefois une limite un peu gênante : elle était limitée à un seul niveau. On pouvait donc connaître le StateType du partenaire, mais pas celui de l’helper(3000) du partenaire (qui aurait nécessité une redirection à deux niveaux : Partner, Helper(3000), StateType. Ce genre de construction était proscrit, du moins, jusqu’ici.

Car la redirection multiple de trigger (c’est à dire sur plusieurs niveaux – « recursive redirection » en anglais) sera bientôt possible, et la construction mentionnée avant pourra être utilisée. Et d’après ce qui est annoncé, s’il existe bien une limite arbitraire au nombre de redirections successives, ce nombre serait très élevé. Or on a très rarement besoin de plus de 2 ou 3 niveaux : les limites seraient donc virtuellement levées en totalité.

Mais ça ne s’arrête pas là, car on peut supposer en outre que les « imbrications » seraient possibles avec des redirections utilisant des expressions. Par exemple : Root, Partner, Helper(Root, Partner, var(8)), StateType : on cherche le statetype d’un helper du partenaire du « personnage racine », cet helper étant celui ayant un ID égal à la var(8) dudit partaire.

A quand cette avancée du CNS ? Il faudra être patient, car elle ne sera pas présente avant la version 1.1. Sachant que la version 1.0 en est toujours au stade des RC, ça n’est pas pour demain… Par contre, la mention « Part 1″ laisse supposer que d’autres améliorations importantes du CNS devraient faire leur apparition, confirmant l’expression « chant du cygne » pour ce format…

Comments 1 commentaire »

Elecbyte a posté un nouveau message sur son blog, l’air de rien. Mais quel message ! Il annonce rien de moins qu’une nouveauté attendue par bon nombre de créateurs : la reconnaissance du stage !

Concrètement, il s’agira d’un trigger nommé StageVar( »info.name »), qui devrait logiquement vérifier le nom du stage dans lequel le personnage évolue, soit le paramètre « name » du groupe [Info], dans le DEF du stage. Une nouveauté qui était espérée depuis très longtemps ; il existait des moyens subtils de reconnaître le stage, mais ils étaient si limités qu’on devait les réserver aux seuls jeux complets.

L’avantage de la méthode, c’est qu’elle peut s’appliquer à plusieurs versions d’un même stage. Par exemple, si on a plusieurs versions du stage « Spain » de Vega (Street Fighter II), il suffira que ces deux versions portent le même nom pour que le personnage (Vega, donc) puisse interagir avec les deux.

En outre, on notera que le trigger est a priori « multi-critère ». Elecbyte aurait pu simplement implémenter un paramètre « StageName » par exemple, mais il utilise un trigger plus complexe sur une base « Trigger(param) », similaire au Const() ou au GetHitVar() qui peuvent utiliser plusieurs paramètres. On peut donc raisonnablement imaginer que par la suite, il sera possible de détecter d’autres paramètres du stage, comme la valeur du Zoffset, la hauteur du stage ou sa largeur, etc.

Quand ces nouveautés seront-elles à disposition des utilisateurs ? Pour le nom du stage, ce sera présent dès la prochaine RC (n°8 donc). Pour le reste, il ne s’agit que de spéculations, mais dans le même billet, Elecbyte annonce des informations à venir sur la version 1.1 (rappelons que la version 1.0 n’est pas encore sortie en version finale). On en saura peut-être un peu plus à ce moment-là…

Par ailleurs, il n’est pas impossible que les messages su le blog se multiplient. C’est en effet une requête qui a été posée sur le forum, ne serait-ce que pour montrer qu’Elecbyte est toujours actif sur Mugen, même si c’est juste pour indiquer que tel bug a été corrigé, ou tel élément à été ajouté. La demande a apparemment été prise en compte, et ce nouveau message semble répondre à cette requête.

Comments Aucun commentaire »

C’est par cette phrase qu’en 2002, Elecbyte avait tiré sa révérence après la « fuite » de Winmugen. On pourrait la traduite ainsi : « le projet a rencontré un problème et est en suspend ».

C’est également par cette phrase que débutait l’avant-dernier message du blog d’Elecbyte, le 3 décembre dernier. Il était suivi de la mention « … Just kidding! » ( »… Juste pour rire ! »), et pourtant, le temps a passé sans qu’Elecbyte se manifeste, alors qu’il était auparavant assez présent. Au point que certains, sur le forum du créateur de Mugen, se sont demandés si ce qui n’était qu’une plaisanterie n’était pas devenu réalité, par une triste ironie du sort.

Et pourtant non, Elecbyte est toujours là. Outre un message succinct, mais on ne peut plus explicite indiquant « les rumeurs de notre disparition sont grandement exagérées », on a eu à un nouveau post sur le blog, annonçant le 7 mars dernier une modernisation du rendu.

Mais la véritable preuve qu’Elecbyte est toujours à l’oeuvre est tombée aujourd’hui même, avec la sortie d’une nouvelle RC (la 7ème, pour ceux qui suivent) de la nouvelle mouture de Mugen, estampillée 1.0. Et ceux qui se désespéraient de ne pas voir la branche EX+alpha adaptée pour la RC6 seront content : avec la RC « normale » sort une nouvelle version EX+alpha, logiquement nommée RC7 EX+alpha (la RC6 EX+alpha n’existe donc pas).

Au menu de cette nouvelle version (hors nouveautés spécifiques à la branche EX+alpha) :

  • L’écran d’options utilise désormais la police « font/options.def » si elle est présente, et si elle est TrueType, sa taille est adaptée à la résolution de l’écran.
  • Le passage en plein écran par la commande Alt+Enter est désormais fonctionnelle.
  • La valeur « PageFlip » du paramètre BlitMode (dans le mugen.cfg) est implémenté, ce qui peut résoudre certains problèmes vidéo.
  • Ajout d’un paramètre Title pour les motifs, dans [Options]
  • Plusieurs corrections de bugs
  • Un nouvel outil « sff2png » qui permet d’extraire les sprites d’un SFFv2 en PNG.

Pas de changement majeur, mais ce n’est pas une grosse surprise, puisque Elecbyte avait annoncé que toutes les RC jusqu’à la sortie de la version 1.0 finale ne viseraient qu’à corriger les bugs présents et à assurer la meilleure rétro-compatibilité possible avec les anciennes versions de Mugen (DOS et Linux, le hack Winmugen n’étant pas une version officielle de Mugen).

Comments Aucun commentaire »

Le ton est donné, je ne vais pas être forcément très tendre avec cette méthode. Déjà parce qu’elle ne correspond pas au standard de Mugen, ensuite parce qu’à force de manipulations, ça peut devenir un grand n’importe quoi dans votre Mugen.

Le principe de la « méthode officielle » consiste donc à installer séparément les screenpacks, de sorte qu’ils peuvent co-exister sans se « parasiter ». On peut donc les activer et les désactiver très facilement, sans faire de manipulations complexes. Le « petit » défaut, c’est qu’on peut se retrouver avec plusieurs screenpacks installés, mais un seul activé, donc tous les autres prennent de la place pour rien. Mais bon, à l’heure où les disques durs de base comptent plusieurs centaines de Go, c’est assez relatif, comme problème…

La méthode « bourrin », elle, consiste à « écraser » le screenpack existant avec le nouveau.

0. Faire une sauvegarde de secours !

Comme on l’a dit, le principe de la méthode « bourrin » consiste à écraser les anciens fichiers par des nouveaux. Le hic, c’est que comme on le verra plus loin (avec le pourquoi), il arrive que ces manipulations ne donnent pas le résultat escompté (le screenpack ne fonctionne qu’à moitié, voire Mugen refuse de se lancer, ou ne fonctionne plus comme vous l’aviez configuré, etc.).

Comme on aura écrasé les anciens fichiers, le seul moyen de faire marche arrière sera de posséder un backup, un copie de sauvegarde.

Que faut-il sauvegarder ? Pour être sûr, les dossiers data/ et font/. Une fois que votre screenpack est installé et fonctionne convenablement et que vous ne souhaitez pas revenir en arrière, n’oubliez pas de détruire votre copie. Bah oui, le principal intérêt de la méthode étant de consommer moins de place, ce serait paradoxal de conserver votre sauvegarde, dans la mesure où l’effet obtenu serait de consommer en fait plus d’espace disque…

1. L’emplacement des fichiers… c’est de l’aléatoire…

L’idée de base, c’est que les fichiers utilisés (system.def, fight.def, etc.) vont se retrouver non plus dans un sous-dossier de data/, mais directement DANS data/, les nouveaux fichiers venant remplacer les anciens.

Seulement voilà, dans Mugen, on peut avoir différent niveaux de complexité dans les screenpacks. Vous pouvez avoir un screenpack basique (comme c’est un peu le cas de celui fourni par défaut). Mais vous pouvez également avoir plus de polices, une intro, une ending, un logo, des crédits, des musiques, etc. qui feront plus de fichiers. Dans le screenpack Castlevania, j’ai même inclus des stages !

Et là, on a deux écoles : certains vont mettre tous les fichiers dans le même dossier (en l’occurrence, data/), alors que d’autres vont juste garder les fichiers essentiels (system.def, et fight.def) à la racine de data/ et placer les autres dans des sous-dossiers (style SFF/ pour les SFF, Music/ pour les musiques, etc.). Du coup, l’architecture d’un SP « bourrin » varie selon le cas.

Ca commence à devenir chaotique lors de l’extraction des fichiers : si certains vont prendre la peine de vous laisser des instructions (on en revient à l’importance des readme), et d’organiser convenablement les fichiers, d’autres vous laisseront vous débrouiller par vous-mêmes : les fichiers seront extraits pêle-mêle, et à vous de deviner dans quel dossier ils vont ! Si pour certains fichiers, c’est assez évident (le system.def va dans le dossier data/), pour d’autres, c’est un peu au hasard (les polices vont-elles dans le dossier fonts/ ou dans le dossier data/ ?).

Comme on parle de remplacement de fichier, vous allez être confrontés inévitablement aux écrans de ce type :

Avec ce que cela implique implicitement : l’impossibilité de revenir en arrière (à moins de faire un backup préalable, ce dont la plupart des utilisateurs se passent même s’ils en reconnaissent l’utilité, et malgré l’avertissement que j’ai mis au point 0…).

2. Activer le screenpack… avec un peu de chance !

Une fois que vous avez placé correctement les fichiers (ou en tout cas, quand vous supposez que c’est le cas), il n’y a rien d’autre à faire. Le fichier système ayant été remplacé, le chemin spécifié dans le mugen.cfg est correctement paramétré (à moins que le nom du fichier système soit différent, mais je n’ai jamais vu le cas jusqu’ici).

Donc, il ne reste plus qu’à lancer Mugen pour vérifier le résultat… et éventuellement constater l’étendue des dégâts !

Là, avec un peu de chance, tout devrait aller à peu près correctement. Dans le pire des cas, vous aurez des éléments qui ne sont pas complémentaires graphiquement (imaginez une interface Mortal Kombat avec des lifebars Street Fighter Alpha, par exemple…), mais qui n’empêche pas Mugen de fonctionner.

Pourquoi ces différences ? On l’a dit avant : les screenpacks sont plus ou moins complexes et comprennent plus ou moins de fichiers. La forme de screenpack la plus basique est la simple interface (les menus, les différents écrans), sans lifebars. Et donc, imaginons que vous ayez installé un screenpack complet « Street Fighter Alpha » (interface & lifebars), et que par-dessus, vous installiez un screenpack Mortal Kombat avec juste l’interface : vos fichiers de lifebars ne sont pas remplacées, et sont donc utilisées avec la nouvelle interface. Maintenant, imaginez ce que ça peut donner après des dizaines d’installations successives : avec tous ces screenpacks « empilés », on se retrouve avec l’interface d’un screenpack, les sons d’un autre, les lifebars d’un troisième, les « FX » (effets lumineux) d’un quatrième, les polices d’un cinquième… Bref, ça devient du beau n’importe quoi.

Mais ce n’est pas le pire qui puisse vous arriver. J’ai vu il y a quelques années un screenpack livré avec un fichier common1.cns. A la base, ce n’est pas très gênant puisque c’est un fichier qu’on modifie rarement. Sauf dans des cas très particuliers. Le premier, c’est quand vous installez un jeu complet. Dans ce cas, le common1.cns peut être modifié (en gros, ce fichier contient le code des actions « courantes » des personnages : marcher, reculer, sauter, etc. : comme ces actions seraient codées de la même façon pour pratiquement tous les personnages, Elecbyte les a codées dans ce fichier, ce qui évite au créateur de personnage de le faire). Pour un Mugen « classique », pas de souci, mais pour un jeu complet, le(s) créateur(s) vont plutôt adapter le common1.cns à leurs besoins plutôt que de réécrire pour chaque personnage toutes les parties de ce fichier qu’ils veulent adapter pour leur jeu. Un autre cas, assez similaire, est celui où l’utilisateur est assez expérimenté et souhaite modifier les actions de base pour tous ses personnages, afin de les adapter à ses désirs. Dans ce cas, il modifiera directement le common1.cns. Et donc, si on installe notre « screenpack de bourrin » sur ces configurations, on perd le common1.cns, avec des conséquences plus ou moins grandes selon les modifications qui avaient été effectuées…

Terminons quand même par le top du top, sur lequel je suis tombé une fois : un inconscient a cru bon d’inclure dans son screenpack le fichier mugen.cfg ! Avec évidemment la ligne « motif » modifiée pour que l’utilisateur puisse « profiter » de son screenpack déjà installé… Seulement, vous devez vous rappeler qu’on a déjà évoqué ici toute l’utilité de ce fichier : il vous permet de configurer Mugen (niveau de vie, vitesse de jeu, résolution, sons…), et notamment les boutons de jeu ! Donc avec un tel fichier, vous perdez tous vos réglages !

Pas bien méchant, me direz-vous, il suffit de tout reconfigurer ! Oui, mais ça, c’est le scénario idéal, ma bonne dame ! Parce que dans les faits, il y a aujourd’hui 90% de chances que vous utilisiez le nouveau Mugen 1.0, et 90% de chances que notre screenpack soit prévu pour une autre version. Et d’une version de Mugen à l’autre, le fichier mugen.cfg a connu de subtiles modifications, si bien qu’au final, vous avez perdu votre fichier avec vos réglages, vous n’avez plus le fichier d’origine, et vous n’avez qu’un fichier mugen.cfg prévu pour une autre version, et qui fera donc planter Mugen lorsque que vous le lancerez !

4. Conclusion

Au départ, ce système d’installation se veut plus simple (on remplace juste les anciens fichiers par les nouveaux), mais à l’arrivée, les failles de cette méthode sont nombreuses, et même dangereuses pour certaines !

Récapitulons la comparaison entre les deux méthodes :

Avantages de la méthode « bourrin » :

  • Mugen prend moins de place (à condition de ne pas faire de sauvegarde de secours)

Avantages de la méthode « classique » :

  • Plusieurs screenpacks peuvent co-exister de façon indépendante,
  • Les fichiers de chaque screenpack sont dans des dossiers séparés ce qui évite les mélanges hasardeux,
  • Ce système de sous-dossiers facilite l’extraction des fichiers,
  • Avec ce système, on sait où trouver tous les fichiers d’un même screenpack (pratique pour la suppression),
  • Si un screenpack pose problème, il est possible (et très simple) de revenir en arrière,
  • On peut désactiver un screenpack sans le désinstaller,
  • La méthode d’installation est toujours la même,
  • On ne touche pas aux fichiers « système » de Mugen comme le common1.cns ou le mugen.cfg, et on ne risque donc pas de perdre ses réglages.

Si vous avez le choix entre un screenpack « bourrin » et un screenpack classique, vous savez désormais lequel choisir, et si vous décidez de créer des screenpacks, vous savez également quelle méthode d’installation choisir…

Comments Aucun commentaire »

Tout d’abord, qu’est-ce qu’un readme ? En français, ça se traduit littéralement par « lis-moi » (ou « lisez-moi », comme vous voulez). Les readme, on en trouve un peu partout, et pas seulement dans Mugen, loin s’en faut. Ce sont des espèces de notices, qui contiennent des informations plus ou moins importantes sur les fichiers qu’ils accompagnent.

Pour l’utilisateur de PC lambda, les readme sont un peu comme des notices classiques : on ne les lit jamais, ou juste pour y trouver une information précise.

Aussi, quand on débute dans Mugen, on fait souvent de même : on ignore les readme, et on se concentre uniquement sur les fichiers. Sauf qu’au moindre problème, on s’empresse d’aller demander sur un forum Mugen, où l’on se fait méchamment envoyer balader avec des « t’as qu’à lire le readme ! ». Retour à la case départ donc.

Dans Mugen, il se trouve que les readme ne sont pas de simples fichiers figuratifs où l’auteur assène une licence de 2000 lignes, ou un historique de tous les changements apportés, ou encore un roman sur ce qui l’a poussé à faire cette création. Bien sûr, on peut y trouver ces éléments qui n’auront que peu d’intérêt pour la plupart des joueurs, mais pas seulement.

Les readme contiennent également des données importantes concernant l’installation de l’élément concerné, et leur utilisation. Par exemple, pour un personnage, le readme pourra vous donner la liste des mouvements, mais aussi expliquer comment activer une version alternative, comment utiliser un mode de jeu, comment fonctionne tel système de jeu inclus dans le personnage, etc.

Bref, pour profiter au mieux d’une création, la lecture du readme est pratiquement indispensable, ne serait-ce que partiellement.

Les readme se présentent sous bien des aspects ; pour les créations basiques (stages, screenpacks…), les readme sont le plus souvent de simples fichiers TXT. En revanche, pour les persos, on peut aller du fichier TXT sobre (comme pour KFM) au fichier HTML détaillé et illustré (ex. avec Link ou Gouki, ici).

La partie suivante est plutôt destinée aux créateurs (ou à ceux qui ambitionnent de le devenir) :

Créer des readme lisibles pour les personnages est certes une contrainte pour les créateurs, mais il est évident que si le readme de KFM, court et réduit au minimum, peut se contenter du format TXT, celui de Link ne le peut pas : la lecture serait très fastidieuse pour le joueur, qui abandonnerait très vite, n’y reviendrait pas, et passerait ainsi à côté de certains aspects intéressants du personnage. La présentation par menu, avec illustrations sert à aider le lecteur à trouver ce qu’il cherche (rares sont les joueurs qui liront le TXT de A à Z d’une seule traite…), et à mieux comprendre ce qu’il lit.

De même, on doit garder à l’esprit que Mugen est international. Pour que le readme soit utile à tous, il faut donc le rédiger en une langue accessible à tous, et là, on en revient à l’article précédent : l’anglais est incontournable. Donc, créateurs, si vous souhaitez rédiger votre readme en français, pensez également à faire une traduction en anglais. Et en tant que simple lecteur, la plupart des readme que vous verrez seront en anglais, d’où la nécessité, là encore, de maîtriser un minimum l’anglais, que vous soyez joueur ou créateur.

Comments Aucun commentaire »