Discussion :

[sikoko]

Bonjour tout le monde,

Voilà, une des gros stresses de linux qui m'empêche de passer dessus à plein temps est qu'il ne supporte pas les jeux commerciaux. Je ne comprends pas pourquoi les développeurs de jeux ne compile pas leur code avec un compilateur Linux afin que leurs jeux soit disponible sur ce système.

Différentes raisons possibles me viennent à l'esprit pour expliquer cela, mais ne sachant pas trop je fais appel à vos cerveaux éclairés :

Les bibliothèques ne sont pas les mêmes et donc cela prendrait trop de temps pour "recoder" les jeux avec des bibliothèques Linux.

Dans ce cas, je suppose que Linux contient des bibliothèques fort semblable à celle de windows, il devrait donc exister des programmes capable de faire la conversion des codes d'un sytème à l'autre ?

Est-ce que les développeurs de jeux utilisent des librairies windows genre .NET qui sont trop tordue et qui n'ont pas été repris dans cette forme sur Linux ?

Ou alors est-ce un problème de driver de carte graphique ou de bibliothèques graphiques genre directX ?

Peut-être que si ce problème était levé, tout le monde passerait à Linux, il me semble.

Qu'en pensez-vous ?

[Davidbrcz]

Dans l'ordre :

Les bibliothèques ne sont pas les mêmes et donc cela prendrait trop de temps pour "recoder" les jeux avec des bibliothèques Linux.

La plus part des jeux sous windows sont codés avec DirectX et DX c'est 100% pour Windows.

Dans ce cas, je suppose que Linux contient des bibliothèques fort semblable à celle de windows, il devrait donc exister des programmes capable de faire la conversion des codes d'un sytème à l'autre ?

Oui,il existe OpenGl qui est portable.Mais DirectX est en C++ et OpenGl principalement C.
Donc c'est impossible à convertir.

Est-ce que les développeurs de jeux utilisent des librairies windows genre .NET qui sont trop tordue et qui n'ont pas été repris dans cette forme sur Linux ?

Aucune idée .Mais je ne connais pas d'équivalent à .Net sous linux bien qu'il existe Mono pour émuler .Net.

Ou alors est-ce un problème de driver de carte graphique ou de bibliothèques graphiques genre directX ?

Les drivers des CG sous linux sont fort acceptable.

Peut-être que si ce problème était levé, tout le monde passerait à Linux, il me semble.

Il n'y a pas que ca.
La flemme de détailer mais ce genre de débat abonde sur google.

[loufoque]

Les drivers des CG sous linux sont fort acceptable.

Les pilotes libres ne sont pas aussi bien que les propriétaires, et les pilotes propriétaires de ATI sont bien mieux sous Windows.

[Davidbrcz]

Oui ces drivers sont moins bon, moins fini car ils visent moins de monde.
Mais pour ma part(avec une ATI) , je n'ai rien de majeur à redire.

[sikoko]

Dans l'ordre :

Oui,il existe OpenGl qui est portable.Mais DirectX est en C++ et OpenGl principalement C.
Donc c'est impossible à convertir.

Ah bon je croyais que c++ n'etait que du c auquel on avait rajoute l'objet. Donc passer de directx a opengl est peut-etre impossible mais ce n est pas a cause de cela. Fin je crois...

Bon et quoi pourquoi les developpeurs developpent-ils en directX et pas en openGL est-ce que c est une question de performance ?

(sorry pour l'orthographe, j'ai un vieux clavier)

[loufoque]

Le problème ne vient pas du fait que l'une des API est en C et l'autre en C++ (d'ailleurs DirectX c'est pas tellement C++ non plus), ça vient tout simplement que ce sont des APIs différentes.
En particulier, l'API de DirectX est tellement ratachée à Windows que la faire tourner sous Linux reviendrait à y réimplémenter Windows. (ce que fait le projet wine, en l'implémentant par dessus OpenGL)
Reste que, sous Linux, OpenGL est la seule interface qui possède une architecture de pilotes matériels.

Bon et quoi pourquoi les developpeurs developpent-ils en directX et pas en openGL est-ce que c est une question de performance ?

Microsoft supporte financièrement DirectX et fournit des kits de développements qui sont plus "tout-en-un".
OpenGL est plus bas niveau, donc plus difficile à exploiter. OpenGL 2.1 avec quelques extensions rivalise avec DirectX 9, en étant plus performant pour certaines choses et moins pour d'autres.
OpenGL 3 devrait surpasser DirectX 10.
Les gros moteurs graphiques comme Unreal peuvent aussi bien fonctionner avec l'une ou l'autre des APIs.

Quoi qu'il en soit tout ça n'a rien à faire sur ce forum.

[nicroman]

