Archive for the “Général” Category

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 »

On va faire une pause nécessaire dans l’explication de l’installation des composants de Mugen.

Sous le titre de cet article, librement emprunté à un certain humoriste, on va parler de la maîtrise de l’anglais. Dans Mugen, et plus généralement dans l’informatique, l’anglais est partout, et le maîtriser est presque indispensable.

Par chance, les outils de traduction sont aujourd’hui plus performants qu’ils ne l’étaient il y a encore quelques années, même si tout n’est pas parfait.

Pourquoi l’anglais ? Parce qu’il est omniprésent, à tout niveau :

  • Dans la documentation Mugen, source à privilégier lorsque vous tenter de résoudre un problème avec Mugen,
  • Dans les sites & forums (Elecbyte, Mugen Guild, RandomSelect, etc., les sites et forums francophones étant assez peu vivants ces derniers temps),
  • Dans le code Mugen (ex : en sachant que « Not » exprime une négation, que « Hit » signifie « touché » et « By » signifie « par », on peut déjà avoir une bonne idée de ce que fait un « NotHitBy » avant même de lire la doc sur cette fonction…),
  • Dans les « readme » (on y reviendra prochainement).

Bref, l’anglais est un peu partout. Il se trouve que Mugen a une portée mondiale, et que tout le monde ne parle pas le français (ou le japonais ou le portugais ou l’espagnol, etc.), et que l’anglais reste la langue la plus universelle. Vous n’y couperez donc pas.

Au-delà du vocabulaire « traditionnel », scolaire que vous pourrez retrouver çà et là, vous verrez que les anglophones utilisent des termes parfois obscurs, équivalents à nos « diminutifs » francophone (ex : « aprem » pour « après-midi »). Si ceux qui ont l’anglais pour langue maternelle s’en débrouillent assez bien, il faut reconnaître que ce n’est pas toujours évident pour ceux qui ont appris l’anglais à l’école, et qui ne maîtrisent donc qu’un anglais très « basique ». On vous enseignera en effet davantage une phrase comme « Come on, what are you doing ? » plutôt que « c’mon, whad’ya doin’ ?».

Et je ne vous parle même pas des sigles comme AFAIK (As Far As I Know), IIRC (If I Recall Correctly), IINM (If I’m Not Mistaken), etc. Bref, les équivalents anglais de nos « OSEF » et compagnie.

Bref, si vous voulez pratiquer Mugen, il vous faudra apprendre/réviser un minimum d’anglais courant…

La seule consolation pour ceux qui sont fâchés avec la langue de Shakespeare, c’est que les anglophones sont quand même moins « kikoo lol » que les francophones : quand ils écrivent des messages, ça reste assez compréhensible dans l’ensemble, et on n’a pas besoin de décrypter mot à mot comme c’est parfois le cas avec le style SMS de certains (prétendus) francophones. On ne trouve donc pas de version anglaise de « komen on fé pr avoir + de perso? ». C’est toujours ça de pris…

Comments Aucun commentaire »

Elecbyte vient de sortir la RC6 de Mugen 1.0. Majoritairement, la mise à jour concerne des corrections de bugs, mais on notera un nouveau trigger Cond (équivalent de IfElse, mais avec un fonctionnement subtilement différent) et de nouveaux paramètres pour les stages, qui les rapprochent du DEF des persos. Et aussi, de façon assez ironique, l’implémentation de bugs, afin d’assurer la rétro-compatibilité avec la version 2002 de Mugen (Linux).

Comments Aucun commentaire »