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

[c.aug]

C'est pas fluide 30 fps c'est de la vitesse de dessin animé, l'oeil perçoit chaque image. 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.

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.

J'en ai fait des jeux sans vsync (dans un contexte où je n'avais pas le choix) et à chaque fois je trouvais le rendu hideux et j'avais honte et je me sentais sale.

Bon je suis un peu extrêmiste avec ma vsync, j'avoue qu'avec les écrans de maintenant l'effet de flou corrige assez bien le tearing si tu choisis des vitesses entre 30 et 50 fps... mais ça remplacera jamais le rendu parfait que permet la vsync.

[Kannagi]

Ben j'ai pris exemple de 30 fps ,déjà je maintiens que certain jeux sont fluide a 30 fps , ça sert complètement a rien de foutre 60 fps si t'es animations sont sur 2 ou 3 frames, quand c'est trop rapide c'est moche (pas le temps analyser animation surtout en 2/3 frame , alors la solution c'est afficher plusieurs fois la même animation du coup le 60 fps sert plus a grand chose.
Et puis rien n’empêche de caler les FPS a 60 ,juste que en général je met du 30 fps ,inutil de consommer plus de CPU pour afficher la même image (surtout en 2D) , mais ça peut etre aussi en 3D , tous dépend de animation.

[c.aug]

Ca dépend. On peut se contenter de 30 fps, en vue 1st ou 3rd person ça pénalise encore pas trop, mais en vue latérale avec un scroll qui va vite ça commence à faire super moche. 30 fps ça fait la même vitesse qu'une vidéo, c'est suffisant pour jouer, mais, si tu veux une vraie fluidité parfaite c'est la vitesse de l'ecran qu'il faut.

Bon et sinon je dramatise peut-être un peu... chez moi la vsync opengl elle marche très bien, j'utilise le code qui l'active dans windows, elle n'est théoriquement pas sensée planter sur 80% des combinaisons windows/gpu... MAIS... le petit détail qui me bloque c'est le warning dans la doc "attention il est possible que les drivers vidéo soient un peu bâclés à cet endroit, faudra pas pleurer si ça vous pète à la gueule"

La doc d'opengl ça donne envie de jeter windows par la fenêtre et de programmer pour des machines et des os qui sont conçus uniquement pour opengl.
Quand tu target windows c'est assez inconfortable.

[Kannagi]

Je suis d'accord ,je dis pas que 30 fps est idéal , 60 fps est quelque fois obligatoire pour certain jeux (je pensa notamment aux jeux de combat).

Mais bon pas besoin d'un control de la vsync , un control de fps a 60 suffira largement.

Apres c'est vrai que windows et opengl ça fait deux , mais tous depend de ce que tu veux faire , bon certain me diront que faut pas utiliser la pipeline fixe opengl , mais opengl 1.4 marche sans souci sur toute les machines ,sauf si tu as ambition de faire un rendu plus 'beau' (oui je trouve pas beau les effets de flou par exemple ).
Mais minecraft était assez basic niveau rendu ça l'a pas empêchè de marcher , je viens de faire une démo d'un jeu , les retours que j'ai eu sont que ça fait un rendu psx/ps2 (plus ps2) , je je trouve que c'est correct , la ps2 étant pas moche perso , et je l'ai fait avec opengl 1.1 =P.

Après si tu trouve opengl pas satisfaisant rien t’empêche de le faire avec directX.

[moldavi]

Bonjour.

DirectX ou OpenGL, le choix est plutôt simple.

Si tu souhaites faire un programme multi-plateforme, sans écrire 36 versions de ton programme (Windows, Linux, Apple, Console), alors c'est OpenGL.

Si ton programme est uniquement destiné à Windows, alors c'est DirectX. Mais même dans ce cas là, tu pourrais choisir OpenGL, tout simplement parce que tu es plus à l'aise avec cette API.

Il faut jauger les avantages/inconvénients, selon le projet.

Mon choix personnel, c'est DirectX, HLSL, Visual Studio, Cuda pour le multi GPU (je n'ai que des cartes NVidia).

Pourquoi ce choix ?

Il y a plein de raisons mais j'abrège :

je considère qu'être expert dans toutes ces technologies est hors de portée d'un cerveau humain. Ce qui m'intéresse, ce n'est pas de bidouiller 50 frameworks, c'est d'en maîtriser 1. Chacun sa philosophie.

