Discussion :

[shenron666]

Donc à priori, DirectX c'est plutôt pour l'AAA, OpenGL plutôt pour les jeux de série B.

à priori = idée reçue
vas faire de l'opengl sous linux ou sur console autre que microsoft

au moins avec les trucs de Microsoft, même si la doc est indigeste, on sait qu'on est en terrain ami, c'est plein d'outils qui marchent bien dans Windows

t'inquiètes, il y a aussi plein d'outils qui ne marchent pas comme il faudrait

Voilà donc après avoir tenu compte de ces détails techniques, je sais pas si OpenGL c'est un choix intelligent dans un cadre où on risque guère de sortir de Windows.

directx n'est pas un choix intelligent, c'est un choix de simplicité et de restriction de plateforme
opengl est un choix intelligent, lui au moins est portable, et très utilisé dans le monde professionnel
après si tu te limite à windows... libre à toi, question de goût

Bon mais, le truc, avec les jeux OpenGL sur Windows j'ai toujours eu plein de bugs de carte vidéo (doom3 qui crashe le GPU toutes les 5 minutes, angry birds qui me crashe carrément la machine deux fois avant de réussir à se lancer). Parce que les fabricants de drivers GPU pour Windows ont tendance à négliger la compatibilité OpenGL pour des raisons d'économie.

bizarre, doom3 ne m'a jamais crashé un GPU
quand à angry birds, je ne vois pas le rapport avec opengl...

Exemple concret de fonctionnalité à problème, la synchro verticale, un truc qui me parait indispensable pour faire un jeu propre, dans la doc de OpenGL ils disent "attention c'est pas fiable on sait pas du tout sur quelle machine ça va planter", résultat dans les jeux OpenGL pour windows comme quake3 ou angry birds ils ont viré la vsync et on a un rendu moche avec du tearing.

elle date de quand ta doc opengl ?
quake3 avec le vsync marche parfaitement

En France j'ai l'impression que les devs plébiscitent OpenGL.

tiens, j'avais pas remarqué
tu as vu ça ou ?
les jeux opengl en dehors d'id software ne sont pas légion
la plupart des moteurs (source, unreal) sont opengl + directx

Donc si je raisonne en commercial je choisis OpenGL sans hésitation.

pourquoi ? opengl n'a rien de commercial

C'est pas fluide 30 fps c'est de la vitesse de dessin animé, l'oeil perçoit chaque image.

un dessin animé c'est 15 fps pour percevoir l'animation
30 fps c'est plus qu'assez pour la grande majorité de la population
peu de personnes sont capables de voir la différence entre 30 et 40 fps

Un jeu vidéo fluide c'est impeccablement calé sur la vitesse de l'ecran là tu as vraiment l'illusion que les trucs bougent tout seul tu ne perçois plus les frames. Baisser le truc à 30 fps ça devrait être une option réservée aux épileptiques, et puis ça empêche pas de tracer le tout proprement avec de la vsync.

t'es pas sympa avec les epileptiques, tu dois pas connaitre la maladie pour en parler comme ça

Je viens de l'époque ms-dos, même si le framerate atteignait rarement les 60 de l'ecran et était souvent baissé à 30 voir 15, ça n'existait pas les jeux sans vsync en ce temps, on ne savait pas ce que c'était du tearing, tout le monde faisait du boulot propre. Quand des jeux sans vsync sont apparu à l'époque de cette nouvelle génération de jeux conçus comme des applications windows qui traçaient dans le dibsection au lieu du backbuffer directdraw, on a pleuré haaa bouh haa mes yeux haa.

tu es sûr que tu viens de l'époque ms-dos ?
à l'époque des 386, on ignorait totalement la vitesse de la machine, on avait des jeux qui tournaient à 10fps sur certaines (wing commander)
le même jeu sur un 486 tournait à 40fps
quand au vsync off, ça existait sur certains jeux (epic de did)

[ash.ice.loky]

Ayant fais 5 ans de C++/OpenGL, j'ai du passer à .NET pour raison personnel il y a 3 ans et je me suis essayé à DirectX via SharpDX.

Je reste sous DirectX car je trouve C# très sympa à coder, toutes mes machines sont sous windows, SharpDX est SUPER bien foutu (Honneur à l'auteur).
Et c'est portable sous windows Phone, Windows desktop et Windows RT, en gros ça me suffit.

[shenron666]

DirectX via SharpDX.

