Discussion :

[Dominique49]

J'ai l'impression que Microsoft va subir une deuxième perte consécutive à la première Non seulement ils foirent au point que les éditeurs de jeux donne leur jeux gratuitement pour Linux, mais en plus le code source de Skype est publié peu après son rachat par Microsoft ... décidément il me semble que ça va mal pour eux (et c'est pas moi qui vais les plaindre ! ).

[Dominique49]

Sauf que ce jour là, il y a fort a parier que les virus commenceront à arriver en masse sous GNU/Linux. Après tout, il n'a pas de raison d'être plus à l’abri qu'un Windows récent. Il est juste épargné pour l'instant à cause de sa relative confidentialité.

C'est sûr, quand tu voit la puissance de COMODO Firewall sur Windows, il détecte la moindre activité suspecte quand il est en mode parano.

Je me suis déjà penché sur lé sécurité Linux et c'est vrai que les distributions basique sans protection, comme par exemple Ubuntu sont très vulnérables ... Quand au sudo, vu que le mot de passe admin se trouve sans doute dans les mdp retenus par les navigateurs ...

EDIT Et je ne parle pas du pare-feu qui peu être contourner sans problème en utilisant le port 80 classique pour la connexion internet, ou si l('utilisateur est vraiment trop parano il suffit de trafiquer le navigateur pour en faire sa boite au lettre c'est les inconvénient du libre, mais on ne peu pas tout avoir

[goran kajfes]

Le port de Left 4 Dead 2 est juste le début d’une vaste opération visant à proposer l’ensemble des jeux de la plateforme Steam sous GNU/Linux

Steam voit d'un mauvais œil la plateforme Windows de distribution des applications sous Metro. Elle envoie donc un message (« Ne marchez plus sur nos plates-bandes ») à Windows en proposant sa plateforme de vente à un concurrent: Linux. Au passage elle se permet de railler Windows: « regarder, on adapte un jeu sous Linux, et il tourne plus vite que sous Windows ». Bien mauvaise publicité (pour Windows mais excellente pour Linux)...

Y voir le début de la proposition de l'ensemble du catalogue Steam sous Linux, c'est un peu s'enflammer. Mais on ne sait jamais: les belles histoires débutent parfois sur un malentendu.

[deadalnix]

Sauf que ce jour là, il y a fort a parier que les virus commenceront à arriver en masse sous GNU/Linux. Après tout, il n'a pas de raison d'être plus à l’abri qu'un Windows récent. Il est juste épargné pour l'instant à cause de sa relative confidentialité.

Moi aussi je suis certain que personne n'essaye d'entrer chez Google, Amazon ou Facebook. Quel intérêt ?

Sinon pour les histoire de portabilité des shader entre directX et openGL, je n'arrive plus à trouver de source. Ça avait pas mal parlé de ça chez wine avec starcraft 2, ou un shader fait des cercles noirs (si je me rappelle bien, diviser par l'infini donne 0 ou NaN selon que tu utilises directX ou openGL mais je n'en suis pas sur du tout. Toujours est-il que c'est une bêtise du genre). Le GPU à deux modes de calcul, l'un pour directX et l'autre pour openGL pour traiter ce genre de cas.

Il y a un projet de propal d'extension openGL pour avoir une compatibilité avec directX, mais je ne sais pas ou ça en est.

[deadalnix]

Y voir le début de la proposition de l'ensemble du catalogue Steam sous Linux, c'est un peu s'enflammer. Mais on ne sait jamais: les belles histoires débutent parfois sur un malentendu.

Porter tout le catalogue, c'est quand même un taff monstre, je n'y crois pas trop, il faut être réaliste.

Par contre, s'assurer que les nouveaux titres made in valve tournent sur linux, c'est une option.

[gbdivers]

Sinon pour les histoire de portabilité des shader entre directX et openGL, je n'arrive plus à trouver de source. Ça avait pas mal parlé de ça chez wine avec starcraft 2, ou un shader fait des cercles noirs (si je me rappelle bien, diviser par l'infini donne 0 ou NaN selon que tu utilises directX ou openGL mais je n'en suis pas sur du tout. Toujours est-il que c'est une bêtise du genre). Le GPU à deux modes de calcul, l'un pour directX et l'autre pour openGL pour traiter ce genre de cas.

Il y a un projet de propal d'extension openGL pour avoir une compatibilité avec directX, mais je ne sais pas ou ça en est.

