Discussion :

[ash.ice.loky]

intenant il y a le windows api code pack, ça résout le problème.

Cela en créé plus que ca n'en résout.
Quelques wrapper sont apparus tel que MDX, managed DirectX, SlimdX mais seulement ce dernier est encore viable.

SlimDX continu d'évoluer, il est compatible DX 9/10/11.

Dire que le code est plus lourd, je demande pourquoi. Le C# avec son framework propose de vrai innovation tel que LINQ, ENTITIES, LAMBDA, WPF, WCF, ..., le tout avec visual studio permet de développer assez rapidement.

SlimDX est complétement compatible avec les exemples du SDK C++.
Question rapidité certain dise que l'on a une pertes d'environ 5%, je veux bien les croire, personnellement mes portages ne m'ont rien fait perdre.

Tout ca pour dire qu'il ne faut pas tout ramener à C++, certain voudrons faire du python choisirons donc OGL, mais d'autre démarre la programmation ou font cela par plaisir sur leur temps libre et préfère le gain de temps plutôt que la performance (et encore).

Pour moi si C++ reste encore la référence c'est que les développeur actuel ne jure que par lui et que les outils, framework et moteur existant sont développé en C++, mais cela change.

[stardeath]

Cela en créé plus que ca n'en résout.

est ce que tu peux développer, un wrapper fournis par microsoft devrait être une bonne nouvelle pourtant, non?

[ash.ice.loky]

On aurait pu le croire en effet.

http://www.gamedev.net/community/for...opic_id=545037

Et plus précisément ici

http://ventspace.wordpress.com/2009/...s-it-any-good/

[oxyde356]

l'interface OO pour manipuler ça ne sert pas à grand chose en soit.

Ah je t'assure que l'API Windows agrémentée des MFC ça n'a plus rien à voir !
Le confort n'est pas du tout le même et il ne serait pas non plus le même si OpenGL avec une couche objet mais toutes les bases doivent rester en C pour les raisons évoquées précédemment.

[stardeath]

Ah je t'assure que l'API Windows agrémentée des MFC ça n'a plus rien à voir !
Le confort n'est pas du tout le même et il ne serait pas non plus le même si OpenGL avec une couche objet mais toutes les bases doivent rester en C pour les raisons évoquées précédemment.

ça je sais XD mon message est juste là pour dire que si c'est pour mettre de l'objet sans que ça serve plus qu'à écrire mon_objet.ma_méthode() ça ne sert strictement à rien.

On aurait pu le croire en effet.

http://www.gamedev.net/community/for...opic_id=545037

Et plus précisément ici

http://ventspace.wordpress.com/2009/...s-it-any-good/

mouais bof ça ressemble à tout discours que ferait un développeur quand un autre produit "concurrent" sort, sans intérêt.

[oxyde356]

Bah c'est à ça que servent les MFC pour l'API Windows, et c'est bien pratique, que ça soit niveau sécurité comme confort, ça serai un plus en OpenGL mais surement plus difficile à maintenir.

[raphchar]

Pour moi si C++ reste encore la référence c'est que les développeur actuel ne jure que par lui et que les outils, framework et moteur existant sont développé en C++, mais cela change.

Je ne suis pas d'accord sur le fait qu'on ne jure que par lui, mais c'est une bonne chose qu'il reste une référence, ça facilite la communication. C'est comme s'il ne fallait aucune langue de référence dans le monde. S'il y a trop de langage; autant retourner au binaire, on y comprendra mieux. Je ne suis pas contre les avancées, mais je ne suis pas pour avoir une multitude de langages. Autant les améliorer.

[stardeath]

je dis pas le contraire, mais visiblement, et depuis le temps que les gens demandent de l'objet dans opengl, ça a pas l'air de convaincre les instances dirigeantes.

[oxyde356]

Bah en même temps c'est vrai que je préfère qu'OpenGL évoluent en terme de fonctionnalités plutôt qu'en ajout d'une couche objet ^^

[Invité]

Après des années d'expérience en OpenGL, je crois que le principal problème est la différence de qualité d'implémentation !
C'est bien simple, la manière la plus pratique d'être compatible est encore malheureusement de s'en tenir au fixed pipeline. Ou alors d'utiliser du middleware, ou d'être nombreux et d'avoir du temps.

Les drivers mentent carrément. Les informations utiles pour la vraie compatibilité ne sont disponibles quasiment nulle part. Il faut tester sur toutes les cartes, même dans la même gamme

Alors que toutes les cartes supportent DirectX 9 de manière plutôt correcte... L'inertie de certains constructeurs il y a quelques années nous maintient à l'âge de pierre. Et visiblement il n'y a pas de validation poussée pour permettre à un constructeur d'annoncer OpenGL x.y

Le fait qu'OpenGL ait un état aussi gros n'arrange rien, il oblige à dupliquer plus ou moins cet état dans le code client, histoire de minimiser les appels, et alors on risque la désynchronisation entre l'idée qu'on se fait de l'état et ce qu'il en est vraiment... Le principe "je binde un objet pour l'utiliser", c'est tout simplement débile.
La séparation entre l'état Sampler et l'état Texture n'est de plus énoncée clairement nulle part...

En tout cas j'ose espérer que côté DirectX c'est mieux.

[oxyde356]

En tout cas j'ose espérer que côté DirectX c'est mieux.

Du coté compatibilité oui, c'est plus clair forcément vu que le gros des consommateurs de cartes graphiques sont les joueurs, les industriels ont tout intérêt à jouer franc jeu avec microsoft, par contre pour tout le reste niveau implémentation c'est du pareil au même à peu de choses prêt.