Discussion :

[c.aug]

Pour faire du portable il faut, premièrement, disposer d'une cinquantaine de machines pour tester le jeu dessus.
Ca c'est pas le boulot d'un indie, c'est le boulot de son client.

Mais je crois qu'on a un problème de vocabulaire générationnel.

[edit je refais en plus simple car c'était confus]

Aujourd'hui on colle le terme "indie" sur des sociétés expertes en marketing qui ont réussi à cartonner en vendant du travail d'amateur et qui bien souvent délèguent le problème du portage à des solutions comme java ou flash ou unity.

A la base l'indie c'était tout le contraire. On doit d'abord faire un beau programme qui plaise et qui techniquement soit puissant et innovant, et ensuite seulement éventuellement on décroche un client qui va financer les tests et les portages.

Donc à partir du moment où le portage n'est pas ton job et que ta machine c'est windows, reste-t-il à openGL des arguments pour séduire l'indé ?
Si ton programme se vend de toutes façons c'est le client qui engagera des spécialistes d'opengl si jamais il veut le porter sur mac ou phone. Et puis si ça se vend pas tant pis ça sera bradé sur le web et, en prévision de cette éventualité de face à face direct avec le public qui a 99% de chances d'arriver, t'as intérêt à ce que ton exe soit copain avec windows.

[moldavi]

Ou plus intelligement, gagner en feature (geometry shader/tesselation shader/compute shader). Il y a tout de même une évolution entre les différentes versions et cette évolution est visuelle aussi.

Oui, tu peux aussi recompiler ton code avec le nouveau compilateur et les nouvelles features du langage.

Ce que je voulais dire, c'est que si je développe un jeu, je pense que 5 ans après, je serai passer à un autre jeu, et que je n'aurai ni le temps ni le courage de maintenir tous les jeux précédents...

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

[_MAID]

C'est quoi ce topic truffé de préjugés ???

...puis....

DirectX n'est pour moi meme pas une option pour faire de la 3D, limité a windows que je n'ai d'ailleur plus depuis quelque temps.

Hmmm, contradictoire ça, non ? (ou alors quelque chose m'a échappé)

[c.aug]

Horreur, qu'est-ce que j'ai fait... nooon... j'ai réveillé le vieux démon de la guerre windows vs linux...

C'était pourtant pas un débat qui se prête à ouvrir la boîte de Pandore.

La prise de tête opengl / diretx sur micro on se la pose uniquement dans le cas où on développe avec windows et pour windows.
Je vois donc pas bien pour quelle raison mystérieuse les mac-linux-ios-android se sentent concernés par la question.

Je partais du postulat de départ qu'à priori on choisit OpenGL sans se poser de questions, mais que peut-être il existe des cas où ben en fait DirectX ça peut le faire mieux, j'en sais rien, je demande.

C'était plus subtil comme questionnement plutôt que de formuler les choses de façon binaire et réveiller la guéguerre standard vs Microsoft.

[c.aug]

Je note aussi, je ne cherche pas à prêcher pour Microsoft...

A la base je penchais plutôt pour OpenGL à vrai dire. Mais pas vraiment pour des raisons techniques

[stardeath]

Je partais du postulat de départ qu'à priori on choisit OpenGL sans se poser de questions, mais que peut-être il existe des cas où ben en fait DirectX ça peut le faire mieux, j'en sais rien, je demande.

à priori? pour ma part j'ai choisit DirectX non pas pour la portabilité (je le répète assez souvent qu'il vaut mieux finir un projet mono-plateforme que se prendre la tête sur les contraintes des différents os), ni sur les performance (une fois que tu dépasses les 60 fps, c'est juste un concours de "qui a la plus grosse") mais de lisibilité et "d'agréabilité" d'utilisation.

DirectX, avec le passage en 10 puis en 11, s'est vu faire un lifting qui fait que maintenant les différentes opérations sur le pipeline sont clairement visibles, le découpage de l'api est plutôt bien fait et la relecture du code agréable, très loin des sacs de nœuds DirectX 9 et opengl toutes versions. (amha toujours)

maintenant à chaque lecture d'une fonction DirectX, tu sais à quel étage du pipeline tu agis, quelle est l'action que tu fais, et sur quel élément de l'étage tu agis, le tout donc sur une seule et même ligne.

et surtout le truc qui n'exaspère avec OpenGL, c'est que tout est un identifiant ; que ça soit une texture, un shader ou un buffer, c'est des int, plutôt pénible. (si je dis pas de bêtise, moins je fais d'OpenGL, mieux je me porte, je peux donc lourdement me tromper)

[Neckara]

(je le répète assez souvent qu'il vaut mieux finir un projet mono-plateforme que se prendre la tête sur les contraintes des différents os)

Autant utiliser des bibliothèques portables et faire du code portable, ainsi on évite toutes les contraintes liés aux différents OS (ou du moins une très grande partie) vu que ce sont les bibliothèques utilisées qui vont s'en charger.

Ce serait quand même bête, si en développant un jeu sous Linux, on perdait tout le public étant sous Windows et qu'on doive alors tout recoder (et inversement), c'est aussi une bonne cause d'échecs de projets.

Il suffit d'utiliser des bibliothèques portables, pas de prises de tête, au pire on fait 1 ou 2 petites modifications pour le porter sur un autre OS une fois le projet fini et voilà

Ensuite, je ne vois pas le problème d'utiliser des int comme identifiant, c'est plus performant que d'utiliser des chaînes de caractères et niveau lisibilité c'est du pareil au même ( je présume qu'ils utilises des enums et/ou des constantes aux noms explicites).

[Kannagi]

et surtout le truc qui n'exaspère avec OpenGL, c'est que tout est un identifiant ; que ça soit une texture, un shader ou un buffer, c'est des int, plutôt pénible.

( je présume qu'ils utilises des enums et/ou des constantes aux noms explicites).

De quoi tu parle ? il parle des identifiants que tu récupére quand tu utilise un buffer ou shader , il y a donc pas enum .

[c.aug]

à priori? pour ma part j'ai choisit DirectX non pas pour la portabilité (je le répète assez souvent qu'il vaut mieux finir un projet mono-plateforme que se prendre la tête sur les contraintes des différents os)

Ouais voilà c'était ça mon argument en faveur de directx. Sacrifier la facilité de portage d'un côté, mais d'un autre côté on gagne en anticipant le polishing windows.

J'ai pu voir que dans les projets communautaires, il y'a un moment où ils butent sur un le fameux sale boulot du polishing. Or là justement pour la version windows on a besoin de sales capitalistes pourris soumis à la secte microsoft qui gèrent directx, et c'est justement ça qui manque dans ces communautés où ils font tous que du opengl.

Maintenant à chaque lecture d'une fonction DirectX, tu sais à quel étage du pipeline tu agis, quelle est l'action que tu fais, et sur quel élément de l'étage tu agis, le tout donc sur une seule et même ligne.

et surtout le truc qui n'exaspère avec OpenGL, c'est que tout est un identifiant ; que ça soit une texture, un shader ou un buffer, c'est des int, plutôt pénible. (si je dis pas de bêtise, moins je fais d'OpenGL, mieux je me porte, je peux donc lourdement me tromper)

C'est vrai que c'est agréable le relatif confort visuel des fonctions directx... mais la contrepartie pour profiter de ce côté "catalogue" c'est se farcir l'encyclopédie de doc qui va avec.

Le côté "roots" d'openGL me dérange pas, j'ai démarré la 3d à une époque où y'avait pas les gpu et qu'il fallait calculer chaque pixel, au contraire je trouve que la simplicité d'openGL a son charme, on comprend tout de suite ce qui se passe dans la machine, alors qu'avec directx qui te mâche le boulot tout ça devient opaque.

[stardeath]

Autant utiliser des bibliothèques portables et faire du code portable, ainsi on évite toutes les contraintes liés aux différents OS (ou du moins une très grande partie) vu que ce sont les bibliothèques utilisées qui vont s'en charger.

oui peut être, mais du à la différence de plateforme, de pilote graphique etc. etc. tu devras de toute façon te taper la même batterie de tests et faire des rustines plutôt moche dans le code en cas de problème.

perso je préfère faire la partie windows en directx, et me taper la partie linux en opengl quitte à avoir un renderer par plateforme.
après ce n'est effectivement que ma préférence ^^

Ensuite, je ne vois pas le problème d'utiliser des int comme identifiant, c'est plus performant que d'utiliser des chaînes de caractères et niveau lisibilité c'est du pareil au même ( je présume qu'ils utilises des enums et/ou des constantes aux noms explicites).

je parle effectivement de tous les int que tu récupères quand tu fais appel aux fonctions opengl.
je ne parle pas non plus d'utiliser des chaines de caractères, mais bien de rajouter un peu de typage static, ça ne fait jamais de mal de faire faire du boulot au compilo.

Le côté "roots" d'openGL me dérange pas, j'ai démarré la 3d à une époque où y'avait pas les gpu et qu'il fallait calculer chaque pixel, au contraire je trouve que la simplicité d'openGL a son charme, on comprend tout de suite ce qui se passe dans la machine, alors qu'avec directx qui te mâche le boulot tout ça devient opaque.

hola, le nommage des fonctions directx, ça te mâche pas des masses de boulot, je dirai même que ça fait plus stricte que dans opengl.
tu n'as pas, par exemple, bindbuffer qui bind à peut près tout et n'importe quoi, en directx tu vas avoir un bind pour les textures, un pour les buffers, etc. mais c'est suffisamment bien nommé pour que tu ne t'y perdes pas.

après je comprends pas le coté "catalogue".

[c.aug]

J'ai pas dit que ça mâchait le boulot, juste que c'est plus lisible.

Ce que j'appelais "catalogue" c'est l'aspect encyclopédie de classe et méthodes, il faut patiemment éplucher la doc pour trouver la fonction que tu cherches. Une action = une fonction. C'est plus lisible mais ça fait plein de noms de fonction à apprendre.

[Kannagi]

Tu as fait ton choix non ? (je crois que t’étais parti sur du directX) .

[c.aug]

J'en sais rien. Pour l'instant je bidouille les deux, dx et gl.

Je ne suis pas en train d'attaquer un projet de développement, j'avais plutôt derrière la tête l'idée de filer un coup de main sur les projets des autres qui manquent un peu de polishing gpu. Pour l'instant je fais des essais et des recherches.

Les mecs qui font des jeux sdl, je ne suis pas sûr qu'ils cracheraient sur un type qui passe tout dans directx pour polir la version windows... même si pour être tout à fait sincère pour l'instant j'ai plutôt envie de me rabattre sur opengl par feignantise (ou par manque de temps si tu préfères...)

[stardeath]

Ce que j'appelais "catalogue" c'est l'aspect encyclopédie de classe et méthodes, il faut patiemment éplucher la doc pour trouver la fonction que tu cherches. Une action = une fonction. C'est plus lisible mais ça fait plein de noms de fonction à apprendre.

ok, je comprends ton point de vue maintenant, je suis totalement d'accord, après je préfère, je trouve ça plus cadré, c'est toujours le problème que j'ai avec opengl, il n'y a peut être moins de fonctions, mais je galère toujours sur comment les utiliser pour arriver à mes fins.

ce que j'essaie de faire en ce moment (en dehors de mon ébauche de jeu, avec dx11 d'ailleurs XD) c'est de faire un wrapper qui transforme (à la compil) mes appels directx 11 en opengl 4.
je n'ai pas vu d'équivalent sur la toile, je pense que ça peut être pratique.

[Squisqui]

Ok, je comprends que parce qu'il y a 45% de User sous XP, on développe sous DirectX9.

Mais ça ne m'explique pas l'histoire d'être obligé de re-télécharger DirectX9 sous Seven, je ne comprends pas.

Et même sous Windows8.
Certains programmes appellent explicitement des bibliothèques du style "d3dx9_43.dll". Ces bibliothèques ne sont pas présentes par défaut (tout comme ses équivalent dx10 et 11).
Je n'y connais strictement rien à DX ou OpenGL donc je ne sais pas à quoi cela correspond exactement. Je me les procure par ici.

[moldavi]

Bonjour.

Et même sous Windows8.
Certains programmes appellent explicitement des bibliothèques du style "d3dx9_43.dll". Ces bibliothèques ne sont pas présentes par défaut (tout comme ses équivalent dx10 et 11).
Je n'y connais strictement rien à DX ou OpenGL donc je ne sais pas à quoi cela correspond exactement. Je me les procure par ici.

Si tu es obligé de récupérer les bibliothèques style "d3dx9_43.dll", ce n'est pas normal. Cela concerne deux/trois dll bien spécifiques au SDK DirectX, et un développeur consciencieux les fournit toujours avec son programme.

Cela ne concerne en rien le runtime DirectX de base, la version 9C, qui est installée depuis des lustres sur Windows (à partir de XP).

[gbdivers]

Normal ou pas, je l'ai constaté aussi : beaucoup de jeux nécessitent l'installation de DirectX 9 à côté (une petite recherche sur le nom de cette dll le confirme). C'est souvent transparent (l'installeur du jeu propose également d'installer le SDK), mais pas toujours.

[c.aug]

Il faut pas compter à 100% sur l'automatisation de la compatibilité ascendante, il restera toujours quelques trucs pour lesquels ils l'ont pas programmée et donc là c'est à nous de le faire. Ils montrent dans la doc de Microsoft il faut faire des switch entre chaque version de directx pour rendre la compatibilité explicite, ça évite la mauvaise surprise du téléchargement d'une demie heure qui sert à rien.

[c.aug]

Bon j'ai coché résolu car je viens de trouver une synthèse qui surmonte la contradiction apparente.

En fait à la base il y'avait un malentendu de vocabulaire car aujourd'hui on a étendu le sens de "jeu indie" aux "jeux à petits budget".

Or j'entendais "indé" dans un sens plus vieux du terme, qui n'a rien à voir avec le travail des mojang/rovo/ankama/etc..., un sens dans lequel "indé" ne rime pas spécialement avec petit budget puisqu'il arrive que des jeux indie finissent dans l'AAA.

Le sens où j'entendais "indé" c'est "le jeu d'abord, le client après", donc que c'est démarré comme un projet amateur, mais pas "amateur" dans le sens "code vite torché", dans le sens où on profite des avantages du cadre de développement amateur, c'est à dire qu'on a pas de deadline, donc qu'on peut prendre le temps de bien faire les choses. Dans le sens où j'entends indé donc, on n'est plus dans la problématique de "gagner du temps", on est dans la problématique de séduire une clientèle sans aucun capital de budget marketing, avec la seule force de ses bras, donc il y'a intérêt à ce que la démo du moteur soit bien faite.

A partir de là, la question ne se pose plus, à plus ou moins moyen terme on a 99% de chances d'avoir besoin de directx pour faire un polishing windows bien propre donc oui il faudra s'en servir.

La question qui reste maintenant, sur quelle librairie on démarre le projet, au risque d'étonner ceux qui m'ont pris pour un microsoft-fanboy, je préfère démarrer sur openGL parce que c'est plus commode pour solliciter les porteurs dans un premier temps, et si je veux une version windows polie au directx je préfère faire appel à un spécialiste de directx qui fera ça mieux que moi, mais ça me dispense pas d'avoir quelques bases en directx au cas où je ne trouve pas de gentil volontaire pour se taper ce sale boulot que personne ne veut faire ou ne serait-ce que pour comprendre quelque chose au code qu'il tape.

Donc réponse: oui directx a toute sa pertinence dans l'indie car si votre projet aboutit à un résultat consistant vous avez guère de chances d'échapper à la salle de torture microsoft. MAIS, il faut aussi savoir travailler avec openGL. Faut connaitre les deux, donc.