Intermédiaire

BUILD 2015 : Nouveautés autour du développement graphique performant

logo-build

La semaine dernière, s’est déroulée, à San Francisco, la BUILD 2015. Evénement organisé par Microsoft, c’est le rendez-vous annuel pour les développeurs de l’éco-système Microsoft. C’est l’occasion de faire le plein de nouveautés et d’annonces. Pour ma part, je vais essayer, tout au long de cet article, de vous restituer les nouveautés concernant le développement graphique performant.

DirectX

Comme il s’agissait d’un événement Microsoft, je vais commencer par traiter les nouveautés autour de DirectX au sens large, mais on verra dans la suite de l’article qu’il y a aussi beaucoup à dire sur le développement multiplateforme.

Direct3D 12

Si vous avez suivi la deuxième plénière de la BUILD (sinon vous pouvez vous rattraper ici), vous avez sûrement vu passer la démonstration sur DirectX12. Je vous la remet ici, au cas où. Cette démonstration de Square ENIX est plutôt impressionnante (même si elle tourne sur une config que peu de monde possède à la maison). Il faut rappeler également que DirectX 12 est toujours en développement, et que la démo n’est qu’un aperçu du travail en cours de Square ENIX.

En plus de cette démonstration, une session était dédiée à Direct3D 12 lors de cet évènement :

Lors de cette session, Max McCullen, lead développeur dans l’équipe Direct3D, rappelle que DirectX 12 sera disponible uniquement sur Windows 10, et par la même occasion que l’upgrade sera gratuite pendant un an pour les utilisateurs de Windows 7 et 8.x. Il nous informe que les API sont finalisées. C’est à dire qu’il n’y aura pas de nouvelle feature, ils travaillent maintenant sur des optimisations, bug fix, et prise en charge du maximum de périphérique. A ce sujet, il indique qu’actuellement 50% des joueurs possèdent une carte compatible DirectX12. Ils estiment que, cet été, ils arriveront à couvrir 67% du parc. Les développeurs également l’ont adopté rapidement. Il précise même que c’est la version la plus rapidement adoptée depuis la sortie de DirectX 9.

Côté support, la plupart des moteurs de jeux connus (il cite Unity 5 et Unreal 4), supportent désormais la dernière version de DirectX. Visual Studio 2015 et notamment son outils de débogage graphique (dont je parle dans cet article), permet de profiler Direct3D 12.

Côté nouveautés, Max a longuement parlé du rapprochement du matériel en donnant plus de contrôle aux développeurs. Pour rappel, l’année dernière, ils avaient surtout parlé de la réduction de la charge CPU grâce au Pipeline State Object, des Command Bundles, Resources Descriptor Heap, et de la suppression de l’immediate context. La session est diponible ici.

Cette fois-ci, il se concentre sur le MultiAdapter (on comprend mieux les 4 Titan X dans le pc de démonstration de la keynote). En gros, grâce au MultiAdapter, il est possible d’utiliser le potentiel de plusieurs GPU.

Il y a deux modes de MultiAdapter. On pourra utiliser le mode Implicit (celui utilisé par la démo de Square ENIX) pour dire au driver que l’on ne veut pas s’en occuper et il le gérera donc tout seul, en s’appuyant sur SLI et CrossFire. Le mode Explicit, quand à lui, permet au développeur d’adresser le GPU qu’il souhaite, d’allouer une ressource sur un GPU en particulier (et de les synchroniser si besoin) et de faire exécuter des commandes à un GPU en particulier.

Il y a deux cas dans le mode Explicit. Tout d’abord celui des Linked GPU, les cartes graphiques viennent du même vendeur et leurs spécifications sont proches, alors on ne verra qu’un seul GPU avec différentes zones mémoires et plusieurs processeurs de commandes. Max ne s’est pas attardé sur cette partie. Il a surtout parlé de l’autre cas, les Unlinked GPU. Dans ce cas, les cartes graphiques ne sont pas forcément du même vendeur et de la même puissance. On peut, par exemple, imaginer de calculer la scène 3D sur la carte graphique dédiée et de calculer l’interface utilisateur à la carte graphique intégrée à la carte mère. Ou encore de laisser le GPU intégré s’occuper des tâches de post processing. Voici la timeline d’une démo présentée tournant avec Unreal engine 4 et qui utilise le GPU intégré pour le postprocessing :

microsoft-dx12-build15-ue4frame

Si vous avez envie de lire un peu plus de détails sur Direct3D 12, Microsoft a mis en ligne une version préliminaire de la documentation de Direct3D12. Je reviendrai bientôt avec des articles détaillés sur DirectX12.

