Journal Où en est-t-on avec OpenGL ?

Posté par  .
Étiquettes :
0
8
mar.
2006
Je développe un jeu en OpenGL depuis quelque mois, et j'ai commencé à me posé certaines questions sur l'OpenGL....
Où en est concrètement son développement ? Car je vais sur le site officiel http://www.opengl.org pour me renseigner, et je vois qu'est sortie depuis presque 2 ans la spécification de OpenGL 2.0 mais apparement, aucune implémentation n'a encore été faite ? Donc pour être sûr, je vais voir sur le site du projet Mesa ( http://www.mesa3d.org/ ) et je vois qu'il n'y a rien de neuf depuis janvier 2003....

Puis, pour finir, je me tourne du coté des "trucs" de OpenGL sur la page officiel, et là, on me parle de OpenGL ES... OpenML... OpenVG... GLSL... Comprend plus rien !

Donc, je voudrais savoir où en est le développement de l'OpenGL, car j'ai de plus en plus l'impression qu'on utilise de vieille API qui n'arrivent plus à évolué.
Et à coté de ça, Microsoft évolue encore son DirectX qui, il faut bien le reconnaitre, et bien foutu....
  • # Nvidia

    Posté par  (site web personnel) . Évalué à 6.

    Les drivers implémentent OpenGL 2.0 depuis un petit moment (6mois je dirais à vue de nez)
    Sinon Mesa évolue encore, j'avais pris le CVS pour Xgl, et quelques jours plus tard je l'ai mis à jour pour voir, et y avait quelques mises à jours (bon j'ai pas regardé quoi exactement)
    Sinon DirectX tu trouve qu'il évolue plus?
    DirectX 9 date de quand?
    2003 aussi non? 2004 ptet
    • [^] # Re: Nvidia

      Posté par  . Évalué à 3.

      Oups, j'ai parlé trop vite... Pour mesa, j'avais regardé l'history et pas news... Je confirme qui est encore dévellopé... y'a une news du 2 fevrier.
      Autant pour moi.
      • [^] # Re: Nvidia

        Posté par  . Évalué à 3.

        as-tu une page pour présenter ton projet de jeu ?

        J'ai d'ailleurs remarqué qu'en général les jeux des contributeurs ici me plaisaient bien (e-joutes, biloba en particulier, désolé pour les autres, qu'ils se signalent ici car je ne les connais pas tous, et en particulier pour wormux car je ne l'ai pas encore testé et il a l'air sympa...)

        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

        • [^] # Re: Nvidia

          Posté par  . Évalué à 4.

          Heu, oui : http://snark.blary.com/?page_id=37
          Je sais, je sais... Que des screenshots et pas de téléchargement encore ! Mais ça viendra quand j'aurai plus développer le moteur.
          • [^] # Re: Nvidia

            Posté par  . Évalué à 6.

            "release early, release often." Linus Torvald :)
          • [^] # Re: Nvidia

            Posté par  . Évalué à 2.

            cela semble pas mal... c'est un projet d'envergure en tout cas. Bon courage. Cela ne te tentait pas d'intégrer un système existant type worldforge ou arkhart ( http://www.nekeme.net/ ) ?

            Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

    • [^] # Re: Nvidia

      Posté par  (site web personnel) . Évalué à 1.

      DirectX 9 date de janvier 2003, mais la dernière version qui apporte de nouveaux API (et non juste des corrections) date du SP2 à l'été 2004, donc y'a un an et demi.
      (DirectX 9.0c avec Pixels Shaders 3.0 et Vertex Shaders 3.0)
    • [^] # Re: Nvidia

      Posté par  (site web personnel) . Évalué à 4.

      Les drivers implémentent OpenGL 2.0 depuis un petit moment (6mois je dirais à vue de nez)

      Même plus, Nvidia implémente OpenGL 2.0 sous GNU/Linux depuis juin 2005 avec les pilotes 76.64 :
      http://www.nvidia.com/object/linux_display_ia32_1.0-7664.htm(...)

      Pour DirectX, d'après Wikipédia c'est août 2004 pour la version 9.0c sur WinXP :
      http://en.wikipedia.org/wiki/DirectX
  • # Developpement d'opengl

    Posté par  . Évalué à 5.

    L'ARB d'OpenGL (je ne parle pas de Khronos) ne dev pas cette API comme peut le faire Microsoft, les membres créent des extensions diverses et à un instant T une version certifié par l'ARB voit le jour. Il s'agit plutôt de fixer les extensions issues de tout les côtés dans une base commune que tous doivent intégrer pour se clamer conforme opengl 2.0.

    ATI, Nvidia, 3DLabs ont déjà étendu la base et ce sont ces efforts distincts qui donneront lieu à un eventuel 2.1.
  • # IPoT

    Posté par  . Évalué à 9.

    Un conseil :désactive l'IPoT...
    sur http://www.mesa3d.org, la dernière nouvelle que je vois date de février 2006 !
    Et mesa bouge pas mal, avec notamment les recherches concernant l'accélération et le rendu off-screen.
  • # oui

    Posté par  . Évalué à 3.


    car j'ai de plus en plus l'impression qu'on utilise de vieille API qui n'arrivent plus à évolué.

    Ce n'est pas une impression, c'est la réalité.
    Alors que DirectX propose un framework complet entièrement orienté Jeux Vidéos, Les autres système doivent coller des APIs fragmentaires pour arriver péniblement à quelque chose.

    Pour commencer, sachant que TOUS les jeux vidéos modernes utilisent le C++ (le C pour des projets doté d'une architecture aussi complexe, c'est trop difficile), donc une série d'APIs C++ pour le graphisme, le son, le réseau, les inputs, ça serait bien.
    C'est pas que la SDL me gonfle, mais elle est obsolète et mal foutue...
    Quant à OpenGL, c'est pas pour dire, mais se tapper le wrapping d'une lib en C, c'est lourd.

    En tout cas, félicitations pour ton projet, il est très impressionnant !
    • [^] # Re: oui

      Posté par  . Évalué à 8.

      C'est dommage que tu te sois fait moinser parce que même si ton avis n'est pas partagé, il est pertinent : c'est vrai qu'on peut avoir envie d'un framework complet en C++.

      Ceci dit, c'est pas dans la philisophie des outils/lib sous Unix qui est de faire une chose mais de la faire bien.

      OpenGL ne fait que de la 3d mais le fait bien (du moins pour ceux qui peuvent se contenter graphiquement d'un moteur style Doom 3 :D ). Le fait que l'API soit en C n'est pas génant puisque que c'est une API "bas niveau" (kestananafout d'avoir des classes pour tracer des triangles ?). Et GLSL par dessus est carrément puissant.

      OpenAL est très pratique (et là aussi rien à foutre du C++). Bon, ça mériterait d'être étoffé un peu vu ce que les chips audio sont capables de faire.

      SDL est un peu différente. Pour ouvrir une fenètre et gérer les inputs, elle est bien. Pour le son, elle n'est pas très utile.

      Pour le réseau SDL_net est pas mal (pas beaucoup utilisé, et j'en ai pas testé d'autres).

      Maintenant tu as raison, toutes ces libs ça fait pas un framework qui va faire le boulot à ta place, mais les briques de base sont là et sont très correctes. L'idée du framework n'est pas mauvaise, ça pourrait faire l'objet d'un projet sympa (si ça existe pas déja)...
    • [^] # Re: oui

      Posté par  . Évalué à 4.

      Tu compares 2 choses différentes , OpenGL est une API 3D généraliste. Tu le trouves aussi bien dans les jeux, que dans la modélisation 3d (maya, blender, houdini, j' en oublies), l' architecture, et j' en oublies encore .
      Direct3D n' est pratiquement QUE ludique (3dsmax pour la modélisation des jeux, et ça doit être tout) , il n' a pas les performances nécessaire pour les scénes lourdes ou trés lourde. Et comme c' est un marché restreint (3d professionelle) MS ne veux pas investir la dedans en tout cas pour le moment .
  • # OpenGL n'avance peut être pas mais qu'en est-il des ordinateurs ?

    Posté par  . Évalué à 10.

    Pour compléter ce qui a été dit dans les autres posts, il faut quand même garder à l'esprit qu'OpenGL n'a pas grand chose à voir avec Direct3D. En effet, ce dernier existe principalement pour le jeu. En revanche, OpenGL est présent sur la totalité des stations de travail (IBM, Sun, SGI & consort) et les applications de simulation ou de visualisation reposent fortement dessus. Donc à mon avis, la mort d'OpenGL n'est pas pour demain.

    Pour ce qui est de l'évolution, tout dépend aussi de l'architecture des ordinateurs. Du peu que je connais des stations que j'ai cotoyées lors de mes études, j'aurais plutôt tendance à dire que l'on a régressé avec les cartes graphiques embarquant leur propre mémoire. On a certes gagné en rapidité mais on a aussi beaucoup perdu en fonctionnalité. En effet, sur les machines à mémoire unifiée, les vertex arrays et les textures étaient d'une grande puissance : le programme modifiait les buffers et les modifications se répercutaient immédiatement à l'écran. Pour retrouver cette puissance, les constructeurs (puis l'ARB) ont dû sortir les render to texture ou les VBO pour rerattraper le retard (tout comme avec la récente GLX_EXT_texture_from_pixmap utilisée par Xgl). Et nous en sommes encore loin puisqu'il y a toujours besoin de faire des transferts entre mémoire centrale et mémoire graphique. Tout ça pour dire que la seule grande innovation depuis belles lurettes est les shaders.

    Pour poursuivre sur les shaders, Direct3D a suivit le matériel (enfin ... celui accessible aux utilisateurs de PCs), on a donc eu plusieurs versions et révisions pour les shaders. Mystérieusement pour OpenGL, on a 1 seule version (avec quand même des révisions mineures). Mes drivers Nvidia me disent "vous avez les shaders de disponible !", je dis "youpi \o/" et pourtant ma gffx5200 supporte partiellement les buffers en flottant et les instructions de saut en sont absentes. Il a fallu donc qu'ATI, Nvidia & les autres arrivent à implémenter les spec d'OpenGL/GLSL dans leurs GPU et cela leur a pris du temps (3 générations de GPU pour Nvidia). Pendant ce temps là, OpenGL stagnait car personne ne l'implémentait à 100% en hard ou n'avait pas besoin de plus.

    OpenGL est certes vieux mais on ne change pas une API éprouvée du jour au lendemain. D'ailleurs 3DLabs s'était pris une belle claque en 2001/2002 car ils avaient réfléchi sur un OpenGL 2.0 où il le remettait entièrement à plat. Mais bon, les specs ont disparu du web et rien ne semblent présager leur retour sur le devant de la scène ; c'est triste ...

    Dans ton énumération des API reprenant l'approche d'OpenGL pour des domaines plus spécifiques, tu oublies OpenAL pour le son (et qui pourra sûrement t'intéresser quand tu t'attaqueras au son dans ton jeu:)

    À propos de ton jeu, quelle méthode utilises tu pour le terrain ? heighmap avec un quadtree ? octree ? ROAM ? CLOD ? j'avoue avoir laché un "merde ! y dit pas quel algo il utilise" O:-)

    mes 2¢ ... allez ! 3¢ vu le nombre de caractères :]
    • [^] # Re: OpenGL n'avance peut être pas mais qu'en est-il des ordinateurs ?

      Posté par  . Évalué à 1.

      Est-ce que les problèmes que connait SGI ces temps-ci peuvent porter préjudice à l'API OpenGL?

      Et si SGI se faisait racheter par Nvidia, qu'a t-on à craindre?
      • [^] # Re: OpenGL n'avance peut être pas mais qu'en est-il des ordinateurs ?

        Posté par  . Évalué à 4.

        OpenGL est un standard géré par l'ARB, pas par une seule société (même si SGI en est à l'origine) donc il y a peu de chance qu'OpenGL disparaisse.

        Avec l'histoire de Vista qui ne permettra(it) pas une adéquation parfaite entre l'interface graphique et OpenGL, j'ai quand même quelques craintes mais je reste relativement confiant dans les utilisateurs professionnels car je vois mal des sociétés passer de Maya (qui n'est qu'OpenGL) à 3dsMax (qui supporte aussi Direct3D) ... je les vois plus passer sous un Linux. De même pour celles qui sont encore sous des stations Unix et qui renouvèlent leur parcs avec des PCs pour des raisons de puissance/prix. Il vaut mieux un Unix (et donc Linux) pour minimiser les changements d'habitudes. Pour moi, le rejet d'OpenGL par Ms est une jolie balle tirée dans leur pied pour ce qui est du secteur professionnel.


        J'ai du mal à voir SGI se faire racheter par un fondeur de processeurs graphiques comme Nvidia. D'ailleurs, à une époque, il y avait des rumeurs de rachat de la division graphique de SGI par Nvidia (qui coincide avec le changement de Silicon Graphics en SGI). En tout cas, il y a des accords entre eux puisque les systèmes graphiques VPro utilisés par SGI pour certaines de leur stations viennent de chez Nvidia (par contre, qui a fait quoi, je ne sais pas):

        bon, au dodo maintenant /o\
        • [^] # Re: OpenGL n'avance peut être pas mais qu'en est-il des ordinateurs ?

          Posté par  . Évalué à 1.

          A ce qu'il me semble, il est désormais certain que Vista n'aura pas le moindre problème pour utiliser OpenGL.

          Quand à SGi, beaucoup de monde se demande s'ils vont passer ne serait-ce que l'année et il n'est donc pas improbable du tout que nVIDIA mette la main sur la division carte graphiques.
        • [^] # Re: OpenGL n'avance peut être pas mais qu'en est-il des ordinateurs ?

          Posté par  . Évalué à 5.

          Les standarts c'est bien jolis, mais le fait est là:

          Soit raoul, un joyeux programmeur de jeux vidéos, qui recherche des libs pour son prochain MMORPG-de-la-mort-qui-tue.

          - Dans sa main gauche, il voit qu'il va devoir mettre côte à côte OpenGL, OpenAL, SDL et ses divers extensions, bidouiller ses propres plugins pour blender/gimp pour gérer ses médias, tout reprendre à 0 parce qu'il n'y a pas d'équivalent D3DX, etc...

          - Dans sa main droite, il ouvre Visual Studio <remplacer-par-l'année-en-cours>, créer un nouveau projet DirectX, et hop, il a tout ce qu'il faut pour développer son jeu.

          Et que croyez-vous qu'il va choisir ? Croyez vous que son choix sera modifié quand il apprendra que 0.1% des gens ne pourront pas jouer ?

          ATTENTION ! Je ne dis pas que c'est bien, et que ce choix est judicieux, je dis que je le comprend. Avez-vous déjà essayé de développer du jeu vidéo ? Ceux qui l'ont fait comprendront mon point de vue.

          Le C, je n'ai rien contre, je l'aime beaucoup pour les applis systèmes où un maximum de vitesse est requis, ainsi qu'un accès bas-niveau au système.
          Pour un jeux vidéo, le C est inutilisable. Ce n'est pas moi qui le dit, ce sont les dizaines de développeurs pro, Carmack inclus.
          Encore une fois, je ne dis pas que c'est bien, je dis que c'est comme ça.

          OpenAL progresse, certes, mais on est loin des capacités gigantesques de DirectSound/DirectAudio.

          SDL, c'est encore mieux, ne progresse plus. Et utiliser SDL juste pour le fenêtrage, c'est overkill. Et pour les inputs ? On a autre chose dans le style de DirectInput ? Ah bin non...

          OpenGL, a atteint un stade tel que la progression est bien trop lente pour suivre l'évolution ultra-rapide des jeux vidéos, et il n'y a AUCUNE alternative à OpenGL, on est coincés à attendre que l'ARB se bouge ENFIN le cul...
          Notons également qu'avec le package DirectX, on retrouve des kilomètres de doc et d'exemples d'une clareté exemplaire. Avec OpenGL, on récupère un include, une référence des fonctions, et quelques exemples sur le site officiels, presque tous obsolètes.

          L'unique solution pour qu'on ait un jour des jeux vidéos de niveau pro sous Linux (autres que les portages de chez Id Software...), c'est que quelqu'un se mette au boulot sur une API de qualité professionnelle destinée aux jeux vidéos. C'est dire à quel point on est mal barrés...
          • [^] # Re: OpenGL n'avance peut être pas mais qu'en est-il des ordinateurs ?

            Posté par  . Évalué à 7.

            L'unique solution pour qu'on ait un jour des jeux vidéos de niveau pro sous Linux (autres que les portages de chez Id Software...), c'est que quelqu'un se mette au boulot sur une API de qualité professionnelle destinée aux jeux vidéos. C'est dire à quel point on est mal barrés...

            Qu'est-ce qu'on attend ?
            Je déconne pas, j'ai déja tendu la perche quelques pixels plus haut, les briques de base sont là, il suffirait de définir ce qui manque et de développer un framework bien propre.

            De toutes façons, à mon avis l'avenir de Linux hors monde professionnel passe par les jeux, et je ne parle pas de jeux libres ou même gratuits. Tant qu'on n'aura pas un bon nombre de jeux de qualité (et merci, pas de troll sur qualité vs libre, un jeu de qualité, c'est des hommes-années d'artistes, et des artistes vous en avez quelques uns sur lestelechargements.com qui vous expliquent qu'ils bossent pas pour des prunes) sous Linux, Linux rentrera pas dans la maison de monsieur-tout-le-monde (voir le fric qui se brasse dans le monde du jeu video pour s'en convaincre).

            Si ça tente quelqu'un ne serait-ce que d'en discuter, je passe sur LinuxFR de temps en temps.
            • [^] # Re: OpenGL n'avance peut être pas mais qu'en est-il des ordinateurs ?

              Posté par  . Évalué à 1.

              Je suis prêt à en discuter, cela pourrait être un projet intéressant.
              Il faudrait trouver des gens motivés avec des qualifications divers.

              Ce qu'il manque est énorme, il faudrait définir les besoins les plus immédiats, et y aller étape par étape.

              D'autres volontaires ?
              • [^] # Re: OpenGL n'avance peut être pas mais qu'en est-il des ordinateurs ?

                Posté par  . Évalué à 3.

                Ça serait assez intéressant d'avoir (au moins) l'avis de ceux qui ont déja développé (ou qui développent en ce moment) des jeux.

                Perso, j'ai participé au portage de Warzone 2100 vers Linux (au passage, les libs existantes ont beaucoup aidé), donc j'ai pu toucher à quelques aspects, mais c'est resté du développement très "local" et je ne pense pas avoir une vision globlale de ce que les développeurs de jeux peuvent attendre (j'ai quelques ptites idées quand même).
                C'est pour ça que je propose un ptit travail en équipe.

                Un ptit point au passage : la libération de Warzone 2100 est un modèle excellent. J'aimerai beaucoup que d'autres éditeurs/développeurs de jeux libèrent leur code et les données du jeu.
              • [^] # Re: OpenGL n'avance peut être pas mais qu'en est-il des ordinateurs ?

                Posté par  (site web personnel) . Évalué à 2.

                il existe des centaines de lib pour jeux video.

                Il y a plusieurs "moteur 3D" de disponnible qui font plus que la SDL.

                "La première sécurité est la liberté"

          • [^] # Re: OpenGL n'avance peut être pas mais qu'en est-il des ordinateurs ?

            Posté par  (site web personnel) . Évalué à 7.

            Pas trop d'accord sur le coup ; je m'explique.

            John Carmack, qui reste la référence pour moi, n'a abandonné le C pur que relativement récemment il me semble ; donc je doute qu'il dise que c'est inutilisable. Au contraire, pour lui Direct3D a une API beaucoup moins bien qu'OpenGL lorsque l'on doit la wrapper. Parce que tout ceux qui ont déjà fait du jeu vidéo savent que Direct3D/DirectX, aussi Orienté Objet soit-il, doit quand même être wrappé dans des objets de haut niveau (mesh, texture, squelette...). J'en profite pour donner un lien d'un didactiel pour faire un moteur 3D utilisant à l'envie OpenGL ou Direct3D:
            http://loulou.developpez.com/tutoriels/moteur3d/

            Sinon je suis d'accord avec toi, le C n'est pas adapté pour faire du jeu vidéo, le C++ est déjà bien mieux. En revanche la force du C est de pouvoir être 'bindé' facilement dans les autres langages. C'est flagrant, tous les langages du monde ont un binding OpenGL (et comme je l'ai dit wrapper OGL en C++ c'est pas plus difficile que wrapper D3D).

            De toutes les façons un mec qui veut se lancer dans un jeu depuis zéro il ne choisit pas la facilité, même si VC++ propose de base un projet DirectX. Il existe tout un tas de moteurs 3D qui proposent des API de haut niveau. Parce qu'autant programmer des Octrees/BSPTree/etc.. c'est super marrant, autant wrapper les fonctions OGL/DX/SDL/etc, faire une nième bibliothèque de maths, faire des gestionnaires de ressources, etc..., et ben c'est déjà beaucoup plus rébarbatif, et DirectX n'y pourra pas grand chose.

            Le plus gros problème pour avoir des jeux pros sous Linux, c'est une histoire de mentalité avant tout, c'est pas technique. Parce que des jeux qui ont utilisé le moteur de Quake 3 y en a eu quelques uns (No one lives forever...), et leur code dans l'absolu devait passer sans gros problème sous Linux ; pourtant on en a jamais vu la couleur. Et c'est parce que les éditeurs n'en ont rien a fiche !!! Même faire un build pour Linux/x86 ça les fait chier pour le peu que ça leur rapporterait. Donc une super-API3D-méga-portable-de-la-mort n'y changerait rien du tout.

            Et puis n'oublions que Linux c'est pas que sur x86, et faire du code qui passe sous tout un tas d'archi, ça se fait pas tout seul (enfin surtout c'est avant tout un question de volonté, parce que des programmes java avec des 'C:\Program Files' ça existe !). Alors GNU/Linux c'est du Logiciel Libre, ça ne marche bien qu'avec d'autres logiciels libres, et c'est très bien comme ça à mon avis. Quelqu'un que ca gène pas de jouer à un jeu proprio, ca ne doit pas le géner beaucoup de garder un OS proprio.

            GuieA_7, qui rêve d'avoir des jeux pros avec un code source libre ! :)
            • [^] # Re: OpenGL n'avance peut être pas mais qu'en est-il des ordinateurs ?

              Posté par  . Évalué à 2.

              Je ne suis pas totalement d'accord avec toi.
              Le C++ est certes plus difficile à wrapper, si l'architecture de base est mal conçue.
              Un exemple comme un autre, il est inconcevable d'avoir à coder une classe de vecteur 3/4D pour faire un jeu ! Sous DirectX, on trouve une classe de vecteur toute prête, optimisée, bien fichue, et parfaitement intégrée au reste de l'API. Sous OpenGL, ce qui est appelé un vecteur, c'est un float[3], on voit de suite la différence.

              Autre exemple, l'affichage de texte. Je me viens de me manger une énième fois un système de rendu de texte maison, et ça me gave (même si sur le princip c'est rigolo). Cela me gave, parce que ma lib ne gère pas l'unicode, n'est sûrement pas optimisée, bug encore un poil, et que ça ne fait pas avancer l'ensemble du moteur.

              Un framework de développement de jeux vidéos DOIT intégrer un système de rendu de texte fiable et polyvalent, gérant parfaitement l'unicode, permettant d'importer les fonts depuis plusieurs formats vers un format interne.

              Quand un studio choisit de développer son propre moteur 3D (et ça arrive souvent, parce qu'un vrai moteur comme le Source Engine ou l'Unreal Engine, ça coûte bonbon), il lui faut un framework de base: hors de question de ré-développer une énième classe RGBColor, une énième gestion de vertex buffer, hors de question de passer des heures à réfléchir à comment qu'on va gérer les dizaines de renderpaths possibles, et j'en passe.

              Un bon framework de devel de jeux vidéos, doit:
              - Disposer d'une API C++ légère et extensible;
              - Être multi-plateforme (Windows, Linux, MacOS au minimum) et multi-systèmes (gestion de renderpaths);
              - Fournir un ensemble de classes de bases: mathématiques (vecteurs, matrices, trigo, ...), physique (cinématique, dynamique, ...), graphisme (vertex buffers, shaders, ...), audio (réverbération, échos, ...), réseau, système (fichiers ...), vidéo, etc.;
              - Fournir un ensemble minimum aisément extensible: rendu de texte, GUI complet, meshs;
              - Être scriptable;
              - Fournir de vrais outils de développement: gestion mémoire maison (là même DirectX ne le fait, alors que cela me parait essentiel), plugins pour différents outils de graphisme/audio pour exporter vers une série de formats interne...

              Et je dois sûrement oublier plein de choses.

              Beaucoup d'éditeurs ne sont pas intéressés par le portage Linux car cela nécessiterait du travail, certes faible, mais existant. Avec un framework complet multi-plateformes, les développeurs n'ont aucune raison d'utiliser une autre API, et donc tout le code est de suite portable.

              Bien-sûr, c'est du boulot, raison pour laquelle ça n'existe pas...

              Quand au moteur de Loulou, il est très bien construit, mais est TOUT sauf multi-plateforme, il n'y a qu'à lire le code.
              • [^] # Re: OpenGL n'avance peut être pas mais qu'en est-il des ordinateurs ?

                Posté par  . Évalué à 2.

                On commence quand ? :*)
                • [^] # Re: OpenGL n'avance peut être pas mais qu'en est-il des ordinateurs ?

                  Posté par  . Évalué à 1.

                  Et bien si tu es sérieux, on commence par définir un moyen de contact, mail (khaelin[at]gmail[at]com) ou jabber (galdor[at]jabber[dot]org).
                  • [^] # Re: OpenGL n'avance peut être pas mais qu'en est-il des ordinateurs ?

                    Posté par  . Évalué à 2.

                    Bon, je suis prêt à mettre du miens pour faire un beau projet de framework (malgrès que je passe déja beaucoup de temp sur mon jeu ^^). Pour les interesser, j'ai fait un canal IRC à #gamefw@freenode (Bon, je débute sur IRC... alors je sais pas si ça marche bien :p). Pour mon mail, il est sur mon site.

                    @rémi: Pour mon jeu, j'utilise un bête octree, optimisé par mes soins et gerant le progressive mesh du terrain.... Mais c'est pas ça qui à été le plus dur à faire ;)
              • [^] # Re: OpenGL n'avance peut être pas mais qu'en est-il des ordinateurs ?

                Posté par  (site web personnel) . Évalué à 2.

                Pour le wrapping de D3D, c'est pas moi qui le dit, c'est Carmack ; ce n'est pas Dieu le père mais je lui fait confiance. Mais si je devais faire la comparaison avec autre chose, je prendrais GTK et Qt. Ce sont là 2 excellentes bibliothèques, mais si coder une GUI avec GTK en C est quand même très cochon (alors que Qt est du C++ bien foutu), il faut reconnaître que GTK est wrappé dans plus de langage que Qt, et que ces wraps sont bien.

                Pour les vecteurs/matrices/quaternions, ce n'est pas par hasard qu'on trouve pleins d'articles sur comment en faire, et ce même sur des sites parlant de dev de jeux sous win, c'est parce qu'on finit toujours par se les frapper. Et ça pour la bonne raison qu'on en a besoin dès qu'on veut faire des collisions 3D par exemple, ceux de D3D/OGL ne vont pas dans ce cas : ils sont fait pour l'affichage, pas pour récupérer les coordonnées résultats et ainsi faire les tests de collisions.

                Mais au final on est d'accord : il faut un framework très puissant et ne pas partir de zéro. Mais ça n'a rien a voir avec OpenGL ou D3D, puisque les gars qui font ce framework vont se charger de les wrapper (dans la mesure où on peut faire les mêmes choses avec dans l'absolu). Pour ma part, même s'il n'est pas du tout parfait, j'aime beaucoup OGRE:
                http://www.ogre3d.org/

                PS : oui le moteur de loulou n'est pas utlisable tel quel sous Linux, mais ce n'est qu'un didacticiel ; je n'allais pas t'envoyer dans les sources de Ogre, qui lui aussi wrappe OGL et D3D entre autres.
              • [^] # Re: OpenGL n'avance peut être pas mais qu'en est-il des ordinateurs ?

                Posté par  . Évalué à 4.

                Ta fougue semble te faire mélanger beaucoup de choses. OpenGL est une API graphique bas niveau, pas un middleware comme peut l'être Renderware (DirectX, lui, se place à mi chemin tout en étant plus proche du middleware) donc merci de comparer ce qui est comparable.


                Tu veux refaire un système physique alors qu'il existe l'excellent ODE : http://www.ode.org/ ?
                Tu veux refaire un système sonore alors qu'il existe OpenAL : http://www.openal.org/ ?
                tu comptes aussi réinventer libcal3D (http://cal3d.sourceforge.net/ ) ?
                Pour les systèmes de datapack, cherches avec ton moteur de recherche préféré et tu en trouvera à la pelle.

                Pour le scriptage, Lua devrait te plaire.

                Si ceux-là ne te plaisent pas, tu en trouveras d'autre plus à ta convenance.


                Bien-sûr, c'est du boulot, raison pour laquelle ça n'existe pas...

                J'adore cette phrase ... pourquoi cela n'existe pas ? Parce qu'il n'y a que les sociétés commerciales qui peuvent se permettre un tel investissement. Si les dev d'Ogre3D utilisent au maximum des bibliothèques tierces, ce n'est pas pour rien. Il est de loin plus efficace de s'appuyer sur une communauté déjà existante que sur celle de son projet.

                DirectX propose tout de base (pas de physique pourtant, cénul) mais dire qu'il n'y a rien en face, je trouve ça plutôt insultant pour tous les gens qui bossent dessus et avec.


                Je m'excuse pour le rentre dedans mais il te faut revenir sur Terre et retrouver une objectivité décente. Toutefois, je me permet d'hasarder quelques conseils :

                1/ KISS. Si tu fais une API trop complexe/figée/autre, la migration vers ton API n'en sera plus que douloureuse pour les dev intéressés. Il te faut donc un système alliant à la fois puissance, évolutivité et souplesse.

                2/ Puisque tu es assez remonté contre l'absence de doc, fais en une bien avec des tutoriels (qui marchent:). Tu risques de comprendre pourquoi il n'y en a peu et pourquoi certaines bonnes idées restent méconnues.


                Pour conclure, il y a, à mon avis, largement de quoi répondre aux besoins de chacuns. Mais ce qui manque surtout, c'est de la communication. Qui sait qu'Unreal tournament utilise OpenAL ? Qui sait que les Baldur's Gate utilise Lua comme langage de script ? Il doit y avoir pleins d'autres cas mais aucun n'est correctement valorisé.


                Bon, j'pars fouiller dans mes répertoires si je peux trouver du code suceptible de vous être utile :)

                rem sur #codefr@freenode
                • [^] # Re: OpenGL n'avance peut être pas mais qu'en est-il des ordinateurs ?

                  Posté par  . Évalué à 1.

                  Ce que je veux dire, c'est qu'il y a plein de petites briques éparpillées, et pas un framework offrant un environnement complet. Et coller des briques ensembles, ce n'est pas toujours pratique/facile/performant.

                  Si en plus tu veux un framework prévu pour le multi-core, les candidats sont d'un coup moins nombreux.

                  Beaucoup de jeux commerciaux utilisent LUA, mais il n'empêchent que le gars qui veut intégrer LUA à son jeu va devoir passer un packet de temps à coder une lib intermédiaire qui devrait déjà être fournie.
                  Ainsi, il devrait être possible de faire un:

                  Object* perso = new Entity(OBJ_SCRIPTABLE | OBJ_RENDERABLE | OBJ_PHYSIC);


                  Puis de fixer les différents paramètres:

                  perso->mod_script->setInitScript("blabla.lua");
                  perso->mod_render->setRenderer(new MeshRenderer("blabla.mesh"));
                  perso->mod_physic->setPosition(Vec3(1, 0, 0));


                  Enfin bon, un bête bout de code c'est très abstrait, mais l'idée est là.


                  Bon, j'pars fouiller dans mes répertoires si je peux trouver du code suceptible de vous être utile :)

                  Merci beaucoup :)
                  • [^] # Re: OpenGL n'avance peut être pas mais qu'en est-il des ordinateurs ?

                    Posté par  . Évalué à 1.

                    C'est pas un truc dans le genre de OGRE 3D ( http://www.ogre3d.org/ ) que tu cherches ?
                    • [^] # Re: OpenGL n'avance peut être pas mais qu'en est-il des ordinateurs ?

                      Posté par  . Évalué à 3.

                      Ogre3D est un moteur gérant l'affichage, les données graphiques et ce qui touche aux collisions et à la physique, il lui manque le son et bien d'autre chose.

                      L'idée de Nicolas Martyanoff est de faire une API assez bas niveau (comparé à un moteur) qui fasse office de surcouche à, par exemple, OpenGL/OpenAL/Lua/ODE/autre pour définir un ensemble cohérent exploitable par des personnes/sociétés pour qu'elles développent leur propre moteur de jeu ... bref, un équivalent à DirectX.
                      • [^] # Re: OpenGL n'avance peut être pas mais qu'en est-il des ordinateurs ?

                        Posté par  (site web personnel) . Évalué à 1.

                        Je ne connais pas bien DirectX, alors ça c'est des vraies questions :
                        - il y a de la physique dans DirectX?? parce que s'il y en a, ça doit pas être aussi bien que ODE vu que des devs pro utilisent ODE avec DirectX.
                        - il y a un langage de script puissant dans DirectX?? parce que là encore Lua est utilisé par des pros avec DirectX.

                        Sinon, et c'est là où les LL sont beaux, c'est que si Ogre suffit pas, et bien il peut être intégré librement dans un moteur de jeu plus haut niveau encore (avec réseau, son etc...). C'est ce qui est fait avec Axiom par exemple :
                        http://realmforge.com/
                        (bon j'ai pas testé, mais après recherche rapide il semble que ça marche aussi avec Mono)
            • [^] # Re: OpenGL n'avance peut être pas mais qu'en est-il des ordinateurs ?

              Posté par  . Évalué à 2.

              Le plus gros problème pour avoir des jeux pros sous Linux, c'est une histoire de mentalité avant tout, c'est pas technique. Parce que des jeux qui ont utilisé le moteur de Quake 3 y en a eu quelques uns (No one lives forever...), et leur code dans l'absolu devait passer sans gros problème sous Linux ; pourtant on en a jamais vu la couleur. Et c'est parce que les éditeurs n'en ont rien a fiche !!! Même faire un build pour Linux/x86 ça les fait chier pour le peu que ça leur rapporterait. Donc une super-API3D-méga-portable-de-la-mort n'y changerait rien du tout.

              Effectivement, mais faire des binaires Linux implique aussi de faire un minimum de support et qui est prêt à assurer un support pour des jeux où 99% des acheteurs potentiels ont un Windows qui le fera tourner ? Ce n'est pas tant que de compiler et faire des versions Linux qui coute cher, c'est aussi d'assurer un support technique qui va avec. Je suis sûr que c'est d'ailleurs la raison principale de l'absence de client Linux pour World of Warcraft, bien qu'il y ait d'énormes chances qu'il en existe un dans les tirroirs de Blizzard.

              Et puis n'oublions que Linux c'est pas que sur x86, et faire du code qui passe sous tout un tas d'archi, ça se fait pas tout seul (enfin surtout c'est avant tout un question de volonté, parce que des programmes java avec des 'C:\Program Files' ça existe !). Alors GNU/Linux c'est du Logiciel Libre, ça ne marche bien qu'avec d'autres logiciels libres, et c'est très bien comme ça à mon avis. Quelqu'un que ca gène pas de jouer à un jeu proprio, ca ne doit pas le géner beaucoup de garder un OS proprio.

              Actuellement, on assiste de plus en plus à une standardisation de fait des architectures matérielles vers un couple x86 pour les ordinateurs et PowerPC pour les consoles. Alors faire une version sparc ou mips d'un jeu qui sera utilisée par 15 personnes... Cela implique aussi le support technique spécifique ET l'optimisation du jeu pour l'architecture en question. Vu le coût de développement d'un jeu, je ne pense pas que ça soit réaliste.
              • [^] # Re: OpenGL n'avance peut être pas mais qu'en est-il des ordinateurs ?

                Posté par  (site web personnel) . Évalué à 1.

                Ah mais on est bien d'accord sur les 2 points que tu soulèves !!

                Je disais qu'un framework très portable ne changeait rien à l'affaire (vu que ça existe déjà), vu que les éditeurs ne font pas l'effort de fournir un binaire ; mais tu fais bien de préciser ma pensée (il faut fournir du support). D'un autre côté si Id software se le permet, même si ce n'est pas forcément un gain d'argent phénoménal pour eux, je doute que ça représente un gouffre financier. Donc pour un jeu qui utilise un moteur d'Id c'est vraiment pas compliqué. C'est pour ça que je parle de mentalité : il est bien connu que Carmack aime bien le libre ; mais sa boite lui laisserait pas jeter l'argent par les fenêtres.

                Pour le 2ème point, je voulais juste dire que ça m'énerve les 'compatible PC' qui signifie en fait 'compatible windows', ainsi que les 'compatible Linux' pour 'compatible Linux/x86/libcN'. Après qu'une boite ne fasse pas de version NetBSD/Sparc, je le comprend évidemment, mais si c'était du libre (le code source j'entend), un courageux pourrait s'y coller.
                • [^] # Re: OpenGL n'avance peut être pas mais qu'en est-il des ordinateurs ?

                  Posté par  . Évalué à 2.

                  De toute façon, même si on réglait ce problème de framework portable - quoique le moteur de Quake3 ou Ogre peuvent répondre à la demande - il restera un problème de taille, des pilotes valablent et en libre au moins pour les cartes ATI, plus répendues. C'est quand même la cause du gros retard des OS libres.
                  Même si j'aime jouer - je dispose d'une console à cette fin - la création est ce qui m'botte le plus.
                  Et la seule constante entre le jeu et la création, c'est cette fichue carte graphique!!!

                  enfin c'est pas gagné

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.