J'ai l'impression que tu parles des modes d'arrondis, non ? Il me semble que ce n'est pas un problème de disponibilité dans DirectX ou OpenGL, mais simplement un paramétrage par défaut différent des drivers (le problème se pose aussi sur OpenGL entre NVIDIA et ATI)
Le mode d'arrondi est paramétrable (en tout cas sur OpenGL), ce n'était probablement qu'un problème passager qui doit bien être connu maintenant
De toute façon, le code des shaders n'est pas compatible, il faut de toute façon réécrire complètement les shaders, le code hôte, etc. Et les fonctionnalités DirectX et OpenGL sont également différentes
Bref, oui pour dire que le passage DirectX <-> OpenGL n'est pas simple, mais je crois pas que ce soit un problème de mode de fonctionnement différents des GPU entre les 2 API

[stardeath]

Bref, oui pour dire que le passage DirectX <-> OpenGL n'est pas simple, mais je crois pas que ce soit un problème de mode de fonctionnement différents des GPU entre les 2 API

je pense plutôt que la difficulté du port vient que sous opengl tu as 36 milles façons pour faire certaines choses alors que tu n'as qu'une possibilité sous dx.

entre les extensions arb, nvidia, ati, intel ... dont il faut tester la présence, avec en plus que chacune est forcément plus rapide sur certaines cartes graphiques, ça fait déjà un bon bordel.

quand on regarde le code des jeux id software où pour certaines fonctionnalités tu as 4 extensions différentes, tu te dis que ça a pris de 1) du temps à coder, de 2) du temps à déboguer et de 3) du temps à tester.

[gbdivers]

EDIT : confirmation plus loin, il existe un système équivalent aux extensions avec DirectX, le contenu de ce message partait de l'hypothèse que cela n'existait pas Finalement non. Faut que les spécialiste DirectX se décide

je pense plutôt que la difficulté du port vient que sous opengl tu as 36 milles façons pour faire certaines choses alors que tu n'as qu'une possibilité sous dx.

entre les extensions arb, nvidia, ati, intel ... dont il faut tester la présence, avec en plus que chacune est forcément plus rapide sur certaines cartes graphiques, ça fait déjà un bon bordel.

quand on regarde le code des jeux id software où pour certaines fonctionnalités tu as 4 extensions différentes, tu te dis que ça a pris de 1) du temps à coder, de 2) du temps à déboguer et de 3) du temps à tester.

Je connais très mal DirectX, mais dit comme ça, j'ai du mal a y croire :
* tu peux faire un code unique et largement portable "minimal" en GL 2, les fonctionnalités supplémentaires sont optionnels (surtout celle avec les extensions non ARB)
* tu as aussi plusieurs versions pour DirectX, avec des fonctionnalités différentes, ça m'étonnerait que dans les mêmes jeux qui utilisent plusieurs extensions de OpenGL, tu n'as pas aussi plusieurs codes pour DirectX. Si c'est pas le cas, c'est que toutes ces fonctionnalités ne sont pas implémenté en DirectX, pas sur que ce soit mieux
* le problème d'avoir des codes multiples vient surtout que les utilisateurs ont des cartes graphiques différentes, avec des fonctionnalités différentes. On a donc le choix de ne pas utiliser ces fonctionnalités et d'avoir un code plus simple, ou des les utiliser avec les problèmes liés (faire plusieurs codes pour les gérer ou non en fonction des utilisateurs)

Bref, toujours d'accord pour dire que le portage ne doit pas être simple, mais tes explications me semblent pas convaincantes.
A vu de nez, l'explication la plus simple, c'est que l'on a affaire à 2 langages différents, deux approches différentes, et qu'il faut tout repenser et pas simplement faire un copier collé du code

[stardeath]

bah ça a toujours été dit que directx est un sous ensemble d'opengl commun à tous les constructeurs de cartes graphiques. c'est pas par magie que tu n'as pas d'option spécifique à un constructeur sous dx.

de plus je n'ai pas dit que faire un code minimal n'était pas possible ; mais pour raison de performance tu essaieras toujours, si c'est possible, pour un constructeur d'avoir les meilleures perfs.
la preuve avec le code d'id software avec le choix de l'extension en fonction de la cg, et ici de valve, ils ont 30 fps de plus sous opengl que sous dx, ce qui perso ne n'étonne pas le moins du monde et pourtant je suis un partisan de dx.
moi ce que j'ai vu c'est que dans les 2 cas le jeu tourne à environ 300 fps, le reste c'est vraiment juste de la tentative d’esbroufe.
je ne sais plus où j'ai lu ça mais gagner 50 fps quand tu en as déjà 300 c'est bidon, par contre en gagner 2 quand tu n'es qu'à 60 ça c'est de l'amélioration conséquente.