Le problème ne vient pas du fait que l'une des API est en C et l'autre en C++ (d'ailleurs DirectX c'est pas tellement C++ non plus), ça vient tout simplement que ce sont des APIs différentes.

DirectX est entièrement en COM, surtout les versions DX10+ qui sont interfacées étroitement avec la configuration du système (DXGI et consorts).

Quant à la différence, il n'y en a fondamentalement aucune sur le principe... Dans un cas comme dans l'autre, il sagit d'empiler tout un tas de paramètres et d'états, puis d'envoyer un ordre de dessin à la CG.

La différence est à mon avis à deux niveaux...
D'abord il y a un abus de langage ici: DirectX est une librairie complète: réseau, input (clavier, souris, joystick), son (3D), musique, vidéo (plus maintenant) et graphisme 3D.... Alors que OpenGl se limite au graphisme (partie Direct3D).

Si on compare uniquement Direct3D et OpenGL on voit:
- D'un coté une API propriétaire, mise à jour régulièrement (tous les 2 ans pour les version majeurs, tous les 2 mois pour les SDKs), développée conjointement avec les fabricants de carte graphique afin de coller au mieux au "futur" développement.
- D'un autre coté une API 'libre', ou chaque fabriquant peut y aller de son extension, en attendant que celles-ci soient éventuellement standardisée dans une version suivante.

Le résultat est que pour utiliser une fonctionalité "récente", il faut, en OpenGL, en connaitre toutes les extensions propriétaires (et les tester avec chaque carte indépendemment) qui peuvent marcher plus ou moins de manière similaire selon le constructeur. Coté Direct3D, c'est une fonction qui marche ou marche pas selon la carte (flag dans les capabilities, remises à plat d'ailleurs pour D3D10), avec en prime un rasterizer de référence qui implémente la fonction (et qu'on peut donc plus ou moins tester même sans carte graphique l'implémentant).

Pour finir, je dirai qu'à une époque, les fabricants de CG étaient ceux qui poussaient les APIs, et OpenGL répondait très bien à cet état de fait, permettant aux programmeurs d'utiliser les nouvelles fonctionalités dès leur "disponibilité".
Depuis Direct3D6, ce sont les programmeurs qui poussent l'API, M$ rajoute ou non la fonctionalité dans D3D (avec les constructeurs derrière qui donnent leur avis sur le sujet quand même). D3D10 est le pire de tous, on a eu quelques mois (presque un an) avec une API implémentée par aucune carte graphique existante !

[koala01]

Salut,

Le problème est, selon moi, que de nombreuses sociétés de création de jeu considèrent (encore) linux comme partie négligeable, ou, du moins, que le nombre d'utilisateur de linux à usage privé est insuffisant pour justifier le portage de leurs jeux sur cet OS

*Peut-être* y a-t-il aussi certaines craintes qui viennent tout simplement du fait que le terme "linux" est fortement associé à d'autres tels que "open source", licence GPL et autres, et donc à la crainte de ne pas pouvoir *vendre* leur jeu à un tarif adéquat par rapport au temps de développement ...

Il n'est pas impossible que certains n'aient toujours pas compris que l'on puisse fournir des applications sous linux avec une autre licence que la GNU/GPL...

Enfin, tu l'auras surement remarqué, mais la tendance est à la protection physique des supports (CD/DVD) des jeux...

De nombreux jeux ne sont pas sensés fonctionner sans le CD/le DVD d'installation, du fait de la présence de protections telles que SECUROM, safedisc ou autres, et, là encore, je n'ai pas l'impression que cela se bouscule très fort pour fournir des solutions tournant sous linux...

Je crois que ces trois raisons sont en grande partie responsable du petit nombre de jeux portés sous linux, mais, il faut aussi comprendre deux autres points, qui ont aussi leur importance:

