Discussion :

[c.aug]

Kannagi >

Oui c'est vrai qu'en l'occurrence là c'est moi qui me torture la tête

Pour le portage je sais pas, ça dépend pas mal du type de jeu.

Un jeu au contrôle simple qui sera adaptable en smartphone, on peut décider d'office que ça sera pour les smartphone donc là on part sur opengl mais dans ce cas là on démarre directement par développer un jeu smartphone, on s'amuse pas à le prototyper d'abord sur opengl/windows.

Par contre un gameplay classique à clavier inadaptable à un smartphone, là on démarre le jeu sur windows, les portages linux et macos sont pas le problème premier d'autant qu'on ne sait pas si on aura les moyens de le faire, on aimerait déjà que ça marche correctement sur la demie douzaine de versions de windows et tous les gpu driver qui vont avec, et pour ça miser sur opengl c'est pas la solution la plus prudente.

Donc, dans les deux cas la combinaison opengl/windows ne sert à rien (à part à économiser de la main d'oeuvre dans le second cas)

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.

Sûrement pas pour gagner 5 fps ça vaut pas le coup pour ça... non c'est juste pour éviter de faire perdre une demie heure aux joueurs à leur faire télécharger une vieille librairie alors qu'ils n'en ont pas besoin vu que les versions plus récentes assurent la compatibilité ascendante, donc tu dois mettre des switch comme ils montrent dans la doc de microsoft.

[moldavi]

Sûrement pas pour gagner 5 fps ça vaut pas le coup pour ça... non c'est juste pour éviter d'enquiquiner les joueurs à leur faire télécharger une vieille librairie alors qu'ils n'en ont pas besoin vu que les versions plus récentes assurent la compatibilité ascendante, donc tu dois mettre des switch comme ils montrent dans la doc de microsoft.

Je ne suis pas certain de te suivre.

Les jeux sous DirectX9 tournent sur Seven sans téléchager de vieilles librairies.

[c.aug]

Ca dépend de ce que tu utilises utilisées dans directx9 en fait.

Certaines fonctions requièrent d'appeler du code spécifique à dx10 et dx11. Si le switch n'est pas assuré dans le programme, ça va réclamer le téléchargement de dx9.

[Kannagi]

ça dépendra du type de jeu , surtout pour les contrôles (même si on peut créer sur smartphone un clavier/manette virtuel).

Par contre un gameplay classique à clavier inadaptable à un smartphone, là on démarre le jeu sur windows, les portages linux et macos sont pas le problème premier d'autant qu'on ne sait pas si on aura les moyens de le faire, on aimerait déjà que ça marche correctement sur la demie douzaine de versions de windows et tous les gpu driver qui vont avec, et pour ça miser sur opengl c'est pas la solution la plus prudente.

Pour la compatibilité opengl windows/linux y a aucun souci , chez moi j'ai que un seul bouton a appuyer (recompiler le projet ).
Donc ça me prend qql seconde , j'ai pas un mac mais je suis sur que ça peut etre aussi rapide x).

Opengl marche sur toute les machines , le seul hic c'est que par exemple opengl 4 marche pas sur toutes les carte graphique (moi je peux supporter que opengl 3.3 max).
donc comme je l'ai dit il est possible de connaitre la version opengl de la carte graphique et de desactiver les fonction opengl par rapport a la version.

Par exemple ce genre de code affiche les détails de la carte graphique.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
void Opengl_info()
{
    printf("%s\n----------------------\n",glGetString(GL_RENDERER));
    printf("%s\n----------------------\n",glGetString(GL_VENDOR));
    printf("%s\n----------------------\n",glGetString(GL_VERSION));
    printf("%s\n----------------------\n",glGetString(GL_EXTENSIONS));
}

Donc, dans les deux cas la combinaison opengl/windows ne sert à rien (à part à économiser de la main d'oeuvre dans le second cas)

Je peux as etre d'accord ça peut servir si on veut faciliter la portabilité (entre windows et linux par exemple) , vu qu'il faut changer aucune ligne de code , donc la portabilité est très rapide (nécessite juste une recompilation du projet).

[c.aug]

Hé bien si on est d'accord, c'est précisément ça que j'appelais économiser de la main d'oeuvre. L'intérêt c'est qu'il y'a moins de travail à faire.

[Kannagi]

comme l'a dit moldavi , il faut faire des choix soit directX est au moins tu t'occupera pas des souci de compatibilité entre carte graphique mais moins portable,soit opengl est faudra que tu t'occupe des différentes version , mais ça sera portable sur différents OS.

[moldavi]

Ca dépend de ce que tu utilises utilisées dans directx9 en fait.

Certaines fonctions requièrent d'appeler du code spécifique à dx10 et dx11. Si le switch n'est pas assuré dans le programme, ça va réclamer le téléchargement de dx9.

Ca va réclamer le téléchargement de dx9.

Bon là je comprends plus rien.

Un programme qui me demande le téléchargement de Dx9, je n'ai jamais connu.

[c.aug]

[edit] ha flute tout d'un coup j'ai un doute

bon attends je suis pas sûr d'avoir tout compris dans les détails pour le coup des switch qui serviraient ou pas à expliciter la compatibilité ascendante, j'ai un doute en fait

je ne sais plus où j'ai lu le document qui parle du problème,

ce que j'ai retenu c'est que "y'a certaines fonctionalités de directx9 qui sont pas dans directx10 et donc le programme va réclamer le téléchargement de directx9"

dans les détails après j'en sais pas plus

mais par prudence c'est mieux de coder les switch comme ça au moins on est sûr, et puis accessoirement ça permet de bénéficier des possibilités des versions supérieures donc c'est du code qu'il est bien de taper

[Kannagi]

De même j'ai jamais eu un programme me demandant de téléchargé dx9

[moldavi]

la vieille 9 obligatoire car 45% des windows user sont toujours sur xp, les deux autres au minimum pour le switch qui évite de télécharger dx9

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.

[c.aug]

En théorie y'a compatibilité ascendante donc dx10 et d11 sont capables de faire marcher tout seuls un programme dx9

Mais en pratique... y'a parfois des surprises

[c.aug]

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

C'est un report de "bug" que j'avais lu je ne sais plus où, et ils expliquaient qu'en réalité il y'a des trucs de dx9 qui marchent plus dans dx10 et donc si jamais le cas se présente le joueur est obligé de télécharger dx9. Mais je me souviens plus du tout de l'explication dans les détails.

[moldavi]

En théorie y'a compatibilité ascendante donc dx10 et d11 sont capables de faire marcher tout seuls un programme dx9

Mais en pratique... y'a parfois des surprises

As-tu un seul exemple concret ?

[c.aug]

Je ne retrouve plus l'url.

Tant pis pas grave...

Dans tous les cas c'est mieux de faire un programme qui switch plusieurs versions de dx au lieu de reposer sur une seule. Si tu veux à la fois que le jeu tourne sur xp, et que ceux qui sont sur dx11 aient leurs beaux shaders, t'es bien obligé de te taper une grosse salade de switch entre trois versions...

...bref le boulot chiant auquel openGL permet de couper

[moldavi]

C'est un report de "bug" que j'avais lu je ne sais plus où, et ils expliquaient qu'en réalité il y'a des trucs de dx9 qui marchent plus dans dx10 et donc si jamais le cas se présente le joueur est obligé de télécharger dx9. Mais je me souviens plus du tout de l'explication dans les détails.

Oui en effet, certaines fonctionnialités présentes dans DiretcX9, ne le sont plus ensuite.

Mais ça ne demande pas le re-téléchargement de DirectX9.

DirectX c'est du COM (Component Object Model), du versionning, du GUID. Ca gère pas trop mal la chose.

Installé DirectX9 c'est pour du Windows 98...

[c.aug]

y'a toujours des imprévus dans un programme

bon après si je veux juste faire de la 2d et que dx9 suffit pour ça...

j'ai pas eu de mauvais retours sur mes tests pour l'instant mais j'ai pas beaucoup de testeurs aussi

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

Si je raisonne selon mes propres contraintes, sorti de windows je suis largué. linux, les mac, les smartphone, j'y connais rien, donc à cet instant la question du choix se pose pas. je suis tellement endoctriné par la secte microsoft que j'ai même payé ma licence windows xp il y'a 10 ans au lieu de le pirater comme tout le monde, c'est dire.

Bon mais je posais la question pour un cas plus général que mes contraintes du moment, on sait jamais si un jour je dois mettre les mains dans un android ça aura servi d'avoir pratiqué un peu d'opengl avant, alors que directx bof... en fait l'interêt personnel que je vois à opengl il est surtout là, mais les smartphone j'ai jamais trouvé ça attirant, je suis pas certain que ce marché soit si nourrissant qu'on le dit

[LittleWhite]

Bonjour,

Je trouve certains propos assez étonnant.
J'aimerai bien avoir le paragraphe de la documentation qui dit que le vsync OpenGL est bancal. Surtout que maintenant on utilise tous du double buffering, qui est implémenté par défaut partout, alors qu'il y a 20 ans, ce n'était pas le cas.
Un jeu pro, qui ne souffre aucun problème avec OpenGL ? -> Unreal Tournament 2004.

Le plus drole pour le vsync, c'est que sous Windows, ce n'est pas le programmeur qui le gère . Il est activé de base, l'application est calé sur 60 FPS et c'est tout. Après, si le programme n'est pas capable de gérer les deltatime et autre ralentissement (ou alors désactivation du vsync), on y peut rien, c'est la faute du programmeur, mais pour le vsync, ce n'est pas lui.

Actuellement, l'état d'OpenGL a vraiment été amélioré. Oui, il y a quelques temps (cela se compte en années), le support d'OpenGL était cramoisi, mais il y a une belle amélioration de la chose, tout de même. Il suffit d'avoir ses pilotes à jour. Bon, malgré cela, il arrive que AMD ne fasse pas toujours un support parfait, mais bon c'est aussi en voie d'amélioration.

Aussi, pour l'histoire des version de DirectX, il y a eu exactement la même évolution dans OpenGL : suppression du pipeline fixe. Oui, il a fallu, peut être deux ans pour que les programmeurs de moteur s'y habitue, mais maintenant, tous les monde fait du DirectX 11/OpenGL 4 (dans les jeux pros je parle), sans que cela gêne personne. Les moteurs sont codés, la réimplémentation est effectuée (DirectX 9 + DirectX 11) et donc, cela est bien géré.

On développera toujours DirectX9 aussi, pour la XBox 360, il ne faut pas l'oublier (même si c'est un peu spécifique).

Pour les programmes multiplateforme, c'est logiquement un choix de développement qu'il faut faire avant de commencer le projet. Plus précisément, il faut juste créer une interface sur les fonctions de bases, afin de permettre une réimplémentation native facilement sans que cela casse le reste du programme.

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.

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.

[c.aug]

Le plus drole pour le vsync, c'est que sous Windows, ce n'est pas le programmeur qui le gère . Il est activé de base, l'application est calé sur 60 FPS et c'est tout. Après, si le programme n'est pas capable de gérer les deltatime et autre ralentissement (ou alors désactivation du vsync), on y peut rien, c'est la faute du programmeur, mais pour le vsync, ce n'est pas lui.

??? ben si dans directx on peut désactiver la vsync si on veut, et puis régler pas mal d'autre paramètres comme le type d'intervalle (théorique, mesuré, réduit par deux, etc...)

bon enfin je dis ça je suis toujours sur windows xp, peut être qu'à partir de windows 7 on ne peut plus virer la vsync

[LittleWhite]

Déjà, les fenêtres (sous Windows) n'ont pas nécessairement de vsync : http://stackoverflow.com/questions/3...d-windowed-app
De deux, la moitié des réponses Google sur la vsync sont liés au logiciel du pilote vidéo (oui, on peut forcer la désactivation de la vsync dans l'utilitaire de NVIDIA, AMD et d'Intel).
Après, bien sur on peut activer ou la désactiver dans le programme lors de l'initialisation du contexte (la configurer surement aussi).
Pour ce qui d'OpenGL c'est ici : http://www.opengl.org/wiki/Swap_Interval

Ce que je voulais dire, le fait d'attendre le faisceau et tout le tralala, ce n'est pas le développeur qui fait quoi que ce soit (comme au temps des jeux en ASM). Maintenant, il y a juste un flag à changer et on est pratiquement bon (pour peu que la gameloop soit efficace).

[Neckara]

Bonjour,

Je n'ai pas tout suivit, mais pourquoi ne pas utiliser une bibliothèque plus au niveau comme Irrlicht qui vous permettrait de changer le pilote utilisé (openGL, DirectX, ...) en ne modifiant qu'une seule variable ou en demandant à l'utilisateur quel pilote utiliser ?