Le Source Engine de Valve, pas natif OpenGL ?
Valve avait annoncé que le portage de ses jeux sur Mac serait un vrai portage natif. Or en inspectant les fichiers du Source Engine, Netkas s'est aperçu qu'il était fait mention de conversion DirectX.
Le sujet a été levé sur le forum de Steam, et Rob Barris y a répondu :
« J'ai écrit le module OpenGL pour la version Mac de Source. Il présente au moteur une interface compatible avec DirectX9, le moteur fait appel à moi, je fais appel à OpenGL, des points apparaissent.
Les problèmes de performance en question sont de manière générale au niveau des pilotes - en dessous de cette couche. Cette interface ne démontre aucun ralentissement notable dans nos tests.
L'application a été compilée avec gcc en binaire natif Mach-O en utilisant les outils de Mac OS X »
La polémique est il est vrai quelque peu abusive : tous les jeux portés de Windows à Mac OS X, aussi "natifs" soient-ils, utilisent ce système d'interface DirectX-OpenGL. Aspyr et Feral Software utilisent le même procédé pour porter leurs jeux sur Mac, à l'aide d'une interface DirectX-OpenGL qu'ils utilisent dans chacun de leurs portages. Ce qui permet également d'avoir des mises à jour globales du code entre Windows et Mac OS X sans avoir à tout réécrire. Rappelons également que le passage d'une ligne de code à l'autre (ce qu'implique ce découpage des fonctions) prend à peu de chose près un cycle processeur, et que les Core 2 Duo qui équipent nos Mac en exécutent plusieurs milliards par seconde…
Par ailleurs, puisqu'il en est question, notez que Portal a été mis à jour. Il vous suffit de lancer Steam pour que la mise à jour soit téléchargée et installée automatiquement.
Le sujet a été levé sur le forum de Steam, et Rob Barris y a répondu :
« J'ai écrit le module OpenGL pour la version Mac de Source. Il présente au moteur une interface compatible avec DirectX9, le moteur fait appel à moi, je fais appel à OpenGL, des points apparaissent.
Les problèmes de performance en question sont de manière générale au niveau des pilotes - en dessous de cette couche. Cette interface ne démontre aucun ralentissement notable dans nos tests.
L'application a été compilée avec gcc en binaire natif Mach-O en utilisant les outils de Mac OS X »
La polémique est il est vrai quelque peu abusive : tous les jeux portés de Windows à Mac OS X, aussi "natifs" soient-ils, utilisent ce système d'interface DirectX-OpenGL. Aspyr et Feral Software utilisent le même procédé pour porter leurs jeux sur Mac, à l'aide d'une interface DirectX-OpenGL qu'ils utilisent dans chacun de leurs portages. Ce qui permet également d'avoir des mises à jour globales du code entre Windows et Mac OS X sans avoir à tout réécrire. Rappelons également que le passage d'une ligne de code à l'autre (ce qu'implique ce découpage des fonctions) prend à peu de chose près un cycle processeur, et que les Core 2 Duo qui équipent nos Mac en exécutent plusieurs milliards par seconde…
Par ailleurs, puisqu'il en est question, notez que Portal a été mis à jour. Il vous suffit de lancer Steam pour que la mise à jour soit téléchargée et installée automatiquement.
@ TequilaPhone : je le tiens de John Stiles, qui a porté nombre de jeux de Blizzard sur Mac et qui est un vieux copain.
@nonoche
Ah ok, tout le monde dans le même panier quoi :/
@ TequilaPhone : encore une fois, l'impact sur les performances est négligeable. Quoi qu'il en soit, le portage du Source Engine sur Mac n'est pas moins natif que n'importe quel autre portage. Les différences qu'on constate en termes d'exécution entre Windows et Mac OS X viennent du système et non du portage.
Oui, cela ne concerne QUE les portages.
Je crois que nonoche a donné la meilleure explication jusqu'à date. Sinon, les performances de Steam sont très acceptable sur mon MBP 2007, même si j'ai le problème des portails noirs depuis la dernière update, comme plusieurs personnes.
@nonoche :
D'ailleurs avec un bon compilateur je suppose que la fonction intermédiaire est supprimée. C'est impressionnant ce que les compilateurs réalisent comme optimisation.
Bref effectivement l'impact sur les perfs est totalement négligeable, par contre l'impact sur le temps de développement est énorme !
Et je n'ai pas trouvé les performances mauvaises sur mon MBP (9400M inside), c'est kif kif avec la version Windows sur la même machine. Par contre j'ai aussi le bug des portails noirs.
@ ErGo_404 : précisément, ça n'a aucun sens de remplacer les appels à DirectX un par un dans la mesure où on peut le faire une fois pour toutes pour chacun d'entre eux, pour des performances similaires. Le rapport temps de développement/résultat ne le justifie absolument pas, encore moins quand on dispose déjà de telles bibliothèques. C'est la raison pour laquelle tous les jeux sont portés de cette façon.
A noter que certains codes sources sont plus "agnostiques" (et propres) dans la mesure où au lieu d'attaquer directement DirectX ils passent par une fonction intermédiaire qu'il suffit de remplacer lors d'un portage (typiquement ce qui se passe avec un moteur de jeu). En pareil cas les différences de performance, à matériel égal, sont directement imputables aux implémentations respectives de DirectX et OpenGL (si on fait abstraction des appels aux autres API du système).
J'ai fini Portal en une après-midi.
Bien sympathique ce ptit jeu, merci à Valve de l'offrir gracieusement.
Les passages ou il faut se servir de la "dynamique" peuvent même être plutôt jouissif une fois que l'on maitrise bien le truc.
Un must have comme on dit!
Moi je trouve qu'il marche plutôt bien Portal. Du moins il marchait plutôt bien... Depuis qu'il a fait la MAJ je ne peux plus voir à travers les portails, il y a seulement une sorte de texture noire. Je me demande si c'est une question de réglages ou si c'est pareil pour tout le monde. Quelqu'un pour confirmer? Merci!
Jveux pas passer pour un rabat joie, et j'ai toujours été un adorateur du natif et de l'optimisation en toute circonstance, mais .... le Cider de portal marche mieux que la version qu'ils nous ont sorti. J'espère qu'ils feront de nombreuses mises a jour.
@Ergo: j'ai bien compris ce qu'est le reverse engineering. Laisses moi te faire comprendre pourquoi j'ai dis cela en te posant une question: penses-tu que Microsoft aie refilé le code à Apple?
@HAL: LOL? Non pas trop. La majorité des jeux sont fait avec DirectX, alors que OpenGL est aussi présent sur Windows. A mon avis pas parce qu'il est meilleur, mais parce qu'il est plus facile à utiliser. Tant que les autres OS n'auront pas DirectX, ils seront sur le carreau pour les jeux. Du coup, certains installent Windows sur leur Mac ou ne quittent pas Windows pour pouvoir jouer. Si ça c'est pas une position hégémonique provoquée intentionnellement en conservant jalousement DirectX sur Windows, je vois pas ce que c'est.
[quote=nonoche]
Explication dans le détail.
Le code source fait appel à une API du système pour afficher de la 3D. Pour simplifier, mettons qu'avec DirectX la commande d'affichage d'un cube ressemble à ça:
DessineCube(coordX, coordY, coordZ, angleX, angleY, angleZ, taille);
[...]
Il suffit d'ajouter la définition de la fonction et de la transmettre à OpenGL en ajoutant ceci au code:
(void) DessineCube(coordX, coordY, coordZ, angleX, angleY, angleZ, taille) {
CubeDessin(taille, angleX, angleY, angleZ, coordX,coordY,coordZ);
}
[...]
[/quote]
Mouais, ben si c'était aussi simple que ça, il suffirait d'écrire des macros en C, utilisées par le compilateur pour remplacer un appel par l'autre, et il y aurait zéro influence en termes de performance.
Et il n'y aurait pas besoin d'un quelconque "module Open GL" pour faire les "traductions" DirectX - Open GL.
Vous affirmez qu'il y a correspondance directe entre les fonctions Direct X et les fonctions Open GL ?
Si c'était le cas, Direct X et Open GL seraient la même chose !
Non : Chaque appel à Direct X est immanquablement traduit par ce module en séries d'instructions pour finir à un ou plusieurs appels à Open GL.
Les performances sont donc nécessairement inférieures avec un tel système que dans le cas où un logiciel est écrit directement en Open GL.
Je l'ai déjà demandé dans un autre fil à ce sujet :
L'auteur du module a-t-il pris la peine de [i]prouver[/i] son affirmation sur le peu d'influence de son module, en programmant deux applications de test identiques en fonctionnalité : L'une utilisant Direct X et son module, et l'autre écrite directement en Open GL ?
Sans un tel comparatif, son affirmation sur un impact minime quant aux performances ne peut être crue que par ceux qui veulent bien la croire. Elle n'a aucun fondement.
Mais l'auteur souhaite-t-il vraiment que soit quantifié précisément l'impact négatif de la solution Direct X + module Open GL face à l'emploi seul d'Open GL ? J'en douterai tant qu'il ne présentera pas de mesures reproductibles.
On arrête l'automasturbation.
Je me rapelle d'une époque pas si lointaine où HL2 et Portal tournaient à fond sur ma petite ATI Radeon 9550 de 2005 (fallais pas trop pousser sur l'anti aliasing bien sur).
Là dans mon MacBook Pro, j'ai une 9400M qui n'est pas capable d'afficher des performances correctes. Alors certes, c'est le début, faut optimiser etc...
Mais si Portal rame, je me demande ce que HL2 va donner, il affiche des scènes beaucoup plus complexes.
Cela dit, je prends plaisir à jouer à Portal sur mon mac et je vais certainement me refaire HL2 avec plaisir !
Pages