-1 Tant que tu utilise la bibliothèque standard ou des bibliothèques développées dés le départ pour être portables (je pense, entre autres à boost ou à QT, mais ce n'est pas une liste exhaustive ) tu n'aura aucun problème...

Si la version correspondante est installée sur un système, et que tu te "contente" d'utiliser ces bibliothèques, la simple compilation croisée suffira pour assurer le portage de ton jeu, mais, dés que tu t'attaqueras à des fonctions plus "bas niveau" (ça peut, tout simplement, être l'utilisation de threads), tu te trouvera confronté à une série d'incompatibilités tant au point de vue de l'interface des bibliothèques que de la simple présence de certains fichiers d'en-tête.

Le résultat direct est qu'une bonne partie du moteur de jeu devra, pour ainsi dire, être codé deux fois: une fois pour tourner sous linux, et l'autre pour tourner sous windows... Même si les deux codes peuvent se retrouver dans un même fichier, entourées de directives de compilation (if defined(linux), par exemple)

-2 Il existe pas mal de sorte de gestionnaires de paquetages sous linux:
rpm, deb, tgz...

Si tu voulais fournir un jeu compilé sous linux (pour la simple raison que tu ne voudrais pas fournir le code source pour permettre une compilation par le "client"), il faudrait que tu prévoies une version pour chaque gestionnaire de paquetage

Le tout, sans même prendre en compte les différences entre ubuntu et debian, par exemple, qui utilisent tous deux les deb, mais dont les versions des différents paquetages sont souvent importantes... et potentiellement sujettes à incompatibilités.

Et, bien sûr, le fait d'avoir développé une application pour qu'elle utilise DirectX au lieu de SDL ou de OpenGL ne fera qu'ajouter des problèmes de compatibilité et la nécessité d'un recodage en règles

[Jean-Michel Ormes]

Juste pour info, il existe un logiciel sous Linux qui permet de faire passer certains jeux commerciaux: Cedega

[Happy]

Je suis sous linux depuis pas mal de temps et ça m'a fait remarque une chose; le passé c'est le passé, ceux qui connaissent le futur, le construisent.

Si on fais légèrement attention, la plus part de nouveaux programmeurs commencent à penser « cross platform ». Ils prennent donc des librairies pour ne pas rester piégés sous un seul OS par exemple, ce qui peut résulter dans un futur plus riche pour linux et autres OS.

Je ne m'inquiète pas, pour l'instant il y en a déjà pas mal de jeux sous linux; en natif ou même en passant par d'autres moyens.
Bien que je ne sois pas un PGM, j'en suis amplement satisfait; les PGM n'ont rien à penser des autres OS, ils pensent seulement jeux par exemple ( mais il y a des exceptions )

[Mat.M]

Bonjour tout le monde,
Voilà, une des gros stresses de linux qui m'empêche de passer dessus à plein temps est qu'il ne supporte pas les jeux commerciaux. Je ne comprends pas pourquoi les développeurs de jeux ne compile pas leur code avec un compilateur Linux afin que leurs jeux soit disponible sur ce système.

Cette question est récurrente mais tout le monde en oublie le principal : un jeu commercial c'est très cher à développer il faut un budget élevé j'ai déjà entendu de 20 millions d'euros au minimum .
C'est pas comme un client qui demande à une SSII de lui faire une appli de gestion.
Le client verse des accomptes qui permettent à la SSII de continuer à développer le projet...

Linux=libre=gratuité chose totalement inconcevable pour une boite de jeu et pour un éditeur qui doit payer les frais de conditionnement, le marketing la pub....

Par exemple Electronics Arts n°1 du jeu vidéo a racheté 2 studios de développement..... pour plus de 800 millions de dollars donc cela fait des grosses sommes...

Comme la plupart des utilisateurs d'informatique utilisent Windows eh bien les boites de jeux préférent développer des jeux ciblés sur cette plateforme.
Surtout que le problème avec Linux c'est qu'il y a pléthore de distributions et que les jeux ne fonctionnent pas toujours .
C'est pas trop une question de technique c'est purement commercial...
Faut pas perdre de vue qu'un studio de développement risque de couler lorsqu'il développe un jeu parce qu'il n'est pas toujours soutenu financièrement ( d'où les nombreuses acquisitions dans le domaine économique du JV ).
Tu as beau investir des millions d'euros et Linux a beau être évolué techniquement, ton jeu a beau être un jeu qui "tue", si le public ne suit pas et que ton jeu fait un flop eh bien tu n'as plus qu'à fermer la boite...

[Mat.M]

Dans ce cas, je suppose que Linux contient des bibliothèques fort semblable à celle de windows, il devrait donc exister des programmes capable de faire la conversion des codes d'un sytème à l'autre ?

Est-ce que les développeurs de jeux utilisent des librairies windows genre .NET qui sont trop tordue et qui n'ont pas été repris dans cette forme sur Linux ?

Mais que cela tourne sous Linux ou Windows c'est pas le problème....le problème c'est de pouvoir gagner de l'argent avec le jeu que tu as développé.
Est-ce que tu comprends ?
Quant aux jeux commerciaux purement .NET à ma connaissance il n'en existe aucun ..

[Happy]

Money, money, money;

Même s'il tes 'trop tôt', penser « cross platform » est le nouveau point de vue des nouvelles boîtes de jeux. Vu que tôt ou tard on voudra que n'importe qui puisse jouer à son jeu sur sa plate-forme préférée.

Il sera alors question que de recompiler un binaire linux et les linuxens auront qu'à se débrouiller pour le faire marcher ...

Faut commencer à bien faire attention; ne pas se faire piéger sous windows avec des excellentes bibliothèques NON portables.

[Mat.M]

Même s'il tes 'trop tôt', penser « cross platform » est le nouveau point de vue des nouvelles boîtes de jeux. Vu que tôt ou tard on voudra que n'importe qui puisse jouer à son jeu sur sa plate-forme préférée.

Développer un jeu c'est un risque financier pour l'éditeur et le studio de développement je le répête.
PAr exemple je viens d'installer Flight Gear un simulateur de vol libre et gratuit, sous XP.
Les avions s'affichent mal je ne sais pas pourquoi j'ai pas le temps à perdre pour piger ce qui ne fonctionne pas donc je l'ai désinstallé.
Peut-être que sous Linux cela fonctionnerait mieux bref j'ai pas le temps..
Je préfère claquer 60 dollars ( ou 50 euros ) pour FSX de Microsoft le simulateur de vol le plus abouti que d'utiliser quelque chose du libre qui ne fonctionne pas.
Le gros problème sous Linux c'est qu'il n'y a pas une plateforme logicielle mais plusieurs.
Un jeu commercial c'est testé intensément par des sociétés spécialisées de tests et localisations de JV donc c'est impensable pour ces sociétés de passer leur temps à tester sur 10 distributions de Linux alors que sous M$ c'est soit XP soit Vista avec quasiment une seule API en l'occurence Direct X

il n'y aura jamais un marché du JV pour Linux comme il y a pour Windows.
Cela fait des années que la presse spécialisée en parle mais je ne vois pas de développement de ce segment là.

[deadalnix]

Même s'il tes 'trop tôt', penser « cross platform » est le nouveau point de vue des nouvelles boîtes de jeux. Vu que tôt ou tard on voudra que n'importe qui puisse jouer à son jeu sur sa plate-forme préférée.

Il est pas trop tot pour penser cross plateformes. Unreal engine 3 ou bien tech5 d'id software peuvent tourner aussi bien en openGL qu'en directX, sous windows, linux ou bien PS3 et Xbox, et meme en 64 bits .

Sans penser forcement linux, faire un jeu qui tourne aussi sous Xbox et sous PS3 en plus du pc est un tres tres gros plus, et ceci necessite de faire marcher le tout avec openGL ou bien directX . Notons que ceci est possible via l'utilisation de classe abstraites manipulées dans le moteur (en C++).

[shenron666]

Sans penser forcement linux, faire un jeu qui tourne aussi sous Xbox et sous PS3 en plus du pc est un tres tres gros plus, et ceci necessite de faire marcher le tout avec openGL ou bien directX . Notons que ceci est possible via l'utilisation de classe abstraites manipulées dans le moteur (en C++).

directx n'existe pas sur ps3 donc c'est opengl obligatoire ET directx pour le X360 (à moins qu'il y ait eu un portage d'opengl sur xbox ?)

quand aux classes abstraites, elle ne sont pas "responsables" de la portabilité d'un soft, ou alors tu t'es mal exprimé

[deadalnix]

Ce que je voulais dire, c'est que grace aux classes abstraites, tu est pas obligé de develloper deux versions completes de ton soft.

Tu calle tout ce qui conerne directX/openGL dans un classe et tu manipule une classe abstraite dans le reste du moteur. Comme ca il n'y a que cette classe a develloper en double.

Et oui, sinon, la PS3 c'est de l'openGL et la xbox du directX . . .

[bafman]

Ce que je voulais dire, c'est que grace aux classes abstraites, tu est pas obligé de develloper deux versions completes de ton soft.

sauf qu'en général, on essaye d'éviter les classes abstraites qui, dans ce cas la, sont une relativement mauvaise idée.
En effet, les machine ne supportant qu'une seule API, ça ne sert à rien de faire payer le cout à l'exécution alors que le branchement peut se faire en statique à la compilation avec des bon vieux #ifdef.

utiliser des classes abstraites pour choisir l'API n'a de sens que si tu souhaite pouvoir changer d'API sans avoir à recompiler le programme (ce qui n'est pas la cas sur console, mais qui peut arriver sur PC par contre)

[shenron666]

je vois mieux ce que tu veux dire deadalnix
même si je suis plutot du même avis que bafman
l'un n'empêchant pas l'autre, le tout étant d'avoir le renderer du "moteur" bien séparé de l'api utilisée par le renderer en interne

[LapinGarou]

Je viens mettre mon grain de sel, mais les moteurs cross plateformes ne sont ils pas moins performants ?
Puisque non optimisés (ou du moins pas autant) pour une API spécifique, du fait que le code doive être un tantinet "générique", j'aurai tendance à dire que oui . (souvent les jeux qui proposent 2 APIs ne sont optimisés que pour une, l'autre n'étant là que pour les cas difficiles d'utilisation de la principale) Mais je me trompe peut-être ?