Wrapper DirectX 8 -> OpenGL opensource

Posté par  . Modéré par Fabien Penso.
Étiquettes :
0
13
fév.
2002
Jeu
Un société du nom de RealTech-VR vient d'ouvrir le code de son wrapper directX 8 OpenGL. Ils recherchent des développeurs pour porter le tout sous Linux et MacOS. A l'origine le produit était destiné à BeOS...

Il semblerait que pas mal des fonctionnalités aient déjà été implémentées. Encore un plus pour nos jeux sous Linux ?

Aller plus loin

  • # Rester sous Windows ?

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

    Chaque jour une raison de moins de rester sous Windows (où de ne pas s'y mettre comme moi (Amiga -> SCO Unix -> Linux).

  • # Monstrueux.

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

    Je crois que voilà la meilleure nouvelle que les gamers sous linux aient jamais entendue. Si ce machin marche correctement, il devrait être assez facilement portable sous linux, vu que les implémentations OpenGL sont plutôt bien écrites.
    Après, reste la partie difficile, mixer ça à Wine, et ça serait royal. Le mieux serait bien entendu que les développeurs de jeux sous DX8 utilisent directement ce wrapper pour porter leurs jeux, ça devrait quand même leur faciliter la tâche.

    • [^] # Re: Monstrueux.

      Posté par  . Évalué à 10.

      Le mieux serait bien entendu que les développeurs de jeux sous DX8 utilisent directement ce wrapper pour porter leurs jeux

      Franchement, je ne suis pas sur que ca soit "le mieux". Le "mieux" serait qu'on ait une API "équivalente" a DX, mais qui soit independante de la plate-forme et de l'OS, et que tout le monde utilise cette API la...

      Mais bon, si ce wrapper est bien fait (j'ai pas ete voir, et de toutes facons, je suis pas assez cale en la matiere pour "juger"), c'est effectivement une solution assez interessante quand meme !

      • [^] # Re: Monstrueux.

        Posté par  . Évalué à 10.

        He he, ca existe deja et ca s'appelle la SDL...

        Sinon, depuis DX8, MS a rattrapé (depassé) OpenGL.. Le probleme (avantage?) d'OpenGL c'est la reactivité aux nouvelles technologies.. Pixel Shader, Vertex Shader, Methode de mapping, etc etc...

        L'implementation dans le core d'OpenGL doit passer par l'aval du Reference Board du consortium OpenGL, et ca prend du temps... Trop meme... Du coup on se retrouve avec PLEINS d'extensions qui deviennent specifiques au hardware (les NV_ et ATI_ extensions), ce qui n'arrange pas les developpeurs soucieux d'integrer les nouvelles technologies.. (C'est sensé faire vendre..)

        D'un autre coté.. Giants, un jeu pur sucre DX7 a ete porte sous MacOS X en OpenGL.. Tout comme Diablo2 sous Mac.. Donc des solutions alternatives existent deja, il serait bon d'nifier un minimum ces solutions, car se disperser, ca n'a rien de bon...

      • [^] # SDL

        Posté par  . Évalué à 6.

        L'équivalent de DirectX 8, on l'a déjà. C'est SDL (http://www.libsdl.org(...)).
        C'est aussi puissant, beaucoup plus simple à programmer et très largement utilisé par quasiment tous les développeurs de jeux sous linux.

        • [^] # Re: SDL

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

          Sauf que SDL, c'est pour la 2D. Effectivement, pour la 2D, ça rend les portages faciles, c'est même plus simple à utiliser que DirectX. Mais il manque l'équivalent pour la 3D : porter un jeu Direct3D en OpenGL est beaucoup plus difficile... Donc les solutions de ce type sont moins intéressantes qu'une vraie bibliothèque universelle, mais elles le sont nettement plus que la situation actuelle ! C'est l'espoir de voir marcher nativement sous linux une large majorité des jeux Windows.

          • [^] # Re: SDL

            Posté par  . Évalué à 3.

            En fait: SDL fournit plus que de la 2D, en ce sens qu'elle fournit un remplacement de Glut.

            • [^] # Re: SDL

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

              Ah, merci, je ne savais pas.
              Ça doit être bigrement pratique, si c'est aussi bien fait que le reste de la SDL.

        • [^] # Re: SDL

          Posté par  . Évalué à 7.

          Il me semble que DX est (malheureusement...) encore un peu plus que la SDL... (rien qu'au niveau 3D déjà).

          Il me semble aussi que la SDL repose encore sur DX6 pour ce qui est des surfaces d'affichages et qu'au niveau gestion des périphérique d'entrée et sons, c'est encore loin de DX (faut pas oublier que DXShow fait partie de DirectX 8 maintenant).

          Ceci dit, est-ce réellement le manque d'un "DirectX" sous nux qui rebute les éditeurs à porter leurs jeux?

          • [^] # Re: SDL

            Posté par  . Évalué à 7.

            Bah, ils y a des chances... Faut etre realiste, le marché visé pour les jeu est a 99.9% le parc de machines Windows.. Donc si tu as des librairies deja toutes faites qui te facilite le travail, pourquoi ne pas les utiliser.. Sachant que ces librairies sont up-to-date niveau hardware...

            C'est triste a dire, mais souvent les features des jeux sont plus mise en avant que l'histoire ou le gameplay.. Moi qui pensais que justement, les developpeurs etant un peu moins charger niveau code... On aurait de meilleurs jeu (enfin tout est question de gouts aussi)

            OpenGL a de moins en moins de defenseurs, meme Carmark commence a regarder de pres DX8 et surtout le 9, avec des stencils buffers de 64 bits...

          • [^] # Re: SDL

            Posté par  . Évalué à 5.

            Ceci dit, est-ce réellement le manque d'un "DirectX" sous nux qui rebute les éditeurs à porter leurs jeux?

            si le manque de direct x n'est pas une raison de ne pas faire les portage, sa presence est une bonne raison de la faire!
            heu ... je me suis fait comprendre?
            bon je reprend :
            un jeux c'est deux choses importantes en general :
            le moteur et les donées. Les donée ca pause pas de probleme (cf quake3 ou rtcw)
            le moteur c'est le probleme.. Si on peut faire des portages avec un minimum de couts il n'y a aucune raison de ne pas porter les jeux pour les boites ca ne peut etre que du benefice.
            dans le cas de loki falait qu'il passent les moteurs des jeux directX en opengl et ca met du temps donc ca coute chere.
            evidement dans le cas ou le jeux est deja en opengl ca simplifie...

    • [^] # Monstrueux.

      Posté par  . Évalué à 4.

      il me semble que wine n'est pas GPL, est ce qu'on peut le "mixer" avec les Wrapper ?

    • [^] # Re: Monstrueux.

      Posté par  . Évalué à 4.

      Je crois que voilà la meilleure nouvelle que les gamers sous linux aient jamais entendue

      Je trouve que c'est quand meme vachement réducteur d'assimiler les jeux aux trucs qui tournent sous MSDirectX. Je rappelle, pour ceux qui l'ignorent, que de tres nombreux bons jeux proprios tournent sur console.Un portage MSDirectX -> SDL/GL est surement plus simple qu'un portage console->MSDirectX, et pourtant, ce dernier est plus fréquent. Ceux qui s'y connaissent un peu en programmation de jeu pourront peut-etre en dire plus ?

      Tout ca pour dire que j'ai vraiment du mal à croire que ce genre de gadget fera miraculeusement augmenter le nombre de jeux sous Linux.

      • [^] # Re: Monstrueux.

        Posté par  . Évalué à 1.

        >Tout ca pour dire que j'ai vraiment du mal à >croire que ce genre de gadget fera >miraculeusement augmenter le nombre de jeux sous >Linux.

        Oui d'autant plus qu'on ne porte pas un jeu sur une plateforme donnée parcequ'on trouve ca facile a faire, mais parcequ'on pense qu'on va avoir assez de client pour l'acheter.

  • # Utilité?

    Posté par  . Évalué à 10.

    C'est sympa leur truc, mais ça ne wrappe pas vraiment la totalité de directX8, seulement Direct3D (De plus, 70% sont implémentés pour l'instant) Je rappelle que DirectX gère aussi le son, les périphériques de jeu (joystick, souris, clavier)... Je doute qu'on puisse faire fonctionner des choses sous linux avec ce truc avant longtemps, à mon avis chez transgaming ils sont tranquilles pour un moment!


    Ce qui est dommage, c'est qu'on joue le jeu de microsoft! à force de vouloir être compatibles avec directx, tout le monde va l'utiliser, ça va devenir un standard encore plus établi. Bof :/

    • [^] # Et en plus ....

      Posté par  . Évalué à 6.

      DirectX bouge beaucoup. La version 9 est déjà en béta test.

      Deja que wine, sur les API générales pourtant assez stable, avait déjà du mal à suivre l'évolution, pour directX, la course sera très difficile à suivre.

      • [^] # DirectX 9.99.10^22

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

        > DirectX bouge beaucoup

        DirectX est meme carrement impossible a suivre. A chaque nouvelle release, tu as droit a une nouvelle API. C'est ce qui fait que DX3 etait une merde finie alors que DX5 commencait a etre utilisable.

        Le seul point positif est que la compatibilite binaire est assuree. Si tu as DX8 installe et que tu veux faire tourner une jeu DX3. Tu peux. Mais par contre tu le paye par la taille - et la complexite - des libs a installer. Le runtime DirectX ne maigrit pas vraiment ces derniers temps, et on comprend pourquoi... Et cette complexite risque d'etre balaise a emuler. Parce qu'un wrapper qui fait DirectX 8 tout seul, ca ne sert a rien. Il faut un wrapper qui soit capable de reproduire le comportement de DX1/2/3/4/5/6/7/8... Et la ca devient hyper chaud de maintenir le truc. Pour Microsoft, c'est pas si grave, ils ont du monde et c'est eux qui decident de refondre ou pas l'API a chaque fois, mais pour celui qui essaie de les suivre, c'est mort.

        Donc je reste convaincu que la solution est d'utiliser des APIs a peu pres standards et stables du type OpenGL. Evidemment ces APIs ne suivent pas le dernier cri du hard disponible, mais c'est le prix a payer pour avoir une API stable, ce qui reste - et la je n'engage que moi - un confort enorme au niveau de la programmation. Du coup on perd moins de temps sur les details bassement techniques lies au code et on peut se consacrer au developpement du jeu lui-meme.

        • [^] # Re: DirectX 9.99.10^22

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

          C'est vrai que ça bouge beaucoup, mais je crois que depuis la version 5, il n'y a plus de gros changements majeur qui rendent les programmes complètement obsolètes...

          Pour permettre de rendre compatible toutes les versions, ils utilisent une technique un peu spéciale qui est non seulement de donner l'adresse de la structure en paramètre, mais également la taille de cette structure en mémoire ! Après, ils font directement un test sur cette taille pour savoir à qu'elle version de la structure ils ont à faire !

          Ils ne faut pas oublier non plus les paramètres dans l'appel de certaines fonctions qui pour l'instant ne servent à rien mais pourrons servir un jour...

          Bon, ben je préfère largement OpenGL !

          • [^] # API Win32

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

            > ils utilisent une technique un peu spéciale qui est non seulement de donner l'adresse de la structure en paramètre, mais également la taille de cette structure en mémoire !

            C'est la technique "standard" de Microsoft. Ils utilisent ca dans la plupart de leurs API. En tous cas l'API C Win32 "de base" ainsi que plusieurs bibliotheques "courantes" (rasapi.dll par ex) fonctionnent comme ca.

            Inutile de preciser que je trouve ca ignoble et tres peu elegant, mais c'est a ce prix qu'ils peuvent garantir la compatibilite binaire...

            • [^] # Re: API Win32

              Posté par  . Évalué à 2.

              Personellement, je ne connais pas de technique élégante pour conserver la compatibilité binaire.

              Donc cette bidouille là ou une autre..

  • # Et OpenGl dans tout ca ?

    Posté par  . Évalué à 3.

    C'est pas portable de win à *nux et réciproquement ?

    Et SDL ?

    Faire une lib qui émule Direct3D 8, c'est bien, ca peu servir.


    Mais il faudrait tout de même mieux avoir un équivalent complet de directX, portable pour nunux.
    Car il faut aussi le son, les périphérique, les films etc... dans un jeu

    Faudrai que ca improve la produtivité des développeurs par rapport à DirextX.
    Comme ca les développeurs déveloperaient sous Linux et porteraient sous Win.

    Est-ce que SDL est ce que nous recherchons ?

    • [^] # Re: Et OpenGl dans tout ca ?

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

      OpenGL (pour la 3D) assorti de SDL pour le reste est une solution de choix (sinon la meilleure) pour développer des jeux, et ce sur n'importe quelle plate-forme.

      Mais le fait est que pour l'instant, les fabricants de jeux ne le font pas, ils font le choix de développer sur une bibliothèque non pérenne, en risquant de devoir refaire complètement leur moteur à chaque nouveau jeu. C'est pour ça que je pense qu'avoir ce genre de bibliothèques est une très bonne chose.

    • [^] # SDL

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

      SDL est une bibliotheque d'assez bas niveau, relativement portable et stable. Pour le developpeur de jeux nunux, c'est pas mal, encore que je recommande de jeter un petit coup d'oeil sur:
      - Allegro http://www.talula.demon.co.uk/allegro/(...)
      - ClanLib http://clanlib.org/(...)
      qui sont des bibliotheques de plus haut niveau, et evitent de reinventer la roue.

      Maintenant le probleme de SDL c'est que c'est une n-ieme couche logicielle a incorporer dans ton soft, et ca risque de pas accelerer les choses. De ce que j'en sais, les dev de jeux "pro" se font a partir de boites a outils "faites maison" qui sont specifiques a chaque jeu et/ou chaque epoque. Concretement ils se refont un mini SDL-like a chaque fois, optimise pour leurs besoins specifiques. Mais il y a peu de chance pour qu'un jour une lib standard comme SDL reponde a tous les besoins des editeurs de jeux. Eux vont toujours vouloir pouvoir utiliser le-petit-gadget-qui-tue-qui-fait-que-tu-passe-de-50fps-a-60fps.

      Pour ce qui est du developpement de jeux libres, SDL, Allegro et ClanLib sont incontournables.

      • [^] # Re: SDL

        Posté par  . Évalué à 3.

        La SDL est une très bonne lib (la perte en performances est vraiment négligeable), mais la SDL ne fait pas du tout de 3D (même si elle conçue pour bien s'interfacer avec OpenGL), donc ce n'est pas SDL ou OpenGL mais SDL et OpenGL pour un jeu 3D.

        • [^] # Un peu plus qu'OpenGL

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

          Effectivement tu dois te reposer sur OpenGL pour la partie 3D, et l'avantage d'SDL est de rendre transparente l'utilisation d'OpenGL.

          Typiquement, si tu veux faire une appli OpenGL portable, tu vas devoir te coltiner tout un tas d'initialisations chiantes et dependantes a priori de la plate-forme. Alors qu'avec SDL, Glut ou ClanLib tu peut te concentrer sur la partie OpenGL a proprement parler et non pas sur la mise en place d'un environnement OpenGL ad hoc sur chaque plate-forme.

    • [^] # Et OpenGl dans tout ca ?

      Posté par  . Évalué à 3.

      Et Open AL ?
      pas mal de monde en a parlé, mais c'est devenu quoi?

Suivre le flux des commentaires

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