tag:linuxfr.org,2005:/tags/sdl/publicLinuxFr.org : les contenus étiquetés avec « sdl »2022-04-22T14:43:29+02:00/favicon.pngtag:linuxfr.org,2005:Bookmark/45852022-04-21T20:45:03+02:002022-04-21T20:45:03+02:00SDL2 Reverts Its Wayland Preference - Goes Back To X11 Default - phoronix<a href="https://www.phoronix.com/scan.php?page=news_item&px=SDL2-Reverts-Wayland-Default">https://www.phoronix.com/scan.php?page=news_item&px=SDL2-Reverts-Wayland-Default</a> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/127535/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/antistress/liens/sdl2-reverts-its-wayland-preference-goes-back-to-x11-default-phoronix#comments">ouvrir dans le navigateur</a>
</p>
antistresshttps://linuxfr.org/nodes/127535/comments.atomtag:linuxfr.org,2005:Bookmark/42052022-01-27T20:01:45+01:002022-01-27T20:01:45+01:00SDL2 On Linux Now Prefers Wayland Over X11 - phoronix<a href="https://www.phoronix.com/scan.php?page=news_item&px=SDL2-Prefers-Wayland">https://www.phoronix.com/scan.php?page=news_item&px=SDL2-Prefers-Wayland</a> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/126723/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/antistress/liens/sdl2-on-linux-now-prefers-wayland-over-x11-phoronix#comments">ouvrir dans le navigateur</a>
</p>
antistresshttps://linuxfr.org/nodes/126723/comments.atomtag:linuxfr.org,2005:News/374472016-07-19T09:26:44+02:002016-07-19T09:26:44+02:00SDL ou SFML ? Ne choisissez plus, prenez Gamedev Framework (gf)Licence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<div><p>Gamedev Framework (gf) est un framework de développement de jeu vidéo 2D en C++11. Il est basé sur <a href="https://www.libsdl.org/">SDL</a> et <a href="https://www.khronos.org/opengles/2_X/">OpenGL ES 2.0</a> et s'inspire très largement de l'API du module graphique de <a href="http://www.sfml-dev.org/">SFML</a> avec quelques différences mineures et surtout en ajoutant des fonctionnalités non-présentes dans SFML.</p>
<p>La première version publique 0.1.0 de ce framework est sortie le 14 juillet 2016.</p>
<p><img src="//img.linuxfr.org/img/68747470733a2f2f7261772e67697468756275736572636f6e74656e742e636f6d2f47616d656465764672616d65776f726b2f67662f6d61737465722f67665f6c6f676f2e706e67/gf_logo.png" alt="Logo de gf" title="Source : https://raw.githubusercontent.com/GamedevFramework/gf/master/gf_logo.png"></p>
<p>Gamedev Framework (gf) est publié sous <a href="https://opensource.org/licenses/Zlib">licence zlib/libpng</a>, identique à celle de SDL et SFML.</p></div><ul><li>lien nᵒ 1 : <a title="http://gamedevframework.github.io/" hreflang="en" href="https://linuxfr.org/redirect/97767">Documentation de gf</a></li><li>lien nᵒ 2 : <a title="https://github.com/GamedevFramework/gf" hreflang="en" href="https://linuxfr.org/redirect/97768">Code source sur github</a></li></ul><div><h2 class="sommaire">Sommaire</h2>
<ul class="toc">
<li><a href="#pourquoi-et-comment">Pourquoi et comment ?</a></li>
<li><a href="#opengl-et-fen%C3%AAtrage">OpenGL et fenêtrage</a></li>
<li><a href="#opengl-moderne">OpenGL moderne</a></li>
<li><a href="#choix-de-lapi">Choix de l'API</a></li>
<li><a href="#portabilit%C3%A9-windows">Portabilité windows</a></li>
<li><a href="#int%C3%A9gration-continue">Intégration continue</a></li>
<li><a href="#documentation">Documentation</a></li>
<li><a href="#et-maintenant">Et maintenant ?</a></li>
</ul><p>Dans cette deuxième partie, je vais vous raconter l'histoire de gf, d'où je suis parti et comment j'en suis arrivé à aujourd'hui. Je ne vais pas vous présenter l'API ou les fonctionnalités. Peut-être dans une prochaine dépêche, quand la bibliothèque aura bien mûri. Vous pouvez déjà avoir un aperçu avec la documentation.</p>
<h2 id="pourquoi-et-comment">Pourquoi et comment ?</h2>
<p>Pourquoi avoir fait ce framework ? Dès qu'on veut faire un jeu en C++ sans moteur de jeu complet, on se retrouve très vite face à deux choix : SDL ou SFML. C'est une <a href="https://www.reddit.com/r/gamedev/comments/44npzz/sdl20_vs_sfml2_in_2016/">question récurrente</a> que j'avais <a href="//linuxfr.org/users/rewind/journaux/sdl2-ou-sfml2-ou">déjà posée</a> en 2013, à l'heure où je commençais Akagoria.</p>
<p>Les arguments sont bien connus : SDL est écrite en C, est très portable, avec des API robustes et bien faites, mais assez bas niveau. Il y a bien quelques fonctions pour afficher des choses mais ça reste assez limité. En revanche, SDL est souvent utilisée pour obtenir un contexte OpenGL et la gestion des événements utilisateurs et ensuite, on peut utiliser directement OpenGL. De son côté, SFML est écrite en C++, est un peu plus haut niveau et est surtout assez adapté quand on débute parce qu'elle offre de très bonnes abstractions.</p>
<p>Depuis le début, j'avais choisi SFML pour Akagoria. L'idée de gf est venue des limitations de SFML. Depuis quelques temps, que ce soit pour Akagoria ou pour des <em>game jams</em>, je me retrouvais à devoir refaire quelques classes de bases, toujours les mêmes. J'en ai fait un projet à part : <a href="https://github.com/jube/gameskel">gameskel</a>. Pour certaines parties, l'intégration avec SFML était assez pénible. Par exemple, j'avais des classes pour avoir des <a href="http://www.sfml-dev.org/tutorials/2.3/graphics-view.php">vues</a> qui s'adaptent automatiquement au redimensionnement de la fenêtre. Mais impossible de faire uniquement des classes dérivées de <code>sf::View</code>, ce qui aurait été le plus logique et le plus simple. Du coup, j'étais obligé dans certains cas de faire des contorsions pour arriver à faire ce que je voulais. C'était de plus en plus compliqué.</p>
<p>Le déclic est venu quand j'ai parcouru le <a href="http://en.sfml-dev.org/forums/index.php?board=2.0">forum de SFML</a> à propos des nouvelles fonctionnalités. J'ai été complètement ahuri de voir le conservatisme de certains développeurs de SFML. La moindre demande de fonctionnalité est quasi-systématiquement rejetée, y compris des fonctionnalités complètement triviales, avec des arguments limite fallacieux. Par exemple, un utilisateur demande <a href="http://en.sfml-dev.org/forums/index.php?topic=20176.0">l'ajout d'un <code>sf::Line</code></a> pour tracer une ligne entre deux points. Les réponses qu'il obtient, c'est qu'il devrait utiliser <code>sf::Rectangle</code> (pas super simple) ou alors recopier <a href="https://github.com/SFML/SFML/wiki/Source%3A-Line-segment-with-thickness">le bout de code</a> qui se trouve sur le wiki ou alors utiliser une bibliothèque externe d'un des développeurs de SFML qui contient une ligne. Il y a aussi cet autre utilisateur qui <a href="http://en.sfml-dev.org/forums/index.php?topic=20052.0">demande à avoir une surcharge de la fonction <code>scale()</code></a> qui prend normalement deux paramètres: un pour <code>x</code>, un pour <code>y</code>. Sauf que dans 95% des cas, c'est le même paramètre (par exemple, quand on zoome ou qu'on dézoome). Le bout de code à ajouter fait littéralement 3 lignes. Mais non, on lui répond qu'on ne va pas ajouter ce cas trivial. Et il y en a des dizaines comme ça dans le forum. Et puis, il y a ce refrain qui revient comme quoi SFML ne serait qu'un framework multimedia et pas une bibliothèque pour développer des jeux (même si ça représente la quasi-totalité des cas d'utilisation).</p>
<p>À partir de là, je me suis dit que j'allais laisser tomber SFML.</p>
<h2 id="opengl-et-fenêtrage">OpenGL et fenêtrage</h2>
<p>Ça tombe bien, j'avais envie de m'intéresser à OpenGL. Le choix a donc été vite fait pour ce qui concerne l'API graphique. Après, j'ai un peu tâtonné avant de me décider. En effet, OpenGL seul est inutilisable, il faut avoir un contexte OpenGL et pour ça, il n'y a pas d'API standard, chaque système a sa manière propre de créer un contexte. Sans compter qu'au delà du contexte, il y a toute la gestion des fenêtres et des entrées utilisateurs (clavier, souris, etc).</p>
<p>Là, on a plusieurs solutions. La première, c'est de réinventer la roue carrée, comme SFML et de recoder toute cette couche à la main. Autant dire que cette solution a été très vite évacuée parce que quand je vois la quantité et la complexité du code qu'il y a dans SFML juste pour cette partie, je me dis que c'est un boulot à part entière. Donc, je suis plutôt parti sur une bibliothèque qui fait déjà le boulot.</p>
<p>Mon premier choix s'est porté sur <a href="http://www.glfw.org/">GLFW</a> qui est une bibliothèque portable qui gère toute la partie fenêtre et entrée, et crée un contexte OpenGL. J'ai commencé et j'avais fait pas mal de trucs, ça marchait. Et puis, j'ai arrêté pour une raison simple : la gestion des manettes de jeu. Cette gestion est très aléatoire, dans le sens où pour chaque manette, la correspondance entre les touches et les identifiants ne sont jamais les mêmes.</p>
<p>Mon second choix a alors été SDL. De la même manière, SDL gère toute la partie fenêtre et entrée et crée un contexte OpenGL. De plus, SDL est connue pour avoir une très bonne gestion des manettes. J'ai donc repris une bonne partie de ce que j'avais déjà fait et j'ai tout porté vers SDL. En fait, SDL est beaucoup plus simple à utiliser. GLFW est basée sur des <a href="https://fr.wikipedia.org/wiki/Fonction_de_rappel">fonctions de rappel</a> pour gérer les entrées utilisateurs et c'est assez pénible.</p>
<p>Au final, je ne regrette absolument pas le choix de SDL, bien au contraire.</p>
<h2 id="opengl-moderne">OpenGL moderne</h2>
<p>Après avoir un contexte OpenGL, il faut utiliser l'API. Mais quelle version ? Mon choix s'est portée sur OpenGL ES 2.0. Pourquoi ?</p>
<p>OpenGL ES 2.0 est une API plutôt vieille (elle date de 2007) et elle est présente quasiment partout des ordinateurs de bureau aux derniers ordiphones. OpenGL ES 3.0 à l'inverse est un peu trop récente (2012). De plus, WebGL est basée sur OpenGL ES 2.0, donc dès qu'on a un navigateur qui gère WebGL, on a un pilote capable de gérer OpenGL ES 2.0, ce qui fait beaucoup de matériel. Ensuite, OpenGL ES 2.0 est la version moderne d'OpenGL, celle où tout passe par un shader. Enfin, pour nous les libristes, Mesa3D prend en charge OpenGL ES 2.0 depuis Mesa 8.0 en 2012 donc même sur une Debian stable, on a ce qu'il faut en terme de pilote.</p>
<p>Alors certes, il manque des fonctionnalités à OpenGL ES 2.0 mais pour faire de la 2D, ça suffit amplement. Et puis, je préfère exploiter complètement la petite API d'OpenGL ES 2.0 plutôt que d'utiliser 50% d'une API plus évoluée. Voici quelques pointeurs vers de la documentation qui m'a été bien utile pour comprendre comment fonctionne OpenGL et la bonne manière de programmer avec OpenGL.</p>
<ul>
<li><a href="https://open.gl/">OpenGL tutorials (open.gl)</a></li>
<li><a href="http://learnopengl.com/">OpenGL tutorials (learnopengl.com)</a></li>
<li><a href="http://docs.gl/">OpenGL API documentation (docs.gl)</a></li>
</ul><h2 id="choix-de-lapi">Choix de l'API</h2>
<p>Plutôt que de réinventer une API, je suis très vite parti dans l'idée de cloner autant que faire se peut l'API de SFML. Les avantages, c'est qu'il n'y a pas besoin de réfléchir beaucoup au design de l'API, et que pour ceux qui voudraient passer de SFML à gf, l'effort sera très minime (remplacer <code>sf</code> par <code>gf</code>).</p>
<p>L'adaptation n'a pas toujours été de tout repos. SFML utilise de l'OpenGL à papa, c'est-à-dire sans aucun shader. Et donc, il a fallu mettre en place tout l'attirail de base quasiment de zéro. Pour ceux qui se demandent où ça se situe, c'est dans la fonction <a href="https://github.com/GamedevFramework/gf/blob/master/library/RenderTarget.cc#L134"><code>gf::RenderTarget::draw()</code></a>. Après cette base, beaucoup de choses étaient semblables et j'ai repris pas mal de code de SFML en modernisant un peu le code (notamment en profitant du fait d'utiliser C++11).</p>
<p>Une des principales différences avec SFML est l'ajout des classes <code>Vector</code> et <code>Matrix</code> complètement génériques. Je me suis inspiré d'un <a href="http://www.reedbeta.com/blog/2013/12/28/on-vector-math-libraries/">article de Nathan Reed</a> de 2013 qui explique un design à peu près standard pour ce genre de classes. J'ai ajouté tout un tas de fonctions classiques liées à ces classes (souvent des fonctions dont j'avais directement besoin dans la bibliothèque ou que j'avais déjà utilisées par ailleurs). Au final, le fichier <a href="https://github.com/GamedevFramework/gf/blob/master/include/gf/Vector.h"><code>Vector.h</code></a> est un des plus gros fichiers : plus de 1600 lignes.</p>
<h2 id="portabilité-windows">Portabilité windows</h2>
<p>Un challenge que je me suis fixé était la portabilité sur Windows, et plus précisément avec MSVC. En effet, si je veux que ma bibliothèque puisse être utilisée le plus largement possible, il est nécessaire qu'elle soit utilisable sur Windows via Visual Studio. Après un gros effort d'adaptation du code, je n'aurai qu'un constat : quelle plaie !</p>
<p>Il faut être clair <a href="https://www.reddit.com/r/cpp/comments/4r8n41/what_are_some_reasons_why_visual_studio_seems_so/">Visual Studio et son compilateur sont autant aimés que détestés</a>. Et comme la dernière mouture de Visual Studio (2015) a une version Community gratuite, je me suis lancé. Personnellement, je trouve que le compilateur est mauvais. Pourtant, les développeurs ont annoncé une meilleure prise en charge de C++11, mais dans les faits, ils sont clairement à la traîne. Voici quelques adaptations que j'ai dû faire et que je n'aurais pas dû faire parce que le code d'origine était du code C++11 valide.</p>
<p>La première adaptation, c'est un truc que j'ai mis deux jours à comprendre. Ça se passe au niveau des constructeurs par copie et par déplacement qui sont générés implicitement (ou pas). J'avais dans ma classe un membre de type <code>std::vector<std::unique_ptr<Foo>></code>. Or, il n'est pas possible de copier ce membre puisqu'il n'est pas possible de copier un <code>std::unique_ptr</code>. Donc, dans ce cas, normalement, le compilateur ne doit pas générer implicitement de constructeur par copie (puisqu'il ne peut pas le faire). Or, MSVC lui le génère. Sauf qu'après, et bien il essaie de l'utiliser et forcément, il sort une erreur : pas de le droit de recopier. L'astuce ici consiste à supprimer explicitement le constructeur par copie (alors que ça ne devrait pas être nécessaire). Deux jours sur cette connerie !</p>
<p>Ensuite, MSVC est connu pour très mal gérer les templates. En effet, <a href="http://stackoverflow.com/questions/6273176/what-exactly-is-broken-with-microsoft-visual-cs-two-phase-template-instanti">il ne fait pas ce qu'on appelle le «two-phase lookup»</a>, ce qui a plein de conséquences très désagréables. Mais dans mon cas, il a très mal géré ce qu'on appelle par le doux nom de <a href="http://en.cppreference.com/w/cpp/language/sfinae">SFINAE</a>, «Substitution Failure Is Not An Error». En gros, on définit une série de templates et à l'instanciation, le compilateur va essayer toute la série en substituant le type en paramètre par le type réel pour trouver le bon appel. Si le compilateur n'arrive pas à instancier correctement un des templates, ce n'est pas considéré comme une erreur, c'est juste que le type réel n'est pas adapté et donc ce template est éliminé de la liste des appels possibles. Avec MSVC, patatras, on obtient une erreur. Il instancie, ça ne marche pas, mais non, il considère que c'est une erreur. Du coup, il a fallu forcer l'élimination à grand coup de <a href="http://en.cppreference.com/w/cpp/types/enable_if"><code>std::enable_if</code></a> complétement superflus.</p>
<p>Dernier exemple, l'instanciation explicite de template. Avant C++11, quand on avait des classes templates, on pouvait instancier explicitement dans le code source (histoire de générer tout le code à un endroit) mais on ne pouvait pas dire qu'on avait instancié explicitement. Et donc, au final, ça ne servait pas à grand chose. En C++11, cette fonctionnalité a été ajoutée, ça s'appelle <code>extern template</code>. Sauf que pour MSVC, ça ne marche pas bien. Ça ne se marie pas très bien avec les <code>dllimport</code>/<code>dllexport</code> qu'on doit ajouter juste pour MSVC. Et du coup, j'ai fait pareil que dans le <a href="https://chromium.googlesource.com/chromium/src/base/+/master/strings/string_piece.h#370">code de Chromium</a>, j'ai désactivé les instanciations explicites pour MSVC (et il le vit bien).</p>
<p>Alors ouais, on pourrait me dire que ce sont des cas très particuliers. Mais je ne pense pas avoir fait du code très complexe. J'ai quand même passé une bonne semaine, je pense, à comprendre et corriger toutes les erreurs de compilation de MSVC. J'ai laissé de côté les avertissements (plus de 2000 !).</p>
<p>Un truc assez pénible à gérer avec Windows, c'est qu'il n'y a pas de paquets. Il faut donc tout installer à la main et ensuite, prier pour que ça fonctionne correctement. En particulier quand on utilise CMake. En définissant les bonnes variables d'environnement, on arrive presque à s'en sortir. Mais il reste que trouver les paquets binaires de bibliothèques assez communes est parfois compliqué. Par exemple, pour Freetype, le seul paquet binaire à disposition est en <a href="http://gnuwin32.sourceforge.net/packages/freetype.htm">version 2.3.5</a> (qui date de 2007) alors que Freetype en est à la version 2.6.5. Ça pique.</p>
<h2 id="intégration-continue">Intégration continue</h2>
<p>C'est la mode, il faut faire de l'intégration continue. Et puis, comme j'avais confiance dans mon code, j'ai tenté le coup.</p>
<p>Dans le monde libre, il existe <a href="https://travis-ci.org/">Travis-CI</a> qui permet à n'importe quel projet libre hébergé sur GitHub de profiter de l'infrastructure et de faire de l'intégration continue. J'avais déjà pu essayer ce service sur un autre projet donc je n'étais pas en terre inconnue. Sauf que depuis que je l'ai testé il y a quelques années, il n'a pas beaucoup évolué, et c'est bien le problème ! Proposer par défaut en 2016 une Ubuntu 12.04 (donc sorti en 2012), même Debian est à la pointe en comparaison. Ha oui, on peut utiliser une Ubuntu 14.04, mais c'est du bêta… Quel est le problème ? He bien les version de paquets ne sont pas du tout à jour. Chez moi, j'ai une Debian stable, ça m'a posé un problème parce qu'il n'y a pas SDL 2.0.4 mais uniquement SDL 2.0.2 (il manque quelques fonctions sympathiques). Mais là, on est sur une autre planète : sur Ubuntu 12.04, il n'y a même pas SDL2, uniquement SDL1. Du coup, j'ai quand même forcé l'utilisation d'Ubuntu 14.04.</p>
<p>Ensuite, il y a eu le problème des versions des compilateurs par défaut. Sur une Ubuntu 14.04, on a droit à GCC 4.8.4… qui ne gère pas complètement C++11. Heureusement, Travis-CI permet d'installer des paquet provenant de ppa, et notamment des paquets de compilateurs récents. Pour GCC, aucun problème. Mais pour Clang, il y avait un problème de vérification et donc impossible d'installer les dernières versions. Pas de souci, Clang 3.5 gère C++11 donc ça passe quand même. Et donc, j'ai trois configurations: GCC 4.9, GCC 5, Clang 3.5. Mais il faut croire que ce <a href="https://github.com/travis-ci/travis-ci/issues/6300">problème de vieux compilateurs</a> ne gêne pas que moi.</p>
<p>Après ça, je me suis intéressé à <a href="https://www.appveyor.com/">AppVeyor</a> qui est la même chose que Travis-CI mais pour le système Windows. Là, l'infrastructure est plus récente donc pas plus de souci qu'avec mon Visual Studio local. Mais on se retrouve avec le problème des paquets binaires. Parce que là, ça devient funky : il faut, dans le script appelé par l'instance AppVeyor qui va compiler le code, télécharger les paquets binaires et les décompresser et mettre en place toutes les variables d'environnement qui vont bien et appeler CMake. Et surtout invoquer l'esprit de Turing pour que tout fonctionne de manière déterministe. Et après quelques hésitations, ça fonctionne !</p>
<p>Au final, ça vaut quand même le coup de passer du temps à tout bien configurer. Ça permet d'avoir un <code>CMakeLists.txt</code> à peu près portable, d'être sûr qu'on n'introduit pas de régression fatale, d'avoir une recette pour construire la bibliothèque. Et puis, on peut afficher de beaux petits badges pour montrer qu'on a bien fait son boulot.</p>
<h2 id="documentation">Documentation</h2>
<p>Dernier point que j'aimerais aborder : la documentation. C'est long ! Je pense qu'au final, j'ai dû passer à peu près un tiers du temps total sur l'écriture de la documentation. Déjà, il y a la documentation Doxygen du code. Certes, ça ne suffit pas mais c'est quand même nécessaire. Là aussi, vu que j'ai cloné l'API de SFML, j'ai également cloné une bonne partie de la documentation Doxygen. Maintenant, je ne souhaite pas aller plus loin dans le clonage, en particulier, je pense que je ne clonerai pas les tutoriels de SFML qui sont pourtant d'excellente qualité. J'ai donc entrepris de compléter la documentation Doxygen par des petits articles sur des ensembles de classes. Ce n'est pas fini mais ça avance petit à petit. L'idée, c'est aussi de commencer par faire des trucs simples et rapides et de les compléter au fur et à mesure, en fonction des retours.</p>
<p>L'objectif à terme, c'est d'avoir une documentation assez complète mais vivante. Et surtout accessible aux néophytes, comme par exemple mes étudiants.</p>
<h2 id="et-maintenant">Et maintenant ?</h2>
<p>Avant la version 1.0, il y a encore du travail. Comme déjà dit, j'aimerais compléter la documentation au mieux. Puis, j'aimerais ajouter des fonctionnalités. J'ai déjà quelques idées, et j'ai fait un peu de prospection et il y a des trucs que j'aimerais bien essayer. Mais ça, ça sera pour une prochaine fois. Et puis surtout, je vais porter Akagoria sur ce framework, histoire de ne pas faire un framework pour faire un framework. Et pour utiliser toutes ces magnifiques fonctionnalités !</p></div><div><a href="https://linuxfr.org/news/sdl-ou-sfml-ne-choisissez-plus-prenez-gamedev-framework-gf.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/109592/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/sdl-ou-sfml-ne-choisissez-plus-prenez-gamedev-framework-gf#comments">ouvrir dans le navigateur</a>
</p>
rewindpalm123Benoît Sibaudhttps://linuxfr.org/nodes/109592/comments.atomtag:linuxfr.org,2005:News/134982003-08-06T14:06:51+02:002003-08-06T14:06:51+02:00OpenML 1.0 SDK (alpha)<div>La toute première version du SDK pour OpenML vient d'être publiée par Khronos Group.
<br />
<br />
Pour rappel, OpenML est un pendant multi-plateforme de Microsoft DirectX.
<br />
<br />
Ceci ne peut-être qu'une très bonne nouvelle car cela permettra enfin d'avoir un outil performant pour développer des applications multimédias sur différents OS/systèmes et ceci en limitant les modifications dans le code lors de la migration.
<br />
Pour le moment, le SDK est disponible uniquement pour Windows XP et Linux.
<br />
<br />
À noter qu'il est nécessaire de remplir un formulaire avec une adresse mail valide pour pouvoir télécharger le SDK.
<br />
</div><ul><li>lien nᵒ 1 : <a title="http://www.khronos.org/openml/index.html" hreflang="en" href="https://linuxfr.org/redirect/27093">Présentation d'OpenML</a></li><li>lien nᵒ 2 : <a title="http://www.khronos.org/openml/spec.html" hreflang="en" href="https://linuxfr.org/redirect/27094">Page de téléchargement</a></li><li>lien nᵒ 3 : <a title="http://linuxfr.org/2000/09/14/112.html" hreflang="fr" href="https://linuxfr.org/redirect/27252">Dépêche précédente (sept 2000)</a></li><li>lien nᵒ 4 : <a title="http://www.khronos.org/members/promoters.html" hreflang="en" href="https://linuxfr.org/redirect/27253">Promoteurs du Khronos Group</a></li><li>lien nᵒ 5 : <a title="http://www.khronos.org/members/contributors.html" hreflang="en" href="https://linuxfr.org/redirect/27254">Contributeurs du Khronos Group</a></li><li>lien nᵒ 6 : <a title="http://www.internetactu.com/archives/techno/techno32.html" hreflang="fr" href="https://linuxfr.org/redirect/27255">Historique du Khronos Group</a></li></ul><div>OpenML n'est pas libre au même sens que peut l'être SDL (par exemple). Mais le but d'OpenML est, selon moi, d'avoir ce que l'on peut faire avec OpenGL (licence comprise) mais dans les secteurs autres que la 3D.
<br />
<br />
Mais je pense que compte tenu des membres, il est possible que cet API s'impose "rapidement" et complète alors les manques d'OpenGL face à DirectX.
<br />
<br />
La licence n'est pas différente de ce qui peut exister avec Java (par exemple).</div><div><a href="https://linuxfr.org/news/openml-10-sdk-alpha.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/12823/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/openml-10-sdk-alpha#comments">ouvrir dans le navigateur</a>
</p>
Stéphane VANPOPERYNGHEhttps://linuxfr.org/nodes/12823/comments.atomtag:linuxfr.org,2005:News/58932001-11-12T12:10:19+01:002001-11-12T12:10:19+01:00SDL 1.2.3 dans les bacs !<div>La nouvelle version de la bibliothèque multimédia pour X est de retour, avec plein de corrections parmi lesquelles :
<br />
<br />
- Support MacOS largement amélioré
<br />
- Support Xinerama sous X11
<br />
- Support de la GNU thread lib
<br />
- Support CD pour BSD
<br />
- Ajout d'une accélération framebuffer sur nvidia
<br />
<br />
Ce ne sont que quelques ajouts parmi une grande liste ...
<br />
<br />
Merci à LinuxGames pour l'info.</div><ul><li>lien nᵒ 1 : <a title="http://www.libsdl.org/download.html" hreflang="en" href="https://linuxfr.org/redirect/10024">Téléchargement</a></li><li>lien nᵒ 2 : <a title="http://www.libsdl.org/release/changes-1.2.html" hreflang="en" href="https://linuxfr.org/redirect/10025">ChangeLog</a></li></ul><div></div><div><a href="https://linuxfr.org/news/sdl-123-dans-les-bacs.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/5848/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/sdl-123-dans-les-bacs#comments">ouvrir dans le navigateur</a>
</p>
FRLinuxhttps://linuxfr.org/nodes/5848/comments.atom