De XNA à MonoGame

Pendant un long moment, l'idée de créer un « vrai » jeu en utilisant des langages managés comme C# était considérée comme de la folie. Mais les choses ont changé et les langages managés prouvent maintenant qu'ils sont tout à fait viables pour créer des jeux, grâce en grande partie à XNA et Unity 3D qui utilisent C# en tant que langage principal ou langage de script. Beaucoup de nouveaux développeurs de jeux ont appris à utiliser XNA afin d'avoir leurs jeux sur Xbox 360 et sur PC sous Windows. Bien que Microsoft ait récemment annoncé que XNA n'évoluera plus et ne sera pas supporté dans l'interface Metro de Microsoft, ces développeurs n'ont pas à tout recommencer à partir de zéro. C'est là qu'arrive MonoGame, une implémentation Open Source de l'API XNA 4.

Le but de MonoGame était à l'origine de permettre aux développeurs XNA de publier leurs jeux sur iPhone, mais le projet a énormément grandi depuis ses humbles débuts. Il supporte maintenant un certain nombre de plateformes, incluant Mac OS X, Linux, Windows 8, Windows Phone 8, Android et iOS. Pour la plupart, l'utilisation est libre (bien que vous deviez payer la licence pour les frameworks Xamarin iOS et Android) et modifiable, car tout le code est couvert par la licence MS-PL (Microsoft Permissive License).

Maintenant, le but premier de MonoGame est de produire une API compatible XNA et multiplateforme, qui peut être étendue à de nouvelles plateformes au fur et à mesure de leur création. Par exemple, comme MonoGame supporte déjà Android, nous avons été capables d'ajouter le support de la Ouya en quelques jours.

Une fois l'API XNA stable, nous envisageons d'étendre l'API avec de nouvelles fonctionnalités que les gens auraient aimé voir dans XNA et l'étendre pour rendre certaines choses plus simples. Pour la plupart des membres de l'équipe qui travaillent sur MonoGame depuis déjà quelques années maintenant, c'est un projet à long terme.

Premièrement, allez sur la page http://www.monogame.net/downloads et récupérez la dernière version stable. Actuellement, MonoGame supporte Visual Studio et Monodevelop/Xamarin Studio.

Si vous voulez utiliser Visual Studio : l'installateur Windows va installer les modèles de projet pour toutes les éditions de Visual Studio 2010 et 2012. Des conditions particulières peuvent exister pour votre plateforme cible :

• pour les Windows bureau, vous pouvez utiliser VS 2010 Express ou une édition supérieure ou VS 2012 Express pour bureau ou une édition supérieure sur Windows 7 ou 8 ;
• pour Windows Store, vous avez besoin de VS 2012 Express pour Windows 8 ou une édition supérieure sur Windows 8 ;
• pour Windows Phone 8, vous avez besoin de Windows 8 64-bits et du SDK Windows Phone 8. Celui-ci installera VS 2012 Express pour Windows Phone et pourra aussi fonctionner avec VS 2012 Professionnel ou une édition supérieure. Pour utiliser l'émulateur Windows Phone 8, votre PC doit correspondre à des exigences matérielles spécifiques. Visitez http://www.microsoft.com/en-GB/download/details.aspx?id=35471 pour plus de détails ;
• pour Android et/ou iOS, vous avez besoin de VS 2010 ou 2012 Professionnel ou une édition supérieure ainsi que de Xamarin Business ou une édition supérieure sur Windows 7 ou 8.

Pour compiler du contenu au format XNB, vous avez besoin de XNA Game Studio 4.0 ou du SDK Windows Phone 7.11 sur votre machine. C'est une solution temporaire tant que notre remplacement du pipeline de contenu n'est pas complet. Pour installer ces SDK sur Windows 8, vous devez d'abord avoir le client Windows Games Live.

Une liste complète des conditions et des liens de téléchargement peut être trouvée ici.