intéressant, merci pour l'info
pour le couple C#/OpenGL (et plus) il y a OpenTK qui est très bien

par contre, j'ai oublié de rappeler une chose très importante :
OpenGL est une API d'affichage 2D/3D
et DirectX est une API non seulement d'affichage mais également de son, de périphériques (clavier, souris, joystick), etc...

il faut donc coupler OpenGL avec d'autres bibliothèques telles que OpenAL, SDL, SFML, GLFW, etc... pour retrouver un équivalent de DirectX
c'est ça aussi qui rebute nombre de développeurs

le mieux étant de partir sur un moteur tel que Ogre ou Irrlicht
après tout, pourquoi réinventer la roue ?

[ash.ice.loky]

intéressant, merci pour l'info
pour le couple C#/OpenGL (et plus) il y a OpenTK qui est très bien

C'est vrai OpenTK est un excellent portage.
Son auteur était (est?) très disponible.

Pour Sharpdx il y a quelques tutos ici:
http://sharpdx.org/forum/7-documentation

Montebourg va être content puisqu'il est français!
http://code4k.blogspot.fr/

Au passage, excellent pour les shaders, du même auteur
http://nshader.codeplex.com/

[Kannagi]

il faut donc coupler OpenGL avec d'autres bibliothèques telles que OpenAL, SDL, SFML, GLFW, etc... pour retrouver un équivalent de DirectX
c'est ça aussi qui rebute nombre de développeurs

Je voudrais bien savoir pourquoi cela rebute ?
Je trouve que le couple SDL/opengl , est très bien (gère affichage/le son/périphérique autre).

Personnellement j'utilise Freeglut/opengl et je trouve ça plutôt bien et facile utilisation.

le mieux étant de partir sur un moteur tel que Ogre ou Irrlicht
après tout, pourquoi réinventer la roue ?

Pour plein de raison , pour apprendre , parce que il ne sont pas obligatoirement nécessaire.
Mais j'aime pas vraiment le terme de réinventer la roue , je parlerai de recoder certaine partie , les techniques et algo sont (avec un peu de recherche et lecture de doc) connus.
Connaitre ce qu'on fait on codant son propre 'moteur' on a pas apprendre a connaitre un autre moteur sa doc ect.
De mon exemple personnel j'utilise freeglut donc pas de loader image ,recoder un loader de bmp m'a même pas pris un aprem (juste lire la doc et basta) , pareil pour le loader de smd (qui gère les model 3D+texture + animation squeletal), même si j'ai mis un peu plus de temps pour faire le rendu de animation squeletal , mais c’était très intéressant

Après l'argument 'personnel' c'est qu'ils sont en C++ , je code en C donc pour ma part ce ne sont pas des alternatives 'possibles'.

[dolanor]

Bon je réponds à de vieux post, mais bon.

Ha tiens... je savais pas qu'il y'a des consoles qui s'en servent. Ok.

En fait, plus simplement, en dehors des PCs sous windows et de la console XBox (et sûrement les windows phone 8, mais je ne suis pas sûr), tout le reste des applications 3D fonctionnent sur OpenGL (depuis que Glade a décédé de son absorption par nVidia, il n'y a plus qu'OpenGL ou Direct3D).

Si tu vises le multiplateforme, OpenGL n'est la seule bibiothèque valide, à moins d'avoir les moyens d'avoir une autre équipe spécialisée en DirectX. Mais je verrais plutôt ça comme une perte. Autant tous bosser sur la partie intéressante d'un jeu, à savoir, le jeu, plutôt que diviser les forces en faisant les choses identique mais pour des plateformes différentes.

