Sony améliore le SDK PS3

[sdekaar]

...qui sera disponible au prix de 950.000 yens au Japon, 10.250 $ aux Etats-Unis et 7.500 € en Europe, prix hors taxe.

tien donc pour les devellopeurs sony respecte le taux de change

[erwan2004]

...qui sera disponible au prix de 950.000 yens au Japon, 10.250 $ aux Etats-Unis et 7.500 € en Europe, prix hors taxe.

tien donc pour les devellopeurs sony respecte le taux de change

lol oui .

C'est pour le Pros pas pour le tout publique .

[baboulette]

les optimisations en assembleur c'est à sony de les faire dans son SDK, c'est plus le boulot des développeurs, sauf les dév 3D qui font les shaders mais c'est un SDK nvidia dans ce cas

Les optimisations, n'ont jamais étés totalement faites par le producteur du sdk, d'ailleurs bcp de firmes developpent leurs propres outils, codes optimisés hors sdk, ca a tjrs été le cas ..

Le sdk, est un outil, pas du boulot maché, sony ne peut pas prendre en compte les desideratas de chaques devs, dans les optimisations ..

Je pense que la mojorité des devs sont retissants à sortir de leurs petites habitudes, mais c'est le boulot qui veut ca , la techno évolue, et si on veut des consoles perenes, il faut un hardware novateur à chaque machine.

Evidament sony doit aussi faire son boulot de son coté, et je pense que c'est pas le sdk qui doit etre le vrai fautif, mais le peu de soutien de sony pour aider les devs.

J'ai l'impression que sony fait comme Ms sur windows, moins les autres en savent mieux c'est pour nos propres jeux.

Modifié le 25 novembre 2007 par baboulette

[deagle]

si sony se concentre surtout sur ses propres studios ça risque de devenir comme nintendo..

moi je parlais surtout des optimisations type graphiques comme un driver super optimisé pour une seule carte graphique sur un pc par exemple, pas des optimisations des jeux comme le chargement en streaming des textures et tout ça

mais le cell doit donner du fil à retordre aux dév qui veulent avoir le max de perfs ça c'est sûr

[baboulette]

si sony se concentre surtout sur ses propres studios ça risque de devenir comme nintendo..

moi je parlais surtout des optimisations type graphiques comme un driver super optimisé pour une seule carte graphique sur un pc par exemple, pas des optimisations des jeux comme le chargement en streaming des textures et tout ça

mais le cell doit donner du fil à retordre aux dév qui veulent avoir le max de perfs ça c'est sûr

Sans etre fans de sony (contrairement a ce que je laisse paraitre), j'espere qu'on en arrivera pas la , pour le bien des JV ..

La concurence y'a que ca de vrai.

Par contre je suis d'accord avec toi, la Ps3 n'est pas facile, et sony à interet à plus soutenir le developpement sur sa plateforme, si ils veulent du bon jeu ..

Mais je pense que comme moi, tu es quand meme en droit d'attendre autres choses que des railleries pour des jeux qui sont qd meme facturés 70 euros ..

Modifié le 24 novembre 2007 par baboulette

[ouasse]

les optimisations en assembleur c'est à sony de les faire dans son SDK, c'est plus le boulot des développeurs, sauf les dév 3D qui font les shaders mais c'est un SDK nvidia dans ce cas

Sur le Cell on peut programmer les SPE en C, si on est sûr de son compilateur.

C'est quand même très clair que le niveau max d'optimisation sur les SPE ne sera de toutes façons atteint QUE si on programme en assembleur, même si on peut avoir un résultat pas trop pourri en C, et encore, il faut faire du C SPE-friendly sinon on aura des perfs toutes pourries. Et pour cela il faut avoir une connaissance minimale de l'assembleur même si on ne tape pas directement au niveau de l'assembleur. C'est une sorte de programmation en langage C qui n'utiliserait pas les types de base du C (int, char, float, ...) sauf pour les variables locales. Dès qu'on tape dans les structures de données complexes il faut tout stocker en vecteurs, le type le plus efficace sur SPE. Et pour comprendre pourquoi, il faut avoir une connaissance minimale de l'archi et des instructions assembleur de base.

le cell doit donner du fil à retordre aux dév qui veulent avoir le max de perfs ça c'est sûr

ça, c'est clair et net ! mais au vu des résultats qu'on peut obtenir, ça vaut franchement le coup de se creuser un peu la tête.

Modifié le 25 novembre 2007 par ouasse

[Inimz]

Perso, je suis d'accord avec fornorst et ouasse ...

C'est vrai qu'actuellemnt le niveau des language de haut niveau est tel, que pour la majorité des applis, qui n'ont pas besoins de vitesse de traitements particuliere, l'assembleur ou le C servent, mais à rien du tout ..

Pour ouasse, je pense qu'il faisait juste une comparaison, pour dire que les devs(editeurs) sacrifient le travail, et la creativité pour faire au plus facile.

Ce qui fait qu'ajourd'hui, on a presque que du jeu pc sur 360 et dans une moindre mesure sur ps3.

Ils sont ou les jeux novateurs du debut de la 360 ???

Bah remplacé à fond par du fps, meme de qualité ,sa saoule à force, autant se prendre un pc, et payer le jeux 50 euros max, avec des mods gratuits à tout vas ..

Désolé baboulett mais je pense que tu manque de connaissance pour pouvoir affirmer ça? Je vais essayer de te montrer que tu es dans l'erreur dans ce que tu dis:

Voici globalement l'architecture d'un jeu multi plateforme, pour un souci de simplicité le schéma que je montre est très simpliste est générique, mais le principal est la:

Comme tu peux le constater tout le gamecode a quelques exceptions pres reste indépendant de la plateforme utilisée. Ce qui veut dire que tu peux avoir n'impote quelle console, n'importe quel PC, que les composant hardware soient proches du PC, que l'API 3D utilisée soit DX ou OGL, cela ne change en rien le Gamecode qui est donc le code du jeu avec le gameplay etc. Donc a partir du moment ou la base du jeu est unique pour toutes les plateformes, seules les couches spécifiques à la plateforme different, et cela n'intervient pas dans la créativité des développeurs. On ne cherche pas la simplicité, mais plus le temps passe, plus les jeux deviennent complex et plus on a besoi de support pour pouvoir traiter tous les aspects d'un jeu qui n'existaient pas avant et qu'il faut integrer aujourd'hui. C'est grâce à ce genre de facilité qu'on peut se permettre d'évoluer et créer des jeux de + en + complexe. Imagine un Crysis en assembleur...

Donc pour terminer, comme la couche gamecode est indépendante et générique aux plateformes, bah le mieu pour nous les développeurs c'est d'avoir le moins de travail possible pour créer ces différentes couches spécifiques au plateformes, car de base, on unifie le code, puis obligatoirement on doit le spécifier pour un support donné, mais la base reste la meme, donc ce dont tu plains est incohérent... Pour en revenir a Sony qui veut simplifier son SDK, le probleme etait donc la. C'est a dire que chaque equipe occupée a implémenter la couche de spécification de la plateforme doit se demerder pour que le gameCode soit retranscris correctement a l'ecran, et c'est la ou le bas blesse pour sony. Pas vraiment de probleme sur PC ou Xbox de créer ces couches spécifiques, par contre pour la ps3 ils ont beaucoup + de mal, a cause du SDK existant et complétement différents de ceux qu'on retrouve sur PC ou XBOX.

Une derniere chose, la je dis peut être des bétises mais corrigez moi si je me trompe. Je pense que la structure du CELL implique des changements importants dans le gamecode, notamment au niveau de l'utilisation des SPE (pour l'ia par ex), et je pense que ça doit etre un vrai souci pour les développeurs, car cela doit casser la générécité du gamecode et que pas mal de spécifs doivent etre présentent pour la ps3 ds cette partie justement...

Modifié le 27 novembre 2007 par Inimz

[Inimz]

ça doit être uniquement du C++ sur ps3, et du C++/C# sur 360, vu la nature des autres langages cités.. (C trop peu pratique en POO, C# uniquement compatible Microsoft, java trop lourd qu'il soit interpreté ou compilé, les autres oubliez..)

un SDK c'est essentiellement des méthodes graphiques, sonores, de gameplay (boutons de la manette,etc..), réseau, accès disque dur/disque optique, interruptions (genre on appuie sur le bouton PS ça déclenche une interruption)..

mais le langage de prog n'a rien à voir là dedans

Petit précision . Le C# en lui même n'est pas exclusivement Microsoft, prend SharpDevelop par ex qui est un IDE C# et qui n'a rien a voir avec Microsoft. Seul le frameWork .NET est exclusif a Microsoft. Bon d'accord le C# sans .NET du coup ça rime plus a grand chose.. mais bon je voulais préciser ça quand meme

[deagle]

enfin je disais surtout ça par rapport à la ps3 : ils développeront jamais en C# sur ps3

[KaMbiOkIkA]

Salut Inimz... on se connait nan ?

Sinon, le C#, n'est qu'une évolution du C++, qui est lui-même une évolution du C. Tout ce qu'on sait faire en C# est faisable par conséquent en C++, et en C. La seule différence, c'est que chacune de ces évolutions a réduit le nombre de lignes à taper pour effectuer des "taches" courantes.

++

Modifié le 27 novembre 2007 par KaMbiOkIkA

[baboulette]

Salut Inimz... on se connait nan ?

Sinon, le C#, n'est qu'une évolution du C++, qui est lui-même une évolution du C. Tout ce qu'on sait faire en C# est faisable par conséquent en C++, et en C. La seule différence, c'est que chacune de ces évolutions a réduit le nombre de lignes à taper pour effectuer des "taches" courantes.

++

Inimz, en programation evidament qu'il y'a du code commun malgres les differences d'architecture.

un printf sera le meme sur 360 ou PS3 ou gameboy, c'est le compilo qui se demerde, mais des que tu attaques les spécificités du proc ou de la CG, gestion de la ram, le code n'a plus rien a voir ..

D'ou les API ..

et si les API ne conviennent pas, bein il faut mettre les mains dans le camboui ..

Et si tu gere le cell comme le proc de la 360, ou la ram de la ps3 comme celle de la 360 (l'inverse est vrai aussi), bah ca donne pas grands choses de bien.

D'ou les problemes (ca n'engage que moi), sur les portages PS3..

Modifié le 27 novembre 2007 par baboulette

[erwan2004]

Inimz, en programation evidament qu'il y'a du code commun malgres les differences d'architecture.

un printf sera le meme sur 360 ou PS3 ou gameboy, c'est le compilo qui se demerde, mais des que tu attaques les spécificités du proc ou de la CG, gestion de la ram, le code n'a plus rien a voir ..

Printf (commande qui permet d'afficher un texte) =

-> Programme pour win32 console, affichage du texte dans un console .

-> Programme pour Dreamcat , affichage du texte dans le fenêtre de débuggage (pas à la TV) .

Et si tu gere le cell comme le proc de la 360, ou la ram de la ps3 comme celle de la 360 (l'inverse est vrai aussi), bah ca donne pas grands choses de bien.

D'ou les problemes (ca n'engage que moi), sur les portages PS3..

Y a un truc qui s'appelle un kernel (noyau) est qui fait ce boulot à la place d'un programmeur .

Modifié le 27 novembre 2007 par erwan2004

[KaMbiOkIkA]

Inimz, en programation evidament qu'il y'a du code commun malgres les differences d'architecture.

un printf sera le meme sur 360 ou PS3 ou gameboy, c'est le compilo qui se demerde, mais des que tu attaques les spécificités du proc ou de la CG, gestion de la ram, le code n'a plus rien a voir ..

D'ou les API ..

et si les API ne conviennent pas, bein il faut mettre les mains dans le camboui ..

Et si tu gere le cell comme le proc de la 360, ou la ram de la ps3 comme celle de la 360 (l'inverse est vrai aussi), bah ca donne pas grands choses de bien.

D'ou les problemes (ca n'engage que moi), sur les portages PS3..

On doit pas parler des même choses je pense. Aujourd'hui, qui travaille sans API ? A part pour faire du calcul brut, et encore, personne. C'est d'ailleurs tout l'intérêt d'un SDK. Pas d'API, pas besoin de SDK.

Ensuite, pour ce qui est du dév sur PS3, ce n'est pas la "configuration" de la machine qui est génante, mais son principe de fonctionnement et de développement, qui remet en cause certains aspects "ancestraux" en développement de jeux. Si tu regardes bien d'ailleurs, des configurations très différentes : RAM, CPU, GPU, ... il y en a beaucoup + sur PC qu'entre ces 2 consoles, et pourtant personne ne se plaint sur PC.

++

[baboulette]

On doit pas parler des même choses je pense. Aujourd'hui, qui travaille sans API ? A part pour faire du calcul brut, et encore, personne. C'est d'ailleurs tout l'intérêt d'un SDK. Pas d'API, pas besoin de SDK.

Ensuite, pour ce qui est du dév sur PS3, ce n'est pas la "configuration" de la machine qui est génante, mais son principe de fonctionnement et de développement, qui remet en cause certains aspects "ancestraux" en développement de jeux. Si tu regardes bien d'ailleurs, des configurations très différentes : RAM, CPU, GPU, ... il y en a beaucoup + sur PC qu'entre ces 2 consoles, et pourtant personne ne se plaint sur PC.

++

Bah non justement depuis DX, qui est une HAL pour les perifs ,pas besoind de se prendre la tete, c'est les constructeurs qui s'adaptent, d'ailleurs,

les cartes videos et audios integrent des fonctions non DX, qui ne sont quasiment jamais utilisées,sauf qd certains devs,decident d'optimiser un jeux pour une carte d'un constructeur.

Ce que je veux dire c'est que les APi ca sert c'est sur, mais ca limite aussi à ce que le concepteur de l'API a bien voulu mettre en oeuvre ..

Si par exemple tu veux faire une carré 3D rose à points jaunes et que l'api ne le permet pas, faut bien passer par autres parts non ???

Il est la mon résonnement, sur le fait que les concepteurs d'API ne pensent pas à tout, sinon elles ne seraient pas en constantes evolutions.

Quoi qu'il arrive, une API limite à un moment, d'ailleurs les dernieres versions de .NET incluent encore MASM le compilateur assembleur,il existe même en version 64 bits, donc faut arreter de croire que l'assembleur est une affaire de geeks des années 60 ..

En fait kambiokika, personne ne dit que les devs se passent d'API, juste que je dis que les devs utilisent encore l'assembleur,pour palier les manques des API ..

Modifié le 27 novembre 2007 par baboulette

[ouasse]

100% d'accord avec baboulette, surtout que bien souvent dans un jeu le processeur passe 99.9% du temps sur 0.5% du code, donc l'utilisation de l'assembleur pour ces 0.5% est largement justifiée.

Un code exécuté une fois, qu'il soit en C++ ou assembleur, on ne verra pas vraiment la différence. Un code exécuté 10 millions de fois par seconde, on commence à saisir l'intérêt de l'optimiser en assembleur. Surtout que généralement la partie centrale du code le plus exécuté va faire au maximum 30 ou 40 lignes de code C, ce qui n'est pas la mort à optimiser en asm

[erwan2004]

Arrétez votre trip sur l'assembleur .

Les compilos C, C++, ect, d'aprés vous il font quoi ?

Ils transforment un code source en binaire en passant par une étape assembleur .

Biensur, on peut gagner quelques cycles en ayant une bonne connaissance de la plateforme mais 2 problèmes:

1° L'assembleur c'est pas portable donc faut tout réécrire .

2° Comme tout langue de bas niveau, c'est lomg à écrire donc couteux en main d'oeuvre .

Bref, c'est surtout un problème économique.

Quand a API, si des fonctions ne sont pas prit en charge, tu l'aurra dans le c*l .

Vu que les console nextgen, on des securités dynamique, je doute que les constructeurs te laissent faire ce que tu veux .

c'est juste l'histoire de pas avoir les même bordel que sur leur ancien console .

[KaMbiOkIkA]

Ce que vous dites et pas faux, mais c'est de moins en moins vrai, et surtout pour les jeux. A part les GFX et SFX, le CPU gère tout le reste, IA, physique, ... et cela ne fait pas 30 ou 40 lignes de codes, c'est le plus gros du code d'un jeu. Et sérieusement, l'assembleur est de moins en moins utilisé. Personnellement, je n'en ai plus vu cer dernières années sauf dans les codes "exotiques" : le hack, linux, les émulateurs, ... mais très rarement avec des applications professionnelles.

Maintenant, c'est sur que DX par exemple est très proche du hardware, donc cela réduit l'utilisation de code "simplifié".

Ensuite, on peut toujours optimiser le C et dérivé par l'assembleur, mais si on analyse un peu les 2 languages, très peu d'opérations C sont loin de leur homologue en assembleur. Et produire un SDK, c'est faire en sorte aussi que le code assembleur généré par le compilateur C/C++/C# soit le plus proche possible de ce que l'on aurait fait en assembleur.

Le problème dans ce topic, c'est que chacun prend un exemple, certe réel, mais pas adapté spécifiquement au développement de jeu. Chaque domaine de développement a un intérêt principal différent d'un autre. Certains domaines ont besoin de puissance de calcul maximum, d'autre de temps de développement les plus court possible, ... On ne peut pas tout avoir. Pour les jeux, c'est un mix du tout actuellement, et il faut être rapide quasiment partout. Seulement si aujourd'hui, il faut tout refaire à chaque fois en pensant que pour ça, il faut tout calculer avec grande attention tous les moindres détails, c'est plus jouable. Soit on aurait des jeux pas plus beau que sur MegaDrive, soit on attendrait 5 ans pour avoir un jeu finalisé. Et si on regarde bien depuis le début, on tourne en rond dans le sujet. Un coup ca gueule parce que les jeux augmentent parce que les temps de développement sont + longs, un coup ça gueule parce que les jeux sont pas optimisés, ... il faut un juste milieu, et si Sony fait des efforts, c'est qu'il y a une raison, et surement pas parce que les développeurs, tierces ou pas, sont fainéants, incapables ou je ne sais quoi.

Plus globalement, je repose une question, puisque personne ne se demande pourquoi Sony a décidé de mettre le RSX quasi au dernier moment ... ?

++

[erwan2004]

La réponse est simple (et tu connais déjà la réponse):

Standardiser les composants pour facilité le développement.

Avec une puce Nvidia, on est sure du connu et maitrisé .

Modifié le 28 novembre 2007 par erwan2004

[ouasse]

1° L'assembleur c'est pas portable donc faut tout réécrire .

oui, c'est pas portable, et non, il ne faut pas tout réécrire. Il s'agit d'identifier les parties de code les plus souvent exécutées et ça se résume au maximum à 3 ou 4 boucles par-ci par-là.

2° Comme tout langue de bas niveau, c'est lomg à écrire donc couteux en main d'oeuvre .

Je ne parle pas de convertir des algos complets en assembleur, ça n'a aucun sens. Mais l'utilisation d'une petite librairie simple de fonctions assembleur pour des opérations très simples mais effectuées très souvent (ex: produit matrice/vecteur pour la 3D, application de formules de physique, etc.) peut tout changer.

Dans un algo complexe, écrit en C, tu peux user et abuser d'appels de fonctions écrites en assembleur. A la limite, les fonctions en question peuvent avoir un pendant écrit en C, comme ça tu utilises l'assembleur là où c'est disponible, et la version C sinon. Comme ça on est pas obligé de tout réécrire d'une machine sur l'autre, ca dépend si ça vaut le coup de le faire en assembleur ou non.

En plus sur la PS3 avec le Cell c'est d'autant plus intéressant qu'on peut envoyer du boulot à faire à un SPE, ce qui libère le CPU pour faire autre chose dans un autre thread.

Ce que vous dites et pas faux, mais c'est de moins en moins vrai, et surtout pour les jeux. A part les GFX et SFX, le CPU gère tout le reste, IA, physique, ... et cela ne fait pas 30 ou 40 lignes de codes, c'est le plus gros du code d'un jeu.

Les fonctions de base (calcul matriciel, calculs de physique) ne sont pas grosses, ce sont les algos qui sont autour qui le sont. Pas besoin d'implémenter un algo entier en assembleur, mais d'utiliser l'assmebleur là où c'est nécessaire.

Et sérieusement, l'assembleur est de moins en moins utilisé. Personnellement, je n'en ai plus vu cer dernières années sauf dans les codes "exotiques" : le hack, linux, les émulateurs, ... mais très rarement avec des applications professionnelles.

Un jeu vidéo n'est pas une application professionnelle : il y a des contraintes supplémentaires, les architectures sont fixes. Il faut faire avec l'existant.

Une application professionnelle, c'est moins contraignant : tu peux faire tourner une appli plus rapidement en utilisant un PC plus rapide.

[Inimz]

Les compilos c/c++ sont tellement optimisés aujourd'hui que plus grand monde n'utilise l'asm dans les jeux, à part pour optimiser quelques routines mais bon ca repsente moins de 0,1% du code... Sinon je répondais surtout au fait que certains se plaignent que le materiel des differentes plateformes soient trop proches et que tout se ressemble. Oui et non, ce qui fait la différence pour moi entre ces machines, ce ne sont pas les API, ni le hardware proprement dit, mais plutot le contexte dans lequel une personne va jouer. C'est a dire d'un coté le clavier souris, de l'autre le Pad. D'un côté le gars sur sa chaise, de l'autre le gars dans son canapé. Et ce contexte fait qu'indéniablement tu as des types de jeu + ou - adapté à ces contextes, avec certains qui peuvent être en adéquation avec toutes les plateformes (jeux de voiture par exemple). Mais avec l'évolution des machines on arrive petit a petit a migrer de nouveu genre de jeu sur console (les FPS notamment). Mais le context dans le lequel joue une personne oriente dès le départ le type de jeu que tu peux produire ( implicitement qui peux ete entable ). Alors les SDK&Co ne sont que des outils pour créer un produit vidéo ludique, si Sony a décidé de l'améliorer c'est que déja par réputation ils fournissent des outils qui ne sont pas en phase avec les développeurs, et si après toutes ces années de désinteret envers les dev, ils osent avouer que leur SDK doit être améliorer c'est qu'il y a une couille dans le paté...

*Camb oui on se connait

Modifié le 28 novembre 2007 par Inimz

[brownsrequiem]

et si après toutes ces années de désinteret envers les dev, ils osent avouer que leur SDK doit être améliorer c'est qu'il y a une couille dans le paté...

Est-ce que ce n'est pas simplement parce qu'ils veulent absolument interesser les développeurs à venir sortir des jeux sur leur console ? Ils n'ont plus le monopole comme par le passé et ils ne peuvent plus se permettrent d'être intransigeants tout simplement aussi (en parfait accord avec cette baisse de prix)

Modifié le 28 novembre 2007 par brownsrequiem

[KaMbiOkIkA]

En support de développement, Sony n'a jamais été une référence, mais si aujourd'hui ils font cela, c'est simplement, que le RSX seul ne permettra pas de faire mieux que la X360, concurrente directe, et voir même égaler, qualitativement j'entends. Si la PS3 veut s'affirmer, il faut quoiqu'il arrive dealer avec le Cell. Et comme tu le dis, si aujourd'hui la PS3 représentait un potentiel de ventes plus important que les autres plateformes, il serait possible de s'y attacher un peu +. Maintenant, ce n'est pas le cas, et d'un point de vue investisseur, il me semble normal de ne pas dépenser 10, 20 ou 30 % de temps humain en + pour n'en tirer qu'au mieux 50% de ventes qu'à côté. Après c'est sur, que les studios qui développent exclusivement sur PS3 peuvent pas vraiment se permettre de dropper la PS3... Tout, mais tout, n'est qu'une question d'argent dans cette histoire. Et Sony réagit très bien à vrai dire, car il ne faudrait pas que de nouvelles bombes vidéo ludiques lui passent sous le nez, alors autant mettre tous les atouts de son coté.

++

[baboulette]

Comme le dit ouasse, il est evident que les devs ne vont pas faire un jeu complet en assembleur, faudrai etre taré ..

Mais certaines partie qui ont besion de vitesse,ou d'un acces particulier au hard impossible a faire en C (et oui le C ne fait pas tout) ..

En terme de jeux, l'assembleur reste et restera tjrs present ..

Le rsx a été ajouté car un processeur ne peut pas rivalisé avec un circuit specialisé, surtout avec tout le reste à gerer.

D'ailleurs, une societe russe, a montrée qu'elle crackait les mot de passe vista en 1 semaine avec un 8800,alors qu'il faudrai plus d'un moi a un core2duo @3ghz pour en faire de même..

Par contre kambiokika a raison, il faudra parler au cell pour tirer vraiment quelque chose de la ps3,sans utilisation correcte des SPE, elle fera pas trop de miracle

Et elle en fera pas non plus avec du code optimisé pour la 360 ..

Modifié le 28 novembre 2007 par baboulette

[KaMbiOkIkA]

Juste une précision quand même la dessus :

En terme de jeux, l'assembleur reste et restera tjrs present

C'est une idée fausse, l'assembleur n'est plus utilisé, et on peut de nos jours, y compris en C/C++/C# s'en passait sans problème pour les jeux. Les compilateurs sont très performants de nos jours quand au code ASM qu'ils génèrent, et les SDK spécifiques aux développements de jeux, en rajoutent encore une couche d'optimisation. L'évolution des processeurs aussi a grandement joué, avec les caches processeurs. J'ai connu une époque (680x0 par exemple) où le cache ne faisait que 256 octets... il fallait être un génie pour faire du code ne dépassant pas 256 octets et la l'ASM était obligatoire pour obtenir des performances. Aujourd'hui avec des caches de 512k ou 1Mo, ca n'a plus rien à voir : c'est énorme ! juste pour info, on peut y mettre un bios XBox 1 complet... alors autant dire que l'ASM ou le C... ca va pas faire grande différence. Et surtout, sur les jeux actuels, on gagne beaucoup plus à optimiser les mesh et objets 3D qu'à passer un code C et dérivés en ASM.

++

[ouasse]

d'après ce que certains écrivent, on dirait qu'ils ne connaissent absolument rien à l'architecture du Cell. Amusez vous à programmer un SPE en C pur sans avoir aucune connaissance de l'archi, et je vous garantis que vous aurez des perfs pitoyables.

Le Cell n'est pas un pentium, il a plusieurs coeurs hétérogènes, et certains sacrifices ont dû être effectués pour limiter le nombre de transistors: pas de prédiction de branchement, pas d'accès mémoire non-alignés sur des vecteurs de 128 bits, notamment. Cela est en partie compensé par certaines instructions assembleur, et cela induit une manière de programmer totalement différente. On peut programmer du code SPE efficace en C, mais ce sera du code qui de toutes façons ne fonctionnera que sur SPE, et qui en exploitera au maximum les capacités.

Modifié le 29 novembre 2007 par ouasse