C# ou C++

[quote]Donc développer un jeu sur un framework, aussi bien qu’il soit, tel que .NET, est extrêmement problématique pour nous. D’où sa limitation aux outils. Et je pense sincérement que les 5 à 10 prochaines années me donneront raison (il suffit de voir des consoles comme la PSP et la PS3 pour savoir que c’est pas en .NET qu’on va exploiter ces bécanes la)[/quote]Et moi je prend des paris qu’il y aura une API, un JIT, des metadata pour le code et du managed/natif hybride pour console Sony et autre dans les generations de consoles qui viennent. .Net ou pas je m’en fout, je parle du concept.

En plus le marche PC+Xbox ou PS2/PS3 est/sera assez grand pour justifier des developpements independants du reste et la taille totalle est pas vraiment en diminution pour le futur. Si beaucoup de boite de jeu developpent pour PS2, GC, XBox, PC, Mac et GameBoy Advance, c’est pas le cas de tout le monde non plus
Ce message a été édité par GloP le 01/11/2003

(moi aussi je peux faire un nouveau post hein)

Sur PSP ? Ahahah non, pas de JIT à l’horizon, c’est une PS2 trafiquée, donc ça va être du joyeusement à la main, avec de l’assembleur VU écrit avec amour à la main, tu verras. La PS3 ? Vu la gueule du machin et les annonces qu’ils font, ils ont l’air de conserver leur philosophie PS2, c’est à dire du hard super puissant à gérer à la main. J’ai l’impression qu’ils comptent dessus en fait pour jouer sur la learning curve de la plateforme, et donc permettrent une amélioration de la qualité des jeux tout au long de la vie de la console, ce qui n’est pas con.

Donc bref, personnellement, dans ma boite, je ne lancerais pas de développement de jeu en .NET tant que je n’ai pas la certitude ABSOLUE que la plateforme est bien le PC uniquement. Voire le PC et la XBox2 tiens, soyons larges. Et encore, j’hésiterai fortement. Pourquoi ? Parce que sur un jeu, tu développes des technos internes que tu réutilises sur 2, 3, 10 jeux. Et que si ton 1er jeu est PC/XBox, c’est super, mais si le 2ème jeu est GC/PS, la tu l’a dans le fion. Et profond Et ce genre de choses, ça arrive mais au quotidien, littéralement. Certains projets passent par 2 ou 3 éditeurs et 2 ou 3 plateformes avant de sortir. Le développement d’un jeu est un parcours du combattant, et clairement pas un chemin de roses, donc du coup tout le monde se blinde un maximum contre les imprévus de toute sorte.

Je te dis, certains studios, A L’HEURE ACTUELLE, écrivent leurs jeux en C. Pourquoi ? Parce qu’ils sont surs d’avoir un compilo C dispo sur toute nouvelle plateforme qui sortirait, et donc de pouvoir réutiliser leur code dessus directement. C’est te dire la parano du milieu

Bref, je suis un gros fan de .NET, j’adore ça, j’en rêve la nuit (euh… non quand même pas), je fais mes tools avec, mon intro 64ko est aussi partiellement compilable en C++ Managed pour pouvoir faire les tools, etc etc. Mais je te dis, pour les jeux, ça va être très très long avant que le passage se fasse. Par contre, je dis pas qu’on va pas utiliser des trucs genre les Winforms pour remplacer les bons vieux appels a Win32 Ca c’est tres probable je dirais.

Moi, c0unt0, lockeur de frame depuis 1987, ca me fait penser a un truc, votre debat : oui, on ai passe a Win<…>/directX/OpenGL sur pc, oui on va sans doute utilise des trucs bizarre sur PC aussi (pas sur console, enfin en tout cas pas sur ps3 : c’est promis)… bon maintenant on a des machines de courses, donc on peut se permettre de perdre 30% de la frame pour cause d’OS, de sur-couche, et de programmation de haut nivo…

maintenant, prenez les dernier jeux code sur spectrums… et notez le type de performances obtenuent compare aux performance “sur le papier” du bon vieux Zx80 et  imaginez qu’on utilise les meme techniques, et le meme language (ASM RoXor !!! Last night ADC saved my life !) sur une machine courante (comme un PC ou une x-box)… ca laisse a reflechir… non ?