Direct2D & DirectWrite

Au niveau de Direct2D et DirectWrite dans Windows 10, il y a également des nouveautés intéressantes. Anthony Hodsdon, développeur dans l’équipe Windows Graphics a animé une session pour nous en faire un tour d’horizon.

Commençons par DirectWrite, la brique de DirectX qui permet d’afficher et de manipuler graphiquement du texte. Dans Windows 10, il y a désormais deux types de police de caractères. Les « recommandées », qui seront présentes sur tous les périphériques tournant sous Windows 10, et les « optionelles », qui seront téléchargées à la demande d’une application. Ce chargement se fera de manière asynchrone. Tant qu’il ne sera pas terminé, une police de caractères « recommandée » choisie sera affichée à la place. Ces polices de caractères sont stockées dans un cache global. Il sera donc possible pour une autre application d’utiliser cette police sans avoir besoin de la retélécharger.

DirectWrite apporte également les FontSets. Un objet qui permet d’énumérer les polices de caractères disponibles sur le périphérique, il vient en complément des FontCollections (d’ailleurs les deux types sont intéropérables). Il apporte principalement de nouveaux filtres de recherche et également une meilleure gestion des polices « optionnelles ». Voici un tableau comparatif entre la FontCollection et le FontSet :

IDWriteFontCollection IDWriteFontSet
Critères de filtre Nom de la famille Nom de la famille;
Nom PostScript;
Langage;
Poids;…
Ensemble personnalisé Implémentation d’une interface de rappel Modèle simplifié
Choix d’une police Locale et téléchargeable Locale et téléchargeable
Requête sur les metadonnées Seulement locale Locale et téléchargeable

Direct2D a également son lot de nouveautés. Tout d’abord, le chargement des images YCbCr est largement simplifié, grâce au type ID2D1ImageSource. Le comparatif dans la session démontre bien la simplification. Le code d’origine (que je ne mettrai pas ici car il prendrait trop de place), tient sur trois slides séparés chacun en deux colonnes. Alors que désormais pour charger une image au format YCbCr il suffit de faire :

// Chargement
m_spD2DFactory->CreateImageSourceFromWic(
        spWicBitmapSource,
        loadingOptions,
        alphaMode,
        &m_spImageSource);

//[...]

// Rendu 
m_spDrawingContext->DrawImage(m_spImageSource);

Au niveau des effets, ils en ont ajouté beaucoup d’intégrés :

Filtre Edge Detection
Transparence Chroma key
Style Emboss
Posterize
Couleur HueToRgb
RgbToHue
Lookup Table 3D
Photo Contrast
Exposure
Grayscale
Highlights and Shadow
Invert
Sepia
Sharpen
Straighten
Temperature and Tint
Vignette

Et ils sont tous optimisés grâce au Shader Linking. Mais qu’est-ce donc ? Sur Windows 8.1, quand plusieurs effets étaient combinés pour rendre un effet plus complexe, chaque effet correspondait à une passe de rendu. Sur Windows 10, Direct2D essaie au maximum de combiner les effets dans une même passe de rendu . Si vous voulez intégrer le Shader Linking dans un effet personnalisé, il vous suffira de suivre la procédure suivante.

Toujours avec Direct2D, il est maintenant possible pour d’utiliser les Gradient Mesh pour définir un dégradé, ce qu’il laisse plus de souplesse dans sa définition. Par exemple, pour rendre ça :
gradientmesh

Voilà comment déclarer le Gradient mesh :

D2D1_GRADIENT_MESH_PATCH patchList[1];

patchList[0] = D2D1::GradientMeshPatch(
    D2D1::Point2F(-210, 90),            // Point00 (bottom left corner)
    D2D1::Point2F(-150, 30),            // Point01
    D2D1::Point2F(-90, 150),            // Point02
    D2D1::Point2F(-30, 90),             // Point03 (bottom right corner)
    D2D1::Point2F(-190, 30),            // Point10
    D2D1::Point2F(-130, 30),            // Point11
    D2D1::Point2F(-70, 30),             // Point12
    D2D1::Point2F(-10, 30),             // Point13
    D2D1::Point2F(-170, -30),           // Point20
    D2D1::Point2F(-110, -30),           // Point21
    D2D1::Point2F(-50, -30),            // Point22
    D2D1::Point2F(10, -30),             // Point23
    D2D1::Point2F(-150, -90),           // Point30 (upper left corner)
    D2D1::Point2F(-90, -150),           // Point31
    D2D1::Point2F(-30, -30),            // Point32
    D2D1::Point2F(30, -90),             // Point33 (upper right corner)
    D2D1::ColorF(D2D1::ColorF::Black),  // Color00 (bottom left corner)
    D2D1::ColorF(D2D1::ColorF::Blue),   // Color03 (bottom right corner)
    D2D1::ColorF(D2D1::ColorF::Red),    // Color30 (upper left corner)
    D2D1::ColorF(D2D1::ColorF::Purple), // Color33 (upper right corner)
    D2D1_PATCH_EDGE_MODE_ANTIALIASED,   // Top edge is a boundary of the mesh
    D2D1_PATCH_EDGE_MODE_ANTIALIASED,   // Left edge is a boundary of the mesh
    D2D1_PATCH_EDGE_MODE_ANTIALIASED,   // Bottom edge is a boundary of the mesh
    D2D1_PATCH_EDGE_MODE_ALIASED        // Right edge is internal to the mesh
);

 m_deviceResources->GetD2DDeviceContext()->CreateGradientMesh(
            patchList,
            ARRAYSIZE(patchList),
            &m_gradientMesh
            );

