A l'époque où je faisais de la 3D, il m'est rapidement apparu que DirectX est une grosse -bip-.
Sous OpenGL, les appels aux fonctions graphiques se font petit à petit avec des appels à la librairie, alors qu'avec DirectX il faut se créer des buffers d'exécution, remplir les buffers et demander à DirectX d'interpréter les buffers... Evidemment, Microsoft nous facilite la tâche en proposant plein de macros C pour remplir les buffers d'exécution mais il n'y a rien de plus chiant pour débugger (il faut passer son temps à jongler avec des pointeurs, dès qu'on veut rajouter des intstructions dans un buffer, il faut revoir l'allocation de ce buffer...).
A l'époque, j'étais tombé sur un document de chez SGI qui montrait comment faire un cube qui tourne en 3D, avec code DirectX et code OpenGL; ben, le code DirectX était bien plus gros (mais faut dire qu'ils utilisaient GLUT qui fait gagner beaucoup de lignes de code en OpenGL). Cela aurait été étonnant qu'ils nous disent le contraire!
[^] # Re: Ouais ça depend...
Posté par pas_moi . En réponse à la dépêche Sortie de la specification OpenGL 1.3. Évalué à 2.
Sous OpenGL, les appels aux fonctions graphiques se font petit à petit avec des appels à la librairie, alors qu'avec DirectX il faut se créer des buffers d'exécution, remplir les buffers et demander à DirectX d'interpréter les buffers... Evidemment, Microsoft nous facilite la tâche en proposant plein de macros C pour remplir les buffers d'exécution mais il n'y a rien de plus chiant pour débugger (il faut passer son temps à jongler avec des pointeurs, dès qu'on veut rajouter des intstructions dans un buffer, il faut revoir l'allocation de ce buffer...).
A l'époque, j'étais tombé sur un document de chez SGI qui montrait comment faire un cube qui tourne en 3D, avec code DirectX et code OpenGL; ben, le code DirectX était bien plus gros (mais faut dire qu'ils utilisaient GLUT qui fait gagner beaucoup de lignes de code en OpenGL). Cela aurait été étonnant qu'ils nous disent le contraire!