Discussion :

[zabibof]

Bonjour,
Je vais sûrement dire des conneries,je m'en excuse d'avance, mais il fallait que je pose cette question.
Bon, voilà: j'aimerais connaître les principales raison qui poussent à faire un moteur multi-API puisque le moteur va encapsuler DirectX et OpenGL, il met les 2 APIs au même niveau.

Je suis sûr que quelqu'un va se ramener avec l'éternel débat OpenGL vs DirectX, donc pour celui ou celle là, NON MERCI.

[MorpheuxDX]

Je me suis souvent posé cette question moi aussi.

Car en fait, les deux API ont quand meme un certains nombres de spécificités. Donc, je me dis quelques parts
qu'en faisant un noyau général, avec derrière une surcouche destiné à une API ou ou autre, on doit perdre un peu en
optimisation.

Donc, si l'on souhaite faire un moteur multiplateforme,pourquoi ne pas faire un moteur tout simplement OpenGL ?
En exploitant au mieux les caractéristiques de cet API.

Il y a certainement une ou des raisons qui m'échappe... et de bonnes raisons qui poussent
les concepteurs de moteurs comme Ogre ou Irrlicht (pour n'en citer que deux) à faire de la sorte...
( et a coder pas mal de routines sous les diffierentes API)

[Yellow.fr]

Une des raison, c'est qu'il n'y a pas seulement deux API graphique.
Part exemple il serait tout a faire possible d'utiliser Ogre sur PS3 (qui utilise OpenGL SE, il me semble), cela est facilité car nous avons la possibilité de coder des wappers pour toutes les API présentes et futures, et cela donne au moteur une très grande flexibilité.

[LeGreg]

Portabilité (l'ensemble des APIs compatibles varient d'une plateforme à l'autre), encapsulation, certaine garantie pour le futur (si une API disparait au profit d'une autre), préférence des utilisateurs (pour les librairies qui sont utilisés par plusieurs équipes différentes) etc, etc.

Il y a beaucoup de raisons de faire du multi-api et parfois c'est indispensable (dévelopement console simultané), mais c'est aussi couteux en terme de temps de developement bien entendu, de couts d'abstraction à l'execution etc...

LeGreg

[screetch]

Ce n'est pas tres couteux en temps d'execution d'encapsuler l'API. La plupart des commandes utilisées existent dans les deux mondes. Il est quasiment indispensable de fournir aux developpeurs une aide de plus haut niveau que le code OpenGL/DirectX; la partie wrapping d'opengl/directx represente une couche tres faible de Ogre par exemple, comparé a la gestion de scene, les mesh, etc.

[bafman]

Ce n'est pas tres couteux en temps d'execution d'encapsuler l'API. La plupart des commandes utilisées existent dans les deux mondes. Il est quasiment indispensable de fournir aux developpeurs une aide de plus haut niveau que le code OpenGL/DirectX; la partie wrapping d'opengl/directx represente une couche tres faible de Ogre par exemple, comparé a la gestion de scene, les mesh, etc.

certe, ce n'est pas les quelques appels de fonction virtuel qui vont couter le plus cher.
le principal problème das moteur multi api, c'est qu'on n'architecture pas un moteur openGL de la même façon qu'un moteur D3D, ls types de données sont different... du coup, à un moment ou a un autre, on est obligé de favoriser une API d'un point de vue architectural... ou alors on ne favorise aucune API, mais du coup, on utilise les 2 de façon non optimal, notamment, au niveau des conversion de données...
bref, faire du multi API, c'est utiliser mal au moins une des API
bien entendu, je parle du multi API comme il est implementé au niveau des moteur du style Ogre. Pour les gros moteur commerciaux, il est possible que plusieurs version du moteur soit fournis, et que le choix se fasse à la compilation (donc sans surcout lié à l'abstraction), mais ce n'est pas le cas de l'unreal engine ni du moteur de far cry en tout cas

[zabibof]

Merci pour ces quelques réponses, en tout cas maintenant, c'est moins sombre.

[nicroman]

le principal problème das moteur multi api, c'est qu'on n'architecture pas un moteur openGL de la même façon qu'un moteur D3D, ls types de données sont different... du coup, à un moment ou a un autre, on est obligé de favoriser une API d'un point de vue architectural... ou alors on ne favorise aucune API, mais du coup, on utilise les 2 de façon non optimal, notamment, au niveau des conversion de données...
bref, faire du multi API, c'est utiliser mal au moins une des API

Je ne suis pas tout à fait d'accord avec ça...

Parlons des "moteurs" qui n'ont qu'un simple wrapper des appels des APIs. Dans la grande majorité ils se basent sur une API donnée. Et il est vrai que même si le precept Buffer->Geometry-Program->Buffer->Vertex-Program->Buffer->Pixel-Program->Target est le même partout il peu y avoir des différences subtiles.

Maintenant le type de données n'a rien à voir avec ça. Pour tout ce qui est buffer (comme les textures), le 'wrapper' peut traduire à la lecture sans aucun problême. Quant aux données durant la partie, le "jeu" ne travaille de toute manière pas sur les mêmes données que l'affichage... Et rien n'empêche au moment de l'interpolation entre deux "frames" (de jeu), de faire une traduction de données si besoin est (et encore, rares sont les cas ou le type est vraiment différent d'une API à une autre).

Maintenant, mon avis est que le but d'un moteur est de proposer une interface de haut-niveau, et pas une simple wrapper autour d'une API. Si une fonction haut-niveau doit être traduite complètement différemment en fonction de l'API, il devrait "suffire" de la descendre au niveau du wrapper.

Enfin, pour en revenir à la question originelle, le multi-API rend de très grand services, ne serait-ce que pour vérifier ou se trouvent les bugs
Si un bug est présent sous toutes les API, il y a de bonnes chances pour qu'il soit "plus haut".