Win2D

Simon Tao, Program Manager dans l’équipe Windows Graphics est venu présenter Win2D. Si vous ne connaissez pas Win2D, c’est une nouvelle librairie open source développée par Microsoft, dont le but est de simplifier l’utilisation de Direct2D et DirectWrite, tout en gardant leur puissance. Avec Win2D, on peut donc dessiner des géométries 2D, du texte, des images, des effets d’images. Win2D est accessible depuis C++ et C#. Il est utilisable pour les projets Win(Phone)8.1 et Windows 10.

Le projet étant open-source et l’équipe de développement ayant opté pour des méthodologies agile, il n’y avait pas de grande nouveauté à annoncer lors de cette BUILD, mais je vous conseille de regarder la vidéo de la session pour vous rendre compte du potentiel de cette librairie.

Si le projet vous intéresse, vous pouvez également suivre l’évolution du projet via le blog et le github.

Quand on voit à quelle vitesse elle a évoluée depuis septembre 2014, je pense qu’elle nous réserve encore de grosses surprises tout au long de cette année.

Développement multiplateforme

Même s’il s’agissait d’un évènement Microsoft, il y avait également des sessions sur le multiplateforme. Cet article se concentrant sur le développement graphique, j’ai donc décidé de vous parler du développement mobile multiplateforme en C++, du projet ANGLE, et d’Unity 5.

Développement mobile multiplateforme grâce à C++

Une session, animée par Ankit Asthana, faisait la présentation de Visual C++ Cross-Platform Mobile, un complément optionnel que le peut installer avec Visual Studio. Ce complément ajoutera la possibilité de créer des projets en C++ pour Android et pour iOS.

Au début de la session, Ankit Asthana, nous informe que, dans le top 50 des apps/jeux android sur marché américain, 80% sont réalisés avec du code C++. Il prend également l’exemple des applications office dont 90% du code est écrit en C++. Ce langage étant le dénominateur commun aux trois plateformes, il pourrait servir, par exemple, pour mutualiser la logique d’une application.

Pour Android, il est possible de choisir CLANG ou GCC pour la compilation, tandis que pour iOS il faudra un XCode en remote. Ce qui est intéressant également, c’est que tout est intégré à Visual Studio : on pourra donc bénéficier d’IntelliSense, de l’expérience de débogage, et on reste en terrain connu.

Ce qui va nous intéresser le plus dans notre cas, c’est la possibilité d’appeler OpenGL ES 2.0. Il est donc possible de faire un jeu en C++ et OpenGL pour Android et iOS en partageant une grande partie du code. Et là où ça devient encore plus intéressant, c’est qu’avec le projet ANGLE (dont je parle juste après), il sera également possible de le partager pour Windows.

Project ANGLE

Le projet ANGLE a été initié par Google en 2010. Le but du projet était d’apporter la compatibilité avec OpenGL pour les applications Win32. Il est notamment utilisé dans Chromium, Google Chrome, Firefox, principalement pour le support de WebGL. Sa particularité est de transformer les ordres OpenGL en Direct3D. Ce choix a été fait car, aux niveaux des drivers, Direct3D est beaucoup plus supporté. Microsoft a ensuite rejoint le projet en 2013. Leur arrivée a permis de rajouter le support de Windows Phone 8.1 ainsi que des applications Windows Store, et également de diminuer les prérequis matériel demandé.

Dans le contexte des applications Windows Store, ANGLE peut aussi bien fonctionner avec les CoreWindow que le contrôle SwapChainPanel de XAML. On peut donc tout à fait combiner de l’OpenGL ES 2.0 avec du XAML. D’une manière macro, ANGLE passe par les trois étapes suivantes pour effectuer le rendu : angle