J'admire les développeurs qui font du multi-plateforme, mais je les plains tellement ils doivent s'arracher les cheveux. Et les standards ny changent rien : chaque OS a ses spécificités, et adapter le standard relève souvent de la bidouille (contre-performant donc). Il n'y a quà voir les navigateurs, malgré les standards, les développeurs web s'arrachent les cheveux. Leurs pages web ne s'affichent pas de la même façon selon le navigateurs. Bidouille sur bidouille pour que ce soit correct.

Ce n'est pas ma conception de l'informatique. Déjà que même en me basant sur un seul OS/Framework, je suis parfois obligé de bidouiller...

Bref j'ai fait mon choix. A toi de faire le tien.

[c.aug]

60 fps est quelque fois obligatoire pour certain jeux (je pensa notamment aux jeux de combat).

Oui c'est un bon exemple. Tout ce qui est basé sur un déplacement latéral de caméra c'est pas terrible sous la vitesse écran.

Tous les jeux 2d donc. Le portage de mario en javascript là (http://www.rawrbitrary.com/arcade/in...bros-in-html5/) tourne environ à 30 fps et ça se voit, ça fait mal aux yeux, c'est pas le beau mario fluide des consoles proprement calé sur l'écran.

Or si justement par souci d'économie de main d'oeuvre on tape dans un jeu en 2d la vsync devient un problème crucial.

Mais bon pas besoin d'un control de la vsync , un control de fps a 60 suffira largement.

Et non justement. Mettre un timer à 60 fps sans vsync c'est là que tu vas avoir le pire type de tearing. Quand y'a pas de vsync on baisse un peu en dessous de la vitesse ecran (genre à 50) pour que le tearing s'équilibre un peu dans la hauteur de l'ecran et ne déchire pas toujours l'image au même endroit.

Apres c'est vrai que windows et opengl ça fait deux

Bah non justement, windows a le privilège de faire tourner le matos des concurrents parce que chez MS ils ont les moyens de s'offrir ce luxe... après ça reste un luxe donc évidemment au niveau des drivers tout est misé sur directx.

mais tous depend de ce que tu veux faire

Pour commencer j'aimerais déjà voir si openGL arrive à rendre correctement de la 2d sur windows, donc pour l'instant le seul truc qui m'intéresse (en plus de faire des rect en maille basique avec un seule canal de texture) c'est savoir dans quelle mesure vsync est fiable.

Mais minecraft était assez basic niveau rendu ça l'a pas empêché de marcher

Ouais mais le mec avait trouvé un concept malin et addictif qui compense la pauvreté graphique, c'est le genre de coup de bol qui arrive rarement.

je viens de faire une démo d'un jeu , les retours que j'ai eu sont que ça fait un rendu psx/ps2 (plus ps2) , je je trouve que c'est correct , la ps2 étant pas moche perso , et je l'ai fait avec opengl 1.1 =P.

Tant que j'essaye juste de faire de la 2d avec opengl ça m'ira très bien... mais je ne conçois pas de faire de la 3d sans mettre un peu de shaders modernes, même les gadgets du web le font donc ça serait un peu dommage d'utiliser opengl pour faire de la 3d inférieure à ce qu'ils font avec javascript

Après si tu trouve opengl pas satisfaisant rien t’empêche de le faire avec directX.

J'en sais rien je vais pas passer 10 ans à comparer de fond en comble les deux librairies...

Pour moi opengl ça serait une solution de "facilité", enfin disons "pour aller plus vite", parce que la lib directx qui change tout le temps, qu'il faut tout le temps réapprendre, et que tes programmes doivent switcher entre au moins trois versions pour pas être largués, y'a un côté sacerdoce, tu passes ta vie à ne faire que du directx et c'est quelqu'un d'autre qui s'occupe de déveloper la partie gameplay parce que c'est pas le même boulot, ça implique que sans une équipe d'au moins trois quatre devs, on touche pas à directx. Avec opengl ça épargne ce travail et ces bras à recruter mais je ne sais pas si c'est réellement une stratégie intelligente.

[Kannagi]

Pour commencer j'aimerais déjà voir si openGL arrive à rendre correctement de la 2d sur windows, donc pour l'instant le seul truc qui m'intéresse (en plus de faire des rect en maille basique avec un seule canal de texture) c'est savoir dans quelle mesure vsync est fiable.

Alors oui opengl fait très bien de la 2D.
J'en ai pour preuve cette demo de jeu de fight fait par mes soins :ici
Les performances sont pas terrible j'avais porté mon jeu de SDL a openg+freeglut , et j'ai fait la betice de renvoyer a chaque frame les image sur la carte graphique ^^'.

Mais bon c'est poiur te montré (faut pas que du blabla =P) que opengl gérè bien la 2D et voir le rendu.

[c.aug]

Bah ouais j'ai fait des test de 2d opengl aussi et "chez moi ça marche" comme on dit...

mais comme je disais, choisir opengl parce que j'ai la flemme de me donner les moyens de bosser en équipe, je sais pas si c'est bien de le faire



( et sinon à part ça je voudrais dire que ton graphiste est un tueur )

[Kannagi]

( et sinon à part ça je voudrais dire que ton graphiste est un tueur )

Ahah désolé les graphisme vient d'un jeu pro (Last blade et melty blood) ,j'ai aucun graphiste

Sinon , bosser en équipe je trouve ça assez rare (jamais eu occaz de bosser en équipe) , quelque chose viendra si tu fait déjà quelque chose seul.

Je pense que c'est possible de faire de opengl portable , opengl permet de connaitre la carte graphique utilisé, c'est un exemple mais tu peux faire une version rendu opengl 1.1 et un rendu opengl 2.0 par exemple.
ça demande pas plus effort (si bien codé) juste de désactivé les option par rapport a la carte graphique.

[c.aug]

qql viendra si tu fait déjà qql chose seul.

Ca oui évidemment il faut bien qu'au départ tu démarres un moteur avec une seule lib gpu pour commencer. mais il faut préparer le projet en anticipant la possibilité que tu vas pas bosser tout seul.

Si tu vas dire aux gens bonjour j'ai fait un jeu opengl je cherche des développeurs directx pour le porter sur directx, ça risque pas de les emballer car ils vont devoir reprogrammer toute la partie graphique/audio/device. Donc avec un projet opengl tu vas plutôt intéresser les dev smartphone.

Par contre si t'as démarré ton jeu sur dx9 et que tu cherches un dev pour corriger tes switch sur la 10 là tu demandes pas trop c'est jouable.

[moldavi]

Re.

parce que la lib directx qui change tout le temps, qu'il faut tout le temps réapprendre

DirectX9 c'est 2002, DirectX10 c'est 2006 et DirectX11 c'est 2009. Trois changement en 7 ans.

La lib DirectX change tout le temps, hum...

[c.aug]

Un changement tous les 3/4 ans c'est déjà pas mal, ça te laisse tout juste le temps de maitriser un peu l'ancienne version.

Il faut assurer des switch entre les différentes versions pour faire les choses bien, c'est surtout ça qui rend directx plus laborieux qu'opengl, on te mâche rien niveau compatibilité tu te débrouilles.

Tu peux démarrer un jeu directx sur la 9 mais c'est bien d'avoir des gens qui connaissent bien la 10 et la 11 pour ajouter des switch corrects dans le programme, au moins pour éviter des téléchargements inutiles aux joueurs... opengl est moins prise de tête de ce côté là

Je me demande aussi si y'a pas un excès de prise de tête sur la question du portage et du cross-platform.

En général on commence par faire tourner le jeu pour une seule machine, les autres on verra plus tard.

[Kannagi]

Je me demande aussi si y'a pas un excès de prise de tête sur la question du portage et du cross-platform.

En général on commence par faire tourner le jeu pour une seule machine, les autres on verra plus tard.

La prise de tête vient beaucoup de toi sur ce fil

Sinon pour le portage oui ça vient a la fin , après tous dépend de comment du code , mais si tu code bien tu peux faire le portage très rapidement (en remplaçant les fonctions/classe/méthode similaire).

(exemple que j'ai c'est la demo de jeu de fight que je t'ai passé je l'ai codé a la base en SDL , ça m'a mis une journée pour le mettre en opengl).

[moldavi]

Re.

Il faut assurer des switch entre les différentes versions pour faire les choses bien

Un jeu que tu as développé il y a 5 ans en DirectX9, tu vas le mettre à jour en DirectX11 pour faire les choses bien, et gagner 5 FPS.

Soit, c'est une très bonne philosohie.

Comme je l'ai signalé, le choix OpenGL, DirectX se fait selon ses propres contraintes.