(exemple http://www.grimrock.net/)

Et là donc.. DirectX (je sais pas s'ils ont fait grimrock avec) , pourquoi pas... financer les portages on en est pas là, on verra bien quand le fric rentrera avec la version windows.

Vu la les systèmes supportés par Grimrock, je dirai OpenGL sans hésitation. ( http://en.wikipedia.org/wiki/Legend_of_Grimrock ).


En fait la plus grande difficulté du portage c'est d'avoir une équipe ayant travaillé sur plusieurs système auparavant et qui connaissent les manière standard de coder. Et non pas être tellement habitué à utiliser tel ou tel système, que des morceaux du jeux seront à revoir pour fonctionner sur un autre système.
En gros, il faut se déshabituer, et après, c'est tout aussi efficace à coder et une recompilation suffit. Après, il y a des spécificités à chaque systèmes et il faut également les connaître, mais ça recouvre des choses spécifiques qui peuvent être abstraite en quelque chose de plus utilisable. En cela les moteurs de jeu sont un avantage, mais cela rajoute souvent une dépendance et d'autres soucis qu'ils faut connaître et analyser.

[shenron666]

Je voudrais bien savoir pourquoi cela rebute ?
Je trouve que le couple SDL/opengl , est très bien (gère affichage/le son/périphérique autre).

ça rebute car il faut multiplier les bibliothèques, avec chacune leur codage, leur apprentissage
voilà le genre de remarque que j'ai eu plus d'une fois

à côté, DirectX c'est Microsoft = valeur sûre du point de vue des entreprises

Pour plein de raison , pour apprendre , parce que il ne sont pas obligatoirement nécessaire.

je suis d'accord, mais pour un projet sérieux, (re)coder son propre moteur demande du temps, et donc de l'argent

Connaitre ce qu'on fait on codant son propre 'moteur' on a pas apprendre a connaitre un autre moteur sa doc ect.

c'est plus rapide en général de t'adapter à un moteur qui a fait ses preuves tels que Unity, Ogre, le moteur de Quake
que de recoder un moteur complet fait maison

le mieux étant de partir d'une base existante comme l'a fait Valve pour HalfLife
ils ont pris le moteur de Quake2, l'on adapté, amélioré, pour qu'il colle à leurs besoins et à la technologie du moment

Après l'argument 'personnel' c'est qu'ils sont en C++ , je code en C donc pour ma part ce ne sont pas des alternatives 'possibles'.

les moteurs de Quake 1 à 3 il me semble sont en C, au cas où ça t'intéresserait

[Kannagi]

ça rebute car il faut multiplier les bibliothèques, avec chacune leur codage, leur apprentissage
voilà le genre de remarque que j'ai eu plus d'une fois

Ok , pour ma part ça me semble toujours un peu étrange , je veux dire qu'on apprend un lib il est facile en apprendre une autre , faut juste regardé le fonction/méthode qui fait le truc a peu prés similaire.
On ayant testé SDL , freeglut,opengl,SFML android canvas (et opengl) , jamais eu un très long apprentissage ( 1 semaines max) et leur codage sont assez similaire grosso modo créer une fenêtre ,la taille ,afficher/charger une image /ou ,découper, comment ect.

c'est plus rapide en général de t'adapter à un moteur qui a fait ses preuves tels que Unity, Ogre, le moteur de Quake
que de recoder un moteur complet fait maison

C'est vrai mais cela dépend beaucoup de nos ambitions ,le plus long a codé c'est la qualité du rendu (effet) et le online.
On enlevant ces deux paramètres le temps de codage est correct , on est début mai donc 5 mois pour faire un moteur fonctionnel c'est correct en terme de temps.

les moteurs de Quake 1 à 3 il me semble sont en C, au cas où ça t'intéresserait

Je regarderais plus le moteur de Quake 3 , le premier je le trouve assez horrible , des glbegin ,pas animation squeletal, des variables global (quoique sur tous leur moteur y en a), un code assez bordélique, .
Mais bon il doit avoir quand même quelque code bon a en tirer.

[shenron666]

Ok , pour ma part ça me semble toujours un peu étrange , je veux dire qu'on apprend un lib il est facile en apprendre une autre , faut juste regardé le fonction/méthode qui fait le truc a peu prés similaire.
On ayant testé SDL , freeglut,opengl,SFML android canvas (et opengl) , jamais eu un très long apprentissage ( 1 semaines max) et leur codage sont assez similaire grosso modo créer une fenêtre ,la taille ,afficher/charger une image /ou ,découper, comment ect.

je suis totalement d'accord avec toi
mais pas facile de convaincre une boite surtout quand la personne en face ne maîtrise pas le sujet

Je regarderais plus le moteur de Quake 3 , le premier je le trouve assez horrible , des glbegin ,pas animation squeletal, des variables global (quoique sur tous leur moteur y en a), un code assez bordélique, .
Mais bon il doit avoir quand même quelque code bon a en tirer.

les animations du premier comme du second sont obsolètes bien que facile à coder
le 3 est clairement plus avancé mais accuse tout de même son age au niveau des animations
ils ont libéré le code source du moteur de doom 3, plus récent, mais codé en C++

j'ai vu aussi que le code source du source engine (half life) avait fuité
mais je pense qu'il est en c++ bien que basé sur id tech 2 (quake2)

lister les moteurs open source et les "noter" en fonction du côté éducatif du code source pourrait être intéressant
les moteurs en langage objet / non objet, le code plus ou moins difficile à appréhender, les technologies embarquées, etc...

[Kannagi]

les animations du premier comme du second sont obsolètes bien que facile à coder
le 3 est clairement plus avancé mais accuse tout de même son age au niveau des animations
ils ont libéré le code source du moteur de doom 3, plus récent, mais codé en C++

Oui les premiers sont obsolète même pour époque , je pense , si on regarde par exemple virtua fighter 1 et 2 (surtout le 2) je doute qu'il utilisais la technique de keyframe (même impossible les persos au 2 font facile 700 polygones mini).
Mais cela m’intéresse de savoir comment il font (surtout pour optimisation en fait, ,je pré-calcul les cos/sin mais si y a d'autre technique ça m’intéresse =D).

lister les moteurs open source et les "noter" en fonction du côté éducatif du code source pourrait être intéressant
les moteurs en langage objet / non objet, le code plus ou moins difficile à appréhender, les technologies embarquées, etc...

ça serait une bonne idée

[Invité]

J'admire les développeurs qui font du multi-plateforme, mais je les plains tellement ils doivent s'arracher les cheveux.

Désolé de vous contredire, mes cheveux vont très très bien, je suis responsable du support des moteurs au sein de la fondation JogAmp, c'est moi qui ai initié le portage de Java3D vers JOGL 2.0 ainsi que celui de Xith3D, Ardor3D, JMonkeyEngine 3, ... Je ne vais pas relancer la discussion au sujet de Java puisqu'ici on va me sortir les mêmes arguments bidons qu'en 2002 + ceux qui sont apparus entre temps pour détourner l'attention des gens sur les problèmes de sécurité des OS de Microsoft et des foyers de spywares que sont Facebook et Google (il faut bien vendre des anti-virus et promouvoir de nouvelles APIs pour les RIA quitte à raconter n'importe quoi sur les acteurs déjà en place depuis le milieu des années 90).

C'est vrai OpenTK est un excellent portage.

dont le binding OpenGL est bien plus lent que ceux disponibles en Java (facilement 30 à 70% plus lent et personne n'avait voulu m'expliquer pourquoi quand j'avais posé la question).

[shenron666]

[OpenTK] dont le binding OpenGL est bien plus lent que ceux disponibles en Java (facilement 30 à 70% plus lent et personne n'avait voulu m'expliquer pourquoi quand j'avais posé la question).

ah mer**
c'est toujours d'actualité sur la version la plus récente ?
tu connais une autre bibliothèque équivalente et plus performante ?

ça serait une bonne idée

tiens, je me suis souvenu de ça :
http://devmaster.net/devdb/engines

[c.aug]

J'attire votre attention sur le genre de choses que m'enseigne ma principale source d'information: Google.

http://www.ask.com/answers/75460561/...n-same-for-1-3

http://answers.microsoft.com/en-us/w...9-7dae76226684

http://newsandguides.com/angry-birds...not-supported/

http://www.angrybirdsnest.com/forum/...ows-8-users/p1

http://social.msdn.microsoft.com/For...-7059824e01e2/

Voilà à quels mauvaises surprises on doit se préparer quand on veut faire l'économie d'un développeur directx.

A un moment ou un autre on a besoin d'eux.

Et encore là le jeu que je cite n'est pas un jeu indie, rovo c'est la politique contraire, on mise tout sur le marketing et on sacrifie le budget de nourrir des développeurs (d'ailleurs ils sont passés sur unity pour nourrir encore moins de développeurs) c'est pas ce genre de modèle économique qui va relancer l'embauche. Chez eux on est donc dans une logique purement commerciale qui fait primer la productivité sur la qualité, on est donc aux antipodes des contraintes de l'indie, donc oui, leurs portages windows foireux c'est typiquement l'exemple où on choisit openGL pour des raisons commerciales: pour réduire le coût de la main d'oeuvre, et tant pis si on fait de la merde c'est pas grave il y'aura toujours des pigeons qui prennent ce qu'il y'a en vitrine parce qu'ils sont trop feignants pour aller chercher de la qualité dans l'arrière boutique. Si je veux appliquer cette politique du travail minimum je prends un moteur tout fait et je me contente de faire du graphisme.

Chez les indie c'est l'inverse, faut avoir pondu un programme qui tienne la route avant d'espérer décrocher un budget promo.

Or plutôt qu'un programme qui marche mal partout, je préfère un qui ne marche que sur windows mais qui marche bien sur windows.

Je lis aussi des gens qui parlent de l'idtech engine, mais qui oublient de mentionner que ce moteur a depuis longtemps la version directx de son moteur graphique, parce que opengl et les dernières versions de windows ça fait 2.

Et sinon j'ai lu je ne sais plus qui dire que les lib opengl-sdl-openal "rebuteraient" parce que faut apprendre plein de librairies...

Mais c'est pire avec directx ! Directx ça n'est pas une librairie, c'est plein de librairies. Aujourd'hui un dev doit connaître au minimum deux versions de la lib dx3d, les deux lib audio, et puis aussi la lib clavier et la lib souris.

Et c'est bien plus galère à apprendre que les solutions "standard" qui ont une grosse communauté active sur internet, on trouve toutes les infos qu'on veut en trois clics sur google, et quand tu poses une question technique un peu pointue sur nos forums, si ça concerne opengl-openal-sdl-etc t'as la réponse en cinq minutes, alors que si ça concerne dx3d ou xaudio t'as au pire le silence en guise de réponse, au mieux le codeur directx aigri du coin qui te conseille de te démerder tout seul avec l'horrible doc indigeste de microsoft parce que lui non plus y'a personne qui a voulu l'aider. Bref: l'esprit d'entraide dans la communauté open-source ça rend ces solutions beaucoup plus accessibles, beaucoup plus rapide à apprendre que directx... et puis elles sont bien plus simple en plus, ce que j'arrive à faire en une soirée et 50 lignes de code avec sdl-opengl, pour faire la même chose avec directx j'en ai pour une semaine, y'a 10 000 lignes à pisser.

Chez les dev indé on manque de bras sur directx, et chercher à se rassurer en inventant des fables selon lesquelles directx ça sert à rien, ça ne fait qu'aggraver le problème puisqu'on décourage les mecs dont on aurait besoin.

Alors je ne vois pas en quoi on fait du tort à la communauté des indie en se farcissant la tâche ingrate de mettre les mains dans l'épouvantable usine à gaz de microsoft, parce que y'a bien un moment où un maso va devoir se farcir ce sale boulot que personne ne veut faire.

[dragonjoker59]

J'attire votre attention sur le genre de choses que m'enseigne ma principale source d'information: Google.

http://www.ask.com/answers/75460561/...n-same-for-1-3

http://answers.microsoft.com/en-us/w...9-7dae76226684

http://newsandguides.com/angry-birds...not-supported/

http://www.angrybirdsnest.com/forum/...ows-8-users/p1

http://social.msdn.microsoft.com/For...-7059824e01e2/

Voilà à quels mauvaises surprises on doit se préparer quand on veut faire l'économie d'un développeur directx.

Ce problème n'est pas très violent, car la solution de chacun a été ... d'installer les drivers de sa carte graphique.

Certes pour un jeu comme Angry Birds ça peut surprendre, mais quel gamer n'a pas ses drivers à jour ?

Ensuite pour moi le problème ne vient pas forcément d'OpenGL mais du fait que Microsoft n'a pas mis à jour sa DLL d'OpenGL depuis la version 1.1, c'est à dire Mathusalem.
Après il est facile d'intégrer Dx11 sur Windows Seven et de demander aux constructeurs de carte graphique d'implémenter les spécif. OpenGL (donc de la 1.2 à la 4.3, yeehaa !), puis de venir dire "Vous avez vu ? Au moins avec DirectX on n'a pas ces problèmes :-P".

'Fin bon, pour moi il n'y a pas de réelle différence dans les fonctionnalités proposées par OpenGL ou par DirectX, je n'ai cependant pas été creuser au plus loin de ce que chacun propose.
Tout ce que je sais donc, c'est qu'au final j'ai plus de facilités à intégrer des nouvelles fonctionnalités OpenGL que de passer (par exemple) mon renderer DirectX de Dx9 à Dx11 (sans avoir utilisé le pipeline fixe de directx 9) ...

Je pense vraiment que c'est à la préférence de chacun. Le "polishing" pour Windows avec Direct3D, je n'y crois pas trop.

[c.aug]

Ce problème n'est pas très violent, car la solution de chacun a été ... d'installer les drivers de sa carte graphique.

Ouep certes les accrocs gl/win on trouve souvent la solution mais ça reste pénible pour le joueur d'avoir plein de bordel à installer.

Si on peut leur éviter ces petits désagréments, c'est mieux.

En fait à la base moi je vois pas l'intérêt de se lancer dans l'aventure du projet indie si c'est pour se farcir les mêmes conditions de travail que dans les boîtes qui appliquent la politique du travail bâclé et de l'embauche minimale de devs.

Ce qui est agréable dans les jeux indie (enfin, les bons) c'est de voir que justement les dev se sont laissé le temps de faire les choses bien et qu'ils ont peaufiné des choses habituellement bâclées dans les "jeux à rentabilité".

[c.aug]

[edit: je le refais en abrégé]

Un indie ça fait rarement un jeu tout seul (on n'est plus sur ms dos en 90) et ça préfère se concentrer sur une partie de la chaine de fabrication. Pour ceux qui ont plus un profil de programmeur graphique que de game developer, c'est souvent plus intéressant de créer un "tool" comme sdl-allegro-sfml-ogre-etc, que de faire les jeux avec, et comme ces projets sont connus pour souffrir d'un manque de bras côté directx, c'est pas très malin de décourager ses petits camarades à se taper la tâche ingrate des horribles lib microsoft, à fortiori dans un projet qui prétend régler la partie bas niveau...

On le sait que microsoft c'est des méchants qui n'en font qu'à leur tête au lieu d'utiliser les standards comme le reste du monde, on le sait que leur librairie est un problème au lieu d'être une solution, c'est une horreur ultra compliquée qui fait chier tout le monde, mais loin de m'inspirer du mépris envers les codeux directx, au contraire ça m'inspire davantage de respect parce que c'est eux qui se tapent le sale boulot que personne ne veut faire.

[stardeath]

[edit: je le refais en abrégé]c'est pas très malin de décourager ses petits camarades à se taper la tâche ingrate des horribles lib microsoft, à fortiori dans un projet qui prétend régler la partie bas niveau...

encore faut il le montrer que les lib microsoft sont horribles, et encore plus quand elles sont livrées avec des samples à ne plus savoir quoi en faire.

parce que c'est bien gentil opengl, soit disant portable, soit disant ..., soit disant surtout que il n'y a pas de samples, alors heureusement qu'il y a nehe, g-truc et d'autres qui en font des samples, parce que sinon, opengl, comme beaucoup de soft sur la toile, serait juste une lib sans aucune finition.

Mais c'est pire avec directx ! Directx ça n'est pas une librairie, c'est plein de librairies. Aujourd'hui un dev doit connaître au minimum deux versions de la lib dx3d, les deux lib audio, et puis aussi la lib clavier et la lib souris.

lol

Et c'est bien plus galère à apprendre que les solutions "standard" qui ont une grosse communauté active sur internet, on trouve toutes les infos qu'on veut en trois clics sur google, et quand tu poses une question technique un peu pointue sur nos forums, si ça concerne opengl-openal-sdl-etc t'as la réponse en cinq minutes, alors que si ça concerne dx3d ou xaudio t'as au pire le silence en guise de réponse, au mieux le codeur directx aigri du coin qui te conseille de te démerder tout seul avec l'horrible doc indigeste de microsoft parce que lui non plus y'a personne qui a voulu l'aider. Bref: l'esprit d'entraide dans la communauté open-source ça rend ces solutions beaucoup plus accessibles, beaucoup plus rapide à apprendre que directx... et puis elles sont bien plus simple en plus, ce que j'arrive à faire en une soirée et 50 lignes de code avec sdl-opengl, pour faire la même chose avec directx j'en ai pour une semaine, y'a 10 000 lignes à pisser.

faut peut être arrêter 5 minutes.

Chez les dev indé on manque de bras sur directx, et chercher à se rassurer en inventant des fables selon lesquelles directx ça sert à rien, ça ne fait qu'aggraver le problème puisqu'on décourage les mecs dont on aurait besoin.

Alors je ne vois pas en quoi on fait du tort à la communauté des indie en se farcissant la tâche ingrate de mettre les mains dans l'épouvantable usine à gaz de microsoft, parce que y'a bien un moment où un maso va devoir se farcir ce sale boulot que personne ne veut faire.

c'est peut être ça aussi qui fait que les codeurs directx restent dans leur coin, y a tellement de bullshits qui circulent sur directx, que souvent je me demande si ce n'est pas juste de l'anti-microsoft primaire.

en tout cas c'est sur que je vais certainement pas faire de l'opengl pour le bien de la communauté.

bref en 3 posts et demi, on est passé de discussion un peu technique à commérage de bistro... bravo.

ps :

Ensuite pour moi le problème ne vient pas forcément d'OpenGL mais du fait que Microsoft n'a pas mis à jour sa DLL d'OpenGL depuis la version 1.1, c'est à dire Mathusalem.
Après il est facile d'intégrer Dx11 sur Windows Seven et de demander aux constructeurs de carte graphique d'implémenter les spécif. OpenGL (donc de la 1.2 à la 4.3, yeehaa !), puis de venir dire "Vous avez vu ? Au moins avec DirectX on n'a pas ces problèmes :-P".

c'est le boulot de khronos et des constructeurs de cg ça, certainement pas de crosoft.

[moldavi]

Bonjour.

Désolé de vous contredire, mes cheveux vont très très bien, je suis responsable du support des moteurs au sein de la fondation JogAmp, c'est moi qui ai initié le portage de Java3D vers JOGL 2.0 ainsi que celui de Xith3D, Ardor3D, JMonkeyEngine 3)

Pas de souci pour moi. Vous noterez que j'ai employé le conditionnel...
Vous vous sentez certainement à l'aise dans le portage multiplateforme, mais est-ce une généralité ?

Vous maîtrisez les OS windows/Linux/Apple/etc... tout cela à la fois ? Vous n'avez jamais rencontré de difficulté de portage ?

Cela n'engage que moi, mais je n'aime pas le bidouillage informatique qui consiste à avoir un Framework, qui soi-disant tourne sur toutes les plateformes à la perfection (la perfection n'existant pas déjà en monoplateforme). Certes c'est très ambitieux et très louable (c'est pour cela que je suis admiratif), mais le résultat je le connais. Faire tourner un cube dans une fenêtre Web, ça doit marcher partout. Dès que l'on veut faire des choses qui sortent du commun, ben c'est là que le multiplateforme coince.

Cela ne veut pas dire qu'en monoplateforme ça ne coince jamais, c'est juste que c'est plus simple à résoudre ou à contourner. En multiplateforme, il faudra qu'une âme charitable résolve le problème. Quand c'est possible.

Imaginons un jour un SDK multiplateforme parfait : perf 100%, zéro bug. Le lendemain, Bim... Mise à jour de windows, mise à jour de Linux, Mise à jour d'Apple, des tablettes, des Box, des portables... Tout à refaire. Je maintiens, je suis admiratif.

Après, n'interpréter pas mes propos comme du dénigrement du multiplateforme. J'ai très bien conscience que cela rend service à beaucoup de monde. A chaque choix, ses avantages et ses inconvénients. Faites votre choix selon votre problématique/contrainte/budget/philosophie/etc...

... Je ne vais pas relancer la discussion au sujet de Java puisqu'ici on va me sortir les mêmes arguments bidons qu'en 2002 + ceux qui sont apparus entre temps pour détourner l'attention des gens sur les problèmes de sécurité des OS de Microsoft et des foyers de spywares que sont Facebook et Google (il faut bien vendre des anti-virus et promouvoir de nouvelles APIs pour les RIA quitte à raconter n'importe quoi sur les acteurs déjà en place depuis le milieu des années 90.

Là je suis largué. Je ne comprends pas le rapport avec la discussion.

PS: ce post est passé de message classique, à débat, puis résolu, et maintenant actualité...

[c.aug]

C'est marrant humainement comme expérience d'avoir un avis NEUTRE. Que ça soit de la part des pro-dx comme des pro-gl qui chacun crachent sur le produit d'en face, ils t'en mettent plein la gueule pour te châtier de pas avoir choisi leur camp.

Bah je vais les mettre d'accord, le point de vue des gars qui dégueulent sur une techno parce qu'ils ont pas envie ou pas le temps d'apprendre à s'en servir, c'est généralement un assemblage de mauvaise foi et d'attaques ad hominem, donc c'est pas intéressant.

Moi ça m'intéresse pas de faire la guerre. Si on fait bien les choses on doit faire une version windows avec dx, et les autres versions avec gl.

Donc on a besoin des deux librairies donc pour moi jouer à la guerre entre les deux outils n'a aucun intérêt.

parce que c'est bien gentil opengl, soit disant portable, soit disant ..., soit disant surtout que il n'y a pas de samples, alors heureusement qu'il y a nehe, g-truc et d'autres qui en font des samples, parce que sinon, opengl, comme beaucoup de soft sur la toile, serait juste une lib sans aucune finition.

Et au lieu de ça, c'est juste la lib de rendu gpu obligatoire sur 75% des os.
Et s'il n'yavait pas les samples de nehe, évidemment, bien sûr, linux, macos, ios, android utiliseraient tous directx.

Oui et au lieu de ça c'est juste la lib gpu de 75% des os.
c'est peut être ça aussi qui fait que les codeurs directx restent dans leur coin, y a tellement de bullshits qui circulent sur directx, que souvent je me demande si ce n'est pas juste de l'anti-microsoft primaire.

La mauvaise foi anti-microsoft primaire a une raison d'être: le manque de temps, ou la flemme. C'est plus facile avec openGL, alors f@k 8i11 G@t3z.





Bon mais ça me fatigue moi la guerre opengl-dx.

Les gens qui défouraillent sur la librairie d'en face n'ont pas compris qu'ils règleront rien comme ça.

La seule façon de régler le problème c'est qu'on a besoin des deux, c'est tout. Les dx et les gl ils sont sensés travailler ensemble au lieu de se taper sur la tronche.

Dans un studio qui fait du multiplatform il faut bien des dev dx et des dev gl. Imaginez s'ils commencent à jouer à la bagarre du mon-os-et-ma-lib-ont-la-plus-grosse, que les codeux gl commencent à râler que l'équipe dx est une perte de fric inutile pour la boîte et qu'il faudrait tous les foutre à la porte, vous pouvez travailler dans ces conditions vous ?

L'objet du topic n'est pas de faire un ènime gros troll ouais super on va jouer à la guerre dx/gl, tirez à vue sur ceux d'en face. Je parlais dans le cas du projet indie qui est démarré sur windows. Il faut choisir une des deux lib pour commencer. En général on prend opengl, est-ce un bon choix.

Si je choisis openGL par feignantise ou par manque de temps (ou par coolitude puisque manifestement chez les dev dx ils sont trois fois plus aigris), bah je le dis au lieu de jouer au rebel anti-microsoft.

[stardeath]

C'est marrant humainement comme expérience d'avoir un avis NEUTRE.

tes derniers posts n'étaient pas particulièrement neutre.

si tu veux être neutre, voilà je pense le propos :

- certes opengl est utilisé sur beaucoup de plateforme mais à chaque fois ce n'est soit pas la même version, ou pire la même variante. opengl 3 ou 4 selon l'opengl de pc "de bureau" et pire opengl es 1 ou 2 pour les terminaux mobiles, et des variantes plus ou moins exotiques pour les consoles de salon.

le support sur les os dépendent presque totalement des constructeurs de cg, khronos servant globalement de décoration et officiellement seul la spec complète est fournis.

la source de samples étant seulement la communauté, les constructeurs de cg sortant seulement une fois de temps en temps une démo.

api 2D/3D uniquement, le reste est à puiser dans des libs supplémentaires.

- directx, restreint aux os windows, 2 versions majeures pour cibler cette branche d'os, 9 et 11, plus les versions exotiques pour consoles. (attention, je ne parle pas de windows phone parce que je ne sais pas ce que ça utilise comme version de directx, à froid je dirai surement un dx11 en compatibilité 9)
api sous l'égide totale de microsoft, ne prenant pas en charge toutes les fonctionnalités des cartes graphiques mais seulement un pool plus ou moins commun.

support, je pense, assez poussé au cul par microsoft. pas de spec complète fournis.

grandes quantités de samples fournis ainsi que tuto, mais doc pas forcément très exhaustive ni très compréhensible.

api pas seulement 2D/3D, gestion des maths 3D ainsi que le chargement des textures, et un format (ou 2) mal documenté de modèles 3D, input utilisateur (dinput ou xinput), musique (xaudio) etc.
api plus ou moins cohérente, certains modules étant carrément abandonnés (dinput)


ce que j'en conclue, c'est que opengl ou directx, c'est surtout une question de préférence d'api (plutôt c en opengl et plutôt objet com en dx) et non plus en terme de fonctionnalités (opengl4 et dx11 c'est bonnet blanc et blanc bonnet)
et en tout cas certainement pas en portabilité, vu que dans les 2 cas, faudra se limiter sur les fonctionnalités pour avoir un code strictement identique.