Si vous avez des compétences OpenGL et que vous souhaitez développer un jeu ou une application avec des graphismes riches, le projet ANGLE semble donc un choix tout à fait judicieux. D’ailleurs, King est intervenu pendant la session pour faire un retour d’expérience. Comme ils ont une grosse partie de leur code en C++/OpenGL, le portage de Candy Crush sur Windows Phone a été très simplifié grâce à ANGLE.

Si le projet vous intéresse, vous pouvez aller sur le site du projet. Vous pouvez également avoir les sources de la version de Microsoft. Il y une version spécifique pour Windows 8.0, c’est ici. Et enfin si vous voulez avoir plus d’informations sur l’implémentation dans une application Windows store, rendez-vous sur son wiki !

Unity 5

Au niveau d’Unity, la seule nouveauté annoncée a été faite sur le blog de l’éditeur. Il s’agit du support de Hololens, les lunettes de réalité augmentée de Microsoft. Pour plus d’informations sur le produit, un site lui est dédié.

Mais de toutes façons, ce n’était pas à la BUILD que l’on attendait forcément des nouveautés de ce produit. Adam Tuliper, évangéliste technique chez Microsoft, est tout de même venu nous montrer, au cours d’une session, comment développer un jeu UWP, avec Unity 5.

Il a commencé par rappeler qu’UnityVS a été racheté l’année dernière par Microsoft et qu’il est désormais gratuit. Vous pouvez le télécharger ici. UnityVS, si vous ne le connaissez pas, est un plugin qui permet d’utiliser Visual Studio pour écrire les scripts et les shaders des projets Unity. On peut également, grâce à lui, profiter du débugger de Visual Studio. Pour ce faire, il vous faudra au minimum Visual Studio 2013 CTP5. L’outil de débogage graphique de Visual Studio est également utilisable.

Au fil de la session, Adam Tuliper montre quelques étapes de la création d’un jeu avec Unity. Si vous débutez avec Unity, je vous conseille fortement d’aller dans la partie tutoriel de leur site, elle est très complète. Une fois le jeu créé, il passe ensuite à la partie export, vers un projet Visual studio. Il nous montre que, dans l’onglet Windows Store, dans la combo pour choisir la version, on peut désormais choisir UAP. Après l’export, on a donc un projet de type UAP qui est généré pour Visual Studio. Une particularité : il y a 3 configurations de solutions au lieu des 2 habituelles par défaut :
Debug : pas optimisé, comme son nom l’indique c’est pour le débug
Release : optimisé, mais supporte encore le profiling
Master : optimisé et ne supporte plus le profiling (la version pour la publication)

Comme il s’agit d’un projet UAP qui pourra être publié sur de nombreux périphériques différents, Adam fait également une démo d’Unity UI, avec lequel il est relativement simple d’adapter l’interface utilisateur en fonction de la résolution et du ratio du conteneur du jeu.

Et il poursuit sur le partage de code. Pour écrire du code spécifique à une plateforme – il prend l’exemple de l’in-app purchase – il suffit d’utiliser les directives de pré-compilations:

#if !UNITY_EDITOR && WINDOWS_UAP
            // Code spécifique pour Windows
#endif

Il parle ensuite du nouveau modèle de plugin Unity. Il fait une démonstration, en créant un plugin UAP dans Visual Studio. Il crée d’abord un projet type bibliothèque de classes UAP, et ensuite il en crée un autre de type bibliothèque de classe .NET. Le premier sera celui embarqué dans le projet final qui sera publié sur le Store, et le second sera utilisé par Unity quand on sera dans l’éditeur. Il partage le code de son plugin en utilisant la fonctionnalité « ajouter en tant que lien », qui permet de partage le même fichier de code entre des projets différents. Il aurait pu également passer un « Shared Project ».

Il finit sa session en annonçant que la version d’Unity 5.2 arrivera dans les prochains mois, et que les possesseurs d’une licence pro peuvent déjà participer à la Beta de cette version.

Si vous avez envie de vous faire une idée d’Unity 5, une version gratuite existe.

Conclusion

Comme vous avez pu le constater, le panel d’outils pour faire des jeux ou applications avec des graphismes riches est très complet. De plus, je n’ai abordé ici que les outils qui ont été traités lors de la BUILD et il en existe d’autres. Je reviendrai prochainement avec des articles sur DirectX12 principalement. J’espère que ce tour d’horizon vous aura plu et qu’il vous aura été utile. Je vous dis à très bientôt !

Nombre de vue : 83

AJOUTER UN COMMENTAIRE