Si vous souhaitez utiliser MonoDevelop/Xamarin Studio : MonoDevelop est un EDI gratuit et Open Source disponible pour Windows, Linux et Mac OS X (http://www.monodevelop.com/). MonoGame est disponible sous la forme d'un paquet, qui inclut les routines pour chaque plateforme. Vous pouvez le télécharger sur CodePlex sous la forme d'un fichier .mpack et l'installer à l'aide du « AddIn Manager » (gestionnaire de modules) dans MonoDevelop. Récemment, Xamarin a publié Xamarin Studio, une version améliorée de MonoDevelop pour les gens voulant utiliser cet EDI. Il y a aussi un fichier .mpack disponible pour cette version.

Une fois que vous avez installé le paquet requis dans votre EDI, vous êtes prêt à créer un nouveau projet MonoGame. Il y a plusieurs choix possibles, mais pour démarrer, prenez celui conçu pour votre plateforme native : pour Windows, créez une nouvelle application « MonoGame for Window GL » (MonoGame pour Window GL) ; pour Mac OS X, créez une application « MonoGame for MacOS » (MonoGame pour MacOS) et ainsi de suite. Une fois que vous avez créé un nouveau projet, vous allez voir la classe habituelle « Game » qui effectue le rendu de l'écran bleu bleuet.

Avant que vous ne commenciez à coder, il y a quelques éléments à savoir. Pour Windows, tous les modèles de projet vont fonctionner directement, mais si vous voulez travailler sur un projet Android, vous aurez besoin de Xamarin.Android provenant de Xamarin. MonoDevelop/Xamarin Studio inclut les modèles de projet pour Max OS X et iOS, mais ceux-ci ne fonctionneront que sur un Apple Mac à cause des conditions de développement requises. Pour iOS, vous devrez installer Xamarin.iOS et pour Mac vous devrez récupérer MonoMac. De plus, à cause de quelques problèmes avec le module AddIn pour MonoDevelop et Xamarin Studio, vous allez devoir télécharger le code source de MonoGame et ajouter les références dans les projets pour MacOS, iOS et Android. (L'équipe de développement travaille sur la correction de ce point.)

Si vous voulez récupérer le code de MonoGame, vous devez installer git. Il existe de jolies interfaces utilisateur pour git, mais la plupart des membres de l'équipe utilisent la ligne de commande. Donc voici la liste des commandes que vous devez utiliser pour récupérer le code :

git clone git://github.com/mono/MonoGame.git MonoGame

cd MonoGame

git submodule update -init ThirdParty

Ces commandes récupéreront une copie en lecture seule de MonoGame et des bibliothèques tierces dont vous avez besoin. Si vous souhaitez faire des modifications et contribuer au projet, vous devez créer un fork du projet. Vous pouvez trouver les détails ici.

MonoGame, tout comme XNA, peut utiliser les fichiers de contenu compilé .xnb. Ces fichiers .xnb sont actuellement créés avec le pipeline de contenu XNA. Au moment de l'écriture de cet article, l'équipe de MonoGame travaille sur une implémentation multiplateforme qui fonctionnera sur Windows, Mac OS X et Linux, mais pour le moment, vous aurez besoin d'utiliser le pipeline de contenu de XNA. Il est aussi possible de charger des ressources natives grâce au ContentManager, donc si vous souhaitez charger directement un fichier .png, vous pouvez utiliser le code que vous utilisez habituellement :

texture = Content.Load<Texture2D>("character");

MonoGame essaiera de charger un fichier .xnb en premier, mais si le fichier n'existe pas, il tentera les types natifs connus pour ce type d'objet. Cette fonctionnalité a été ajoutée à l'origine pour aider les personnes développant pour iOS et Mac et n'ayant pas accès à une machine Windows pour préparer leurs contenus. (Voir la Figure 1 pour une table des types de fichiers disponibles pour chaque classe.)

Comme vous pouvez le voir dans la Figure 1, sur Android vous ne pouvez pas utiliser les fichiers .xnb pour les SoundEffet et Song. Vous devez utiliser les types natifs pour cette plateforme. Cela est dû aux limitations des classes SoundPool et MediaPlayer sur Android. (Certaines de ces restrictions seront retirées au fil du temps et de la maturation du framework.) De plus, certaines plateformes ne supportent que les fichiers .xnb pour certains types. Cela est dû au fait qu'il est plus efficace d'utiliser les fichiers de contenu compilé et optimisé pour ces types. Par exemple, il est plus performant de prétraiter un Model au moment de la compilation que de charger un fichier .fbx pendant l'exécution et de le décoder sur un périphérique mobile.

Heureusement, le framework MonoGame est fourni avec des outils que nous utilisons pour étendre le pipeline de contenu de XNA afin de produire ce dont nous avons besoin. Toutefois, comme il repose sur le framework XNA, cela ne fonctionnera que sous Windows. Vous pouvez créer un « MonoGame Content Project » (Projet de contenu MonoGame) dans Visual Studio 2010, qui créera un projet au contenu XNA classique et un projet XNA qui va, à son tour, construire le contenu du projet. Ces deux projets ont toutes les références nécessaires et les importations de cibles MSBuild pour permettre d'utiliser les processeurs de MonoGame.

Maintenant, lorsque vous ajoutez une nouvelle ressource au contenu du projet et que vous sélectionnez le type de processeur que vous souhaitez utiliser, vous allez voir des processeurs liés à MonoGame : « MonoGame - Effect », « MonoGame - Texture » et ainsi de suite. Ces processeurs effectueront des tâches spécifiques sur les ressources pour les optimiser pour la plateforme cible (voir Figure 2).

Le nouveau projet « Builder » possède plusieurs configurations de construction pour chaque plateforme, donc si vous ciblez l'iPhone, vous pouvez choisir la configuration iOS. Si vous ciblez le Windows Store, choisissez la configuration Windows 8. Les fichiers produits seront placés dans bin\<Configuration>\Release, de sorte que si vous construisez les fichiers pour plusieurs plateformes, vous aurez un répertoire pour chaque plateforme cible. La dernière étape est d'ajouter ces fichiers au répertoire Content de votre projet. Vous pouvez le faire facilement en utilisant la fonctionnalité « Add as Link » (Ajouter comme lien) dans Visual Studio et MonoDevelop. De cette façon, vous pouvez lier un fichier sans avoir à le copier dans le répertoire du projet, ce qui est pratique lorsque vous modifiez le contenu et que vous le compilez avec le « Builder » de contenu, le fichier sera automatiquement récupéré la prochaine fois que vous compilez votre application. Notez que selon la plateforme cible vous devez définir la BuildAction (action de construction) correctement pour vos fichiers ressources afin de les inclure dans le paquet final de l'application.

Si vous souhaitez utiliser des fichiers Effect d'un projet XNA précédent ou d'un échantillon XNA, vous devez les traiter avec le processeur d'effets de MonoGame afin de les compiler pour la plateforme cible. Certaines plateformes utilisent OpenGL au lieu de DirectX comme bibliothèque graphique, donc le fichier Effect de XNA devra être converti dans le langage de shaders d'OpenGL pour fonctionner.

Plutôt que de demander aux développeurs de réécrire leurs shaders en GLSL, MonoGame installe quelques outils pour convertir automatiquement le HLSL du fichier Effect vers le langage de shaders approprié pour la plateforme cible. Pour les plateformes utilisant DirectX, MonoGame utilise la suite d'outils de DirectX 11 pour compiler vos effets en shaders optimisés. Pour les plateformes OpenGL, le fichier Effect est traité par un outil appelé MojoShader, qui effectue une conversion bas niveau du HLSL vers GLSL permettant à votre effet de fonctionner pour cette plateforme.

Bien sûr, le processus de conversion peut occasionnellement introduire des erreurs ou des fonctionnalités non supportées par la plateforme cible. Par exemple, avec OpenGL Shader Model 3.0, vous ne pouvez pas accéder à la texture dans le vertex shader, donc si votre effet utilise cette fonctionnalité, il ne fonctionnera probablement pas. Prenons un échantillon d'un effet provenant des exemples de XNA disponibles sur le site Xbox Creator Club : l'effet d'extraction de bloom est un bon exemple. Bien que ce ne soit qu'un pixel shader, cela vous donnera une bonne idée du genre de choses dont nous devons nous soucier.

// Le Pixel shader extrait les zones claires de l'image.
// C'est la première étape pour appliquer l'effet de bloom.
sampler TextureSampler : register(s0);
float BloomThreshold;
float4 PixelShaderFunction(float2 texCoord : TEXCOORD0) : COLOR0
{
    // Récupère la couleur originale de l'image.
    float4 c = tex2D(TextureSampler, texCoord);
    // Ajustement pour garder seulement les valeurs plus claires que le seuil fixé..
    return saturate((c - BloomThreshold) / (1 - BloomThreshold));
}

technique BloomExtract
{
    pass Pass1
    {
        PixelShader = compile ps_2_0 PixelShaderFunction();
    }
}

Si vous regardez le code de l'effet du listing 1, une des premières choses à noter est que cet effet utilise les pixel shaders 2.0 (ps_2_0). Cela est correct pour DirectX 9, mais pour OpenGL et DirectX 11 cela doit être modifié. Avant de changer le code, il est nécessaire de noter que vous pouvez utiliser des définitions conditionnelles dans les fichiers d'effets pour changer le comportement selon le modèle de shaders ciblé. Si vous ciblez le modèle de shaders 4, vous pouvez utiliser :

#if SM4
// code
#endif

pour gérer ce cas spécial. Ces définitions sont toujours valides lorsque vous utilisez le « Content pipeline » de MonoGame, donc pour faire en sorte que ce shader supporte toutes les plateformes que nous voulons, nous devons mettre à jour la partie technique pour gérer toutes les plateformes cibles. Dans ce cas, nous devons supporter le modèle de shaders 4 pour DirectX 11 et le modèle de shaders 3 pour OpenGL/GLES. Sachant cela, la passe devient :

pass Pass1
{
    #if SM4
        PixelShader = compile ps_4_0_level_9_1 PixelShaderFunction();
    #elif SM3
        PixelShader = compile ps_3_0 PixelShaderFunction();
    #else
        PixelShader = compile ps_2_0 PixelShaderFunction();
    #endif
}

Pour chaque type de modèle de shaders, nous définissons un pixel shader différent. Vous pouvez aussi faire cela avec les vertex shaders, donc une déclaration vs_2_0 deviendra vs_3_0 pour les modèles de shaders 3 et vs_4_0_level_9_1 pour les modèles de shaders 4.

Ensuite, regardons les paramètres passés à la fonction PixelShaderFunction. Dans cet exemple, la fonction ne prend qu'un paramètre, mais afin que cet effet fonctionne correctement avec l'effet SpriteBatch de MonoGame, nous devons ajouter des paramètres supplémentaires. (C'est une limitation de MonoGame qui sera probablement résolue dans le futur.) La bonne nouvelle est que l'ajout de ces paramètres supplémentaires ne casse pas la compatibilité avec XNA, donc, dans ce cas, nous pouvons simplement ajouter les paramètres manquants comme suit :

void PixelShaderFunction( float3 position: POSITION0, float4 color : COLOR0, float2 texCoord : TEXCOORD0)

Dans XNA 3.1, les fonctions PixelShader et VertexShader étaient appelées PixelShader et VertexShader. Cela n'est plus valide en XNA 4.0 ou dans MonoGame, ce qui explique pourquoi, dans le listing 1, nous renommons les fonctions : VertexShaderFunction et PixelShaderFunction. Bien sûr, vous pouvez les nommer comme vous le souhaitez.

Si vous appliquez ces techniques à tous les effets inclus dans l'échantillon de Bloom, le portage du projet pour Windows 8, Android et iOS devient juste une question d'utilisation du constructeur de contenu pour produire les fichiers .xnb pour chaque plateforme cible et ensuite lier ces fichiers à votre projet.

Donc, vous avez un bon jeu sur Xbox 360 ou Windows que vous souhaitez porter sur mobile. Quelles sont les choses dont vous devez vous soucier ? Certains points sont évidents : la taille de l'écran, les commandes et la performance. Voici comment gérer ces détails dans MonoGame.

VII-A. Résolution d'écran▲

var virtualWidth = 800;
var virtualHeight = 600;
var scale = Matrix.CreateScale(
                    (float)GraphicsDevice.Viewport.Width / virtualWidth,
                    (float)GraphicsDevice.Viewport.Height / virtualHeight,
                    1f);

spriteBatch.Begin(SpriteSortMode.Immediate, null, null, null, null, null, scale);
// affichage
spriteBatch.End();

VII-B. Gestion des commandes▲

VII-C. Pousser les performances▲

public class Player
{
  public Vector2 Position;
  public Vector2 Scale;
  public void Update(GameTime gameTime) { … }
  public void Draw(GameTime gameTime) { … }
}

var matrix = Matrix.CreateTransform(Position) * Matrix.CreateScale(Scale);

public class Player
{
  Vector2 position;
  Vector2 scale;
  Matrix matrix;
  
  public Vector2 Position {
    get { return position; }
    set {
      if (position != value) {
        position = value;
        UpdateMatrix();
      }
    }
  }

public Vector2 Scale {
  get { return scale; }
  set {
    if (scale != value) {
      scale = value;
      UpdateMatrix();
    }
  }
}

  public void UpdateMatrix() {
    matrix = Matrix.CreateTransform(Position) * Matrix.CreateScale(Scale);
  }
  public void Update(GameTime gameTime) { … }
  public void Draw(GameTime gameTime) { … }
}

VII-D. Éditeur de liens Android et iOS▲

#if ANDROID

  [Android.Runtime.Preserve(AllMembers=true)]

#elif IOS

  [MonoTouch.Foundation.Preserve(AllMembers=true)]

#endif

public class Example {

  public Example ()
  {
  }
}

Cet article n'a fait qu'effleurer la surface de MonoGame, mais heureusement cela vous motivera pour essayer et peut-être même le rendre meilleur ! Nous avons un certain nombre d'objectifs à l'horizon pour lesquels nous souhaitons être aidés, comme construire un pipeline de contenu multiplateforme, ajouter le support de nouvelles plateformes telles que Windows Phone 8 et Raspberry Pi, utiliser DirectX 11 et étendre XNA. Donc, si vous souhaitez nous aider, rejoignez http://www.monogame.net/.

Merci à Dean Ellis de nous avoir permis de traduire son article.

Merci à Winjerome pour ses corrections et à ClaudeLELOUP et zoom61 pour leur relecture orthographique.