pour les fonctions non implémentées en directx, tu te poses pas la question, elles ne sont pas là, sous opengl tu peux avoir des fonctions tiptop mais pour un constructeur seulement, ou alors qui ne fonctionne pas de la même manière sur une autre carte etc. pas sur que ça soit mieux non plus.

pour comparer pour opengl tu as les versions 2.0, 3.0, 3.1, 3.2, 4.0, 4.1 + la liste des extensions arb + les extensions spécifiques aux constructeurs ;
dx tu as 9, 10, 10.1, 11, 11.1 et c'est tout, quand tu as la liste de fonctionnalités pour une version de dx tu es sur que toutes sont disponibles sans exceptions.

en conclusion, pour moi, le copié-adapter marche très bien (entre dx et opengl à fonctionnalités équivalentes maintenant c'est pratiquement qu'une histoire de gout entre le design des apis), mais c'est la même problématique que le portage console->pc, ne veut on pas que à l'occasion de ce portage on essaie au maximum d'avoir un truc qui tire parti de la plateforme cible?

[gbdivers]

EDIT : confirmation plus loin, il existe un système équivalent aux extensions avec DirectX, le contenu de ce message partait de l'hypothèse que cela n'existait pas Finalement non. Faut que les spécialiste DirectX se décide


Tu as le possibilité d'écrire 1 code (en GL2 et D3D 9 par exemple). Tu as la possibilité d'écrire 3-4 codes "semi" optimisé (GL 2, 3 et 4 d'un côté et D3D 9, 10, 11 de l'autres). En plus, avec les extensions OpenGL, tu as la possibilité d'utiliser des fonctionnalités plus récentes (la dernière version de D3D, la 11, date de 2009) ou vendeur spécifique (extension NV, ATI, EXT). Et c'est cette liberté que tu trouves problématique pour développer sous OpenGL ?

C'est pas le première fois que j'entend ce type d'argumentation (forcement, en faisant du C++) et je dois avouer que j'ai du mal à comprendre...

Bon, déjà que le sujet de la discussion est très trollogène à la base (Windows vs Linux, DirectX vs OpenGL), mais si tu viens avec des arguments aussi trollogène (et très personnel) que "moins de liberté, c'est mieux parce qu'on n'a pas à s'embêter à choisir", je suppose que tu t'attends à ce que tu fasses l'unanimité, non ?

Sinon, pour ton argument sur la différence de FPS quand on est à 300, c'est vrai que ce n'est pas très significatif

[screetch]

pour comparer pour opengl tu as les versions 2.0, 3.0, 3.1, 3.2, 4.0, 4.1 + la liste des extensions arb + les extensions spécifiques aux constructeurs ;
dx tu as 9, 10, 10.1, 11, 11.1 et c'est tout, quand tu as la liste de fonctionnalités pour une version de dx tu es sur que toutes sont disponibles sans exceptions.

Ce n'est pas vrai, il y a les "capabilities" des cartes graphiques (le nombre d'instructions autorisees, le nombre de texture fetch, la memoire disponible pour certains buffers, le nombre de samples quie l'on peut ecrire dans un shader...)
OpenGL et DirectX, a part le nom de certaines extensions, c'est blanc bonnet et bonnet blanc.

[gbdivers]

Ce n'est pas vrai, il y a les "capabilities" des cartes graphiques (le nombre d'instructions autorisees, le nombre de texture fetch, la memoire disponible pour certains buffers, le nombre de samples quie l'on peut ecrire dans un shader...)
OpenGL et DirectX, a part le nom de certaines extensions, c'est blanc bonnet et bonnet blanc.

Merci screetch
Ça m'étonnait que DirectX n'ai pas un mécanisme équivalent aux extensions. Sinon, cela voudrait dire qu'il n'était pas possible d'utiliser les nouvelles fonctionnalités sorties sur les GPU depuis DirectX11 (2009), alors que manifestement, c'est possible


Question plus général : quelqu'un à déjà fait ce type de portage dans un jeu pro ? non pro ? pas pour un jeu ? juste pour tester ?

[stardeath]

heu???

