Discussion :

[c.aug]

Dans les jeux faits avec peu de moyens, je vois une nette préférence pour OpenGL, ce qui me semble normal parce qu'on va cibler plutôt les smartphoned que le marché du CD-ROM.

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

Enfin du moins c'est ce qui semble le plus évident à priori, enfin si on a en référence un Angry Birds. Maintenant si on part du cadre « amateur », enfin disons qu'on part des moyens d'un Notch, c'est-à-dire de zéro, donc qu'on n'est pas assez riche pour s'offrir trois ou quatre portages, les licences de diffusion qui vont avec, les développeurs spécialistes de chaque OS, ainsi que les douze machines de test, bref envisager sérieusement de faire du jeu smartphone s'il n'y a pas une société avec des moyens derrière c'est impensable.

Donc dans ce cadre là, et après avoir exclu les solutions type Java/middleware, tout ce qu'il te reste c'est de cibler Windows.
Et là donc je ne sais pas si OpenGL est encore un choix judicieux.

Même si OpenGL est plus facile d'utilisation, à chaque ligne de code tapée j'ai peur de tomber sur l'interminable liste des trucs d'OpenGL qui foirent sur Windows. Alors qu'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, et donc à priori le code tapé cause beaucoup moins de risques de planter le GPU.

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.

Qu'en pensez-vous ?

[Kannagi]

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

euh ,tu peux faire de AAA avec OpenGL ,d'ailleurs sur psp c'est OpenGL et sûrement aussi la ps3

Moi je vois aucun souci de faire un jeux avec OpenGL, je utilise personnellement et jamais eu de souci avec, et niveau portage ça l'est.

[c.aug]

euh ,tu peux faire de AAA avec OpenGL ,d'ailleurs sur psp c'est OpenGL et surement aussi la ps3

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

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.

C'est ça qui me bloque... si je fais un truc avec OpenGL ça tournera bien pour ma machine mais je prévois une interminable liste de retours de bugs.

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.

En France j'ai l'impression que les devs plébiscitent OpenGL. Je ne saurais dire si c'est par philosophie "open-source" / "independent coding", ou si ça serait pas plutôt que les entreprises ont du s'abaisser à une basique stratégie de réduction du coût de la main d'oeuvre en choisissant la solution la plus facile. Du coup au final nous on choisit rien, on va là où y'a la demande.

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

Maintenant si on raisonne d'un point de vue d'artisan qui privilégie le travail bien fait sur le boulot à l'arrache... là...

Je reprends l'exemple de angry birds. D'un point de vue commercial c'est un jeu génial car il y'a eu une solide couverture marketing pour le faire cartonner, le tout pour un coût de main d'oeuvre dérisoire. D'un point de vue purement technique maintenant c'est du travail bâclé sans intérêt qui a resucé le tutoriel du jeu de lance pierre pour programmeurs débutants. Si t'as pas la fanfare marketing qui va avec tu vas pas te vendre avec ce genre de jeu, donc, stratégie pas du tout adaptée au cadre indy qui n'a pas les moyens d'une grosse promo, dont le seul capital est la force de ses bras, et qui donc est obligé de se vendre avec des produits d'un autre niveau de qualité (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.

[Kannagi]

Exemple concret de fonctionnalité à problème, la synchro verticale, un truc qui me parait indispensable pour faire un jeu propre

Je suis pas d'accord le contrôle de la vsync est absolument pas nécessaire pour avoir un jeu propre.

Apres si tu cible que Windows tu peux prendre DirectX .

Voila bon j'ai dit juste mon avis, j'utilise OpenGL et pas eu de souci de ce coté.

[c.aug]

Je suis pas d'accord le control de la vsync est absolument pas nécessaire pour avoir un jeu propre.

Même si tu noies le tearing dans des effets de flou ça vaudra jamais la vsync.
La vsync c'est beau. Les jeux sans vsync c'est crade, c'est moche l'image déchirée.

J'ai connu une époque où des jeux sans vsync ça n'existait tout simplement pas, c'était même pas pensable de caler la routine de retracage sur une horreur de timer à la place de l'écran et laisser un affreux tearing, c'était la garantie de se faire lyncher par toute la presse spécialisée et couler le studio.

A une époque on a commencé à négliger ce truc, j'ai trouvé ça hideux visuellement et limite méprisant pour le public.

Pour moi ça fait un argument en faveur de DirectX, la routine d'animation est tout de suite calée sur la vsync, ça marche tout seul, c'est clean. C'est pas une option branlante que tout le monde désactive et remplace par des choses sales avec des millisecondes.

Apres si tu cible que Windows tu peux prendre DirectX .

Voila bon j'ai dit juste mon avis ,j'utilise OpenGL et pas eu de souci de ce coté.

Bah moi non plus j'ai pas eu de soucis avec OpenGL mais c'est un peu normal quand on teste son programme à soi sur sa machine à soi, vu qu'on fait pas tourner les trucs qui plantent sur sa machine à soi.

C'est quand je teste les programmes des autres que y'a des soucis.

[Kannagi]

Même si tu noies le tearing dans des effets de flou ça vaudra jamais la vsync.
La vsync c'est beau. Les jeux sans vsync c'est crade, c'est moche l'image déchirée.

J'ai connu une époque où des jeux sans vsync ça n'existait tout simplement pas, c'était même pas pensable de caler la routine de retracage sur une horreur de timer à la place de l'écran et laisser un affreux tearing, c'était la garantie de se faire lyncher par toute la presse spécialisée et couler le studio.

A une époque on a commencé à négliger ce truc, j'ai trouvé ça hideux et limite méprisant pour le public.

Quoi pour les jeux 2D , je peux te passer plein de jeux 2D fait par SDL animation est super fluide.
Pour les Jeux3D animation ,j'ai pas plus experience dessus mais je fais un jeux en 3D j'ai pas impression que mon jeu est saccadé
ça dépend principalement des FPS si tu fais en sorte que y a 30 fps , animation sera pas du tous saccadé.

[erwanlb]

c'était la garantie de se faire lyncher par toute la presse spécialisée et couler le studio

Sans oublier la pendaison des salariés sur la place publique

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

T'es Terminator toi si tu vois chaque image...

Toc toc....Sarah Connor, créatrice de jeux vidéos à 30fps ? PAN..........

[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]

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'.

[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

[RedGuff]

Bonjour.
De nombreux jeux, très anciens je vous l'accorde, sont compatibles Direct X et OpenGL.
Si vous voulez de la modernité, il existe d'autres solutions : le lancer de rayon en temps réel (expérimental), par exemple, ou les voxels.