Pourquoi est-ce qu’il y a une telle difference de performance entre les titres premieres generations et les titres de maintenant sur tout ces machines (XBOX/PS2/GCN) ? Parce que plus le temps passe et plus on fait du bas-nivo dessus, plus on se debarasse des libs officiel pour pousser la bete dans ses dernier retranchements (et oui meme sur X-Box)… donc pour moi le JIT et le managed sur console : j’y crois pas avant 2 ou 3 generations, celle d’apres, peut-etre : mais pas celle qui vient !

(et GloP : PS2 R0x0R )

[quote]donc pour moi le JIT et le managed sur console : j’y crois pas avant 2 ou 3 generations, celle d’apres, peut-etre : mais pas celle qui vient ! (et GloP : PS2 R0x0R )[/quote]Oui on est d’accord avec Xbox commencant a le faire dans celle qui vient, meme si personne va l’utiliser.

Sinon, oui Ps2 roxor, mais xbox et GC roxor plus Et encore c’est parceque je joue a dance dance revolution 2 sur ps2. Jeu qui pousse, on le sait bien, la PS2 dans ses dernier retranchements

Ah ben enfin le capitaine c0unt0 (grand reporter animalier inside) se range de mon coté

Même si bon il est contaminé par la PS2 et qu’il oublie que la GC ça roxe bien aussi Bon, j’avoue que niveau délire du codeur la PS2 est plus tripante, mais hein faut penser aussi aux gens qui jouent aux jeux hein, même si nous on joue à les faire

Bref, JIT-inside pas avant quelques temps, c’est la bête loi du marché : concurrence, tout ça tout ça, faudra toujours pousser davantage les machines, donc commencer “haut niveau” puis tomber de plus en plus vers le bas niveau (ce qui veut pas dire forcément faire tout en assembleur, loin de la).

Pour en revenir à la question de départ de nicjac notre epflien javaïste, j’ai le DirectX 9.0 SDK dans lequel il y a des exemples de programmes Direct3D en C++ et C#.

Pour avoir une base de comparaison, j’ai executé la démo Dolphin VS version C++ et version C# et j’obtiens le même nombre de fps pour les deux.

Avec la démo BillBoard, j’ai un fps de 1000-1100 fps pour la version C++ et 500-600 fps pour la version C#.

Avec la démo CubeMap j’ai 550-555 fps en C++ et 530-535 en C#.

J’ai fait ces mesures avec les settings par défaut (400x300 pixels) et je les ai faites plusieurs fois.

Voilà, ce sont des mesures faites par moi et qui n’engage que moi et mon ordinateur.

[quote]Pour avoir une base de comparaison, j’ai executé la démo Dolphin VS version C++ et version C# et j’obtiens le même nombre de fps pour les deux. Avec la démo BillBoard, j’ai un fps de 1000-1100 fps pour la version C++ et 500-600 fps pour la version C#. Avec la démo CubeMap j’ai 550-555 fps en C++ et 530-535 en C#.[/quote]Ah bah en voilà des données qu’elles sont intéressantes.
Qu’est-ce qui rend BillBoard si sensible au code managé?

[quote]Ah bah en voilà des données qu’elles sont intéressantes. Qu’est-ce qui rend BillBoard si sensible au code managé?[/quote]Peut etre le fait que 1000 fps ca veut completement plus rien dire ? Faut tester sur des scenes ou on sait que le facteur limitant c’est le processing directx pour se faire une idee je pense. Au pif je dirais des scenes <100fps.
Ce message a été édité par GloP le 10/11/2003

[quote]Avec la démo BillBoard, j’ai un fps de 1000-1100 fps pour la version C++ et 500-600 fps pour la version C#.
Avec la démo CubeMap j’ai 550-555 fps en C++ et 530-535 en C#.[/quote]En fait ca veux surtout dire que la demo CubeMap se repose quasiment entierement sur le hardware et les drivers directX, donc le fait que le code soit compile a la mano ou bien compile JIT/managed n’a que tres tres tres peu d’impact sur les perfs… ce qui n’est pas le cas pour le billboard, ou le plus gros des calculs sont fait “a la mains”…

Le plus etonnant dans tout ca, c’est que l’experience (enfin surtout la miene ) prouve que ce qui coute cher en c#, c’est pas temps la qualite du code genere (qui est plutot pas mal) mais le “managed” !

voici un petit jeu développer with .NET même si ce n’est pas du C# mais du c++ managé…

http://www.vertigosoftware.com/Quake2.htm

Bon par contre c’est vrai qu’il faut installer le Framework .NET… Côté portabilité on a vu mieux