les extensions sous dx ça n'existe pas, les capabilities c'est autre chose (qui existe d'ailleurs aussi sous opengl)

et oui si des fonctions sortent depuis une version de dx elles ne sont pas disponible même sous forme d'extension, il faut attendre une nouvelle version de dx pour les avoir.

et non je ne tiens pas à faire l’unanimité, sinon je ne posterai pas, c'est plutôt simple.

[screetch]

non ca c'est vrai cependant, les capabilities ne marchent que dans un sens; par exemple il n'y a pas forcement la possibilité de faire du deferred rendering si la carte ne supporte qu'une seule ecriture dans un buffer. Ce que je critiquais c'etait exactement la phrase

quand tu as la liste de fonctionnalités pour une version de dx tu es sur que toutes sont disponibles sans exceptions.

ca c'est pas vrai, il est parfois possible que certaines fonctionnalites soient bridees sans que cela ne remette en cause le support d'une version de DirectX.
Par contre ce que dit stardeath après est vrai, si il y a de nouvelles fonctionnalités il faut un nouveau DirectX

[gbdivers]

Bon, comme j'y connais pas grand chose, j'ai regardé un peu dans les livres

Direct3D 11 Considerations
(...)
Another of the more major changes is the removal of the CAPS bits. In previous versions of Direct3D, you had to check the capabilities of the underlying video hardware to make sure that certain functionality like pixel shaders was available to use. Now, any features not provided by the hardware are emulated by the system in software, ensuring you always have the full range of functionality to play with. This will greatly simplify the initialization code for games using D3D10. It is also much needed, since in the past some hardware vendors supported only a subset of features, which caused issues when dealing with supporting different pieces of hardware. To be considered DirectX 10- or 11-compatible today, hardware must strictly follow guidelines for compliance.

Donc plus de "cababities" dans DirectX 11. Quand une fonctionnalités n'est pas disponible, elle est émulé. Donc effectivement, si on travaille sur Windows 7 avec DirectX 11, on peut écrire qu'un seul code, quelque soit les capacités du GPU

@stardeath
Donc ça change pas ce que j'ai dis : tu compares 2 approches, l'une qui permet l'utilisation de nouvelles fonctionnalités et l'autre non et la conséquence sur le code

Bref, dire "le code OpenGL est plus complexe" est un raccourci très rapide...

[screetch]

http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx

plus de CAPS mais bon...
les features sont un peu plus optionnelles que celles de D3D 9 quand meme, mais ca existe toujours.

[stardeath]

le code opengl PEUT être plus complexe, et heureusement encore, tu as accès à tout ce que les constructeurs ont développé pour leur cg, c'est pas un défaut mais faut pas forcément y voir une qualité non plus.

si tu veux faire un portage simple, comme je l'ai dit et screetch l'a rajouté, entre opengl 4 et dx11 c'est du pareil au même, mais comme je l'ai aussi dit si tu veux faire un portage qui exploite le maximum de la plateforme, là faut mettre les mains à la pâte, et ça amène forcément à du code plus complexe, à moins que je me goure plus tu te rapproches des spécificités d'un hardware plus tu vas avoir de code à écrire.

et je le répète je ne trouve rien de problématique à avoir le choix de la méthode, mais plus on te donne de choix, potentiellement plus tu vas avoir de code et de tests à effectuer, je vois pas ce qu'il y a de choquant là dedans. ma préférence avec dx n'a rien à voir la dedans.

[goran kajfes]

Porter tout le catalogue, c'est quand même un taff monstre, je n'y crois pas trop, il faut être réaliste.

Par contre, s'assurer que les nouveaux titres made in valve tournent sur linux, c'est une option.

Si dans 5 ans, au moins une nouvelle sortie de jeu sur deux est rendue disponible sous Linux par Steam, il y aura de quoi sauter au plafond. C'est un scénario optimiste.

[Uther]

Si dans 5 ans, au moins une nouvelle sortie de jeu sur deux est rendue disponible sous Linux par Steam, il y aura de quoi sauter au plafond. C'est un scénario optimiste.

Le catalogue de Valve ayant déjà été porté sous MacOS X, ce ne serait pas si énorme que ça.

Le catalogue Steam en entier, par contre, c'est en effet totalement inenvisageable.

[Freem]

Selon leur blog, il semblerait que la semaine prochaine une version bêta interne soit "disponible" (la chance qu'ils ont les dev linux de valve quand même ) et une bêta privée est quand à elle prévue pour début octobre.

Cette version privée inclura:

• steam lui-même
• un jeu valve (on se demande lequel, *ahem*)
• support pour Ubuntu 12.04 et plus récent

source: http://blogs.valvesoftware.com/linux/