creation de jeux - Page 3

je dis que je fait un jeu, j'ai pas dis que je faisai "le jeu"

ben si, c'est plus ou moins ce que t'as dit un peu plus haut

alors si vous avez des conseils tan mieux

je t'en ai donne, mais visiblement t'en a rien a foutre

si vous voulez m'aider

te feliciter betement, ca n'est pas t'aider. le fait de poster des critiques dans ton topic, ca en revanche, si tu sais les accepter, c'est t'aider.

Sinon, oui, je reprendrai peut être le moteur pour le refaire en C#

pitie, pas en C#... en C++, a la limite en C (le C est plus simple a apprendre que le C++, mais coder un moteur evolue en C est legerement plus prise de tete et long qu'en C++)

autres raison? tout simplement parce que c'est un language on ne peux plus basic

heu.. tu parle du C#? mouarf

et que l'on peut tirer n'importe quel capacité d'un pc!

en asm, oui, en C, presque, en C++ presque, en C#, moins, en Blitz3D, encore moins...

et derniere raison, tout simplement parce que dire qu'on fait un jeu sous Blitz, on va me dire, " Ha la gueule...c'est un truc de naze, c'est pas pro etc...." bref même si le résultat était le même on aurai sans nuls doutes plus de considératons pour un jeu réalisé dans un language plus réputé...

et la t'es completement a cote de la plaque. au contraire si tu fais un jeu code en Blitz3D aussi bien qu'un bon jeu code en C++, ca force le respect... (d'avoir reussi a faire un truc bien avec ce langage de merde) et pour l'instant, je suis alle voir l'autre jour ce qui avait l'air d'etre la homepage de blitz3d, heu.. y a rien qui force le respect dans les projets utilisant blitz3d qui y sont presentes...

J'ai un pote qui disais , "Le soft ne fait rien, tout est question de bidouille" et il a raison!

même avec du C++ on sort des merdes

sans blague? depuis quand un langage code a ta place? quand a la bidouille, une fois que tu n'arrivera plus a lire et a comprendre ton propre code sans te replonger dedans pendant au moins 5 minutes et que modifier la moindre chose sera une veritable prise de tete, tu te rendra compte que la bidouille irreflechie ne mene a rien, et que la phrase de ton pote ne veut rien dire...

Maintenant, vous pouvez dire autant de chose que vous voudrez, je deserte cette section et ce forum, je ne pense pas trouver ce que je cherche ici...

tant pis pour toi.

Et si vous avez a me poser des questions allez sur mon site y a tout ce qu'il faut pour communiquer , forum, mail, etc... donc bye tous, et a la revoyure!!!

perso, j'ai aucune envie d'aller me faire chier a aller sur un forum paume pour "aider" un gars borne qui lit les posts en diagonale et qui chie sur les conseils qu'on lui donne et sur les critiques qu'on lui fait sous pretexte qu'on est des vilains nazis qui aimons pas son petit langage cheri Blitz3D

bonjour chez toi, et re-bonne chance quand meme...

Pollux> pas ridicule, non... je trouve juste que c'est pas vraiment adapte a des jeux. rien que la gestion memoire du C++ est pete couille, la ca doit etre encore pire. pour la lenteur, c'est pas grave du moment que ca touche que le code non critique point de vue perfs, mais je sais pas si tu peux mixer du C/C++ avec du C# (et de l'asm?), comme tu peux mixer du C avec du C++.

Bah... je pense pas que la vm éxécute le bytecode aussi vite que le processeur intèrprète le code. Ca doit se ressentir quand même pas mal sur la fluidité du jeu (Halo ??).

Sinon, le GC, c koi ??

sBibi
: rien que la gestion memoire du C++ est pete couille, la ca doit etre encore pire.

Comment ça? Le C# est garbage-collecté, donc c'est tout sauf pète-couilles... Par contre, je me demande si le fait qu'il soit garbage-collecté ne risque pas de ralentir les choses.

pour la lenteur, c'est pas grave du moment que ca touche que le code non critique point de vue perfs, mais je sais pas si tu peux mixer du C/C++ avec du C# (et de l'asm?), comme tu peux mixer du C avec du C++.

Ben t'as le "Managed C++" qui sert à ça : ça te permet de mélanger des objets garbage-collecté avec des non-GC A mon avis c'est assez bien foutu, même si j'ai jamais essayé (le but de .NET est de permettre une interaction très facile entre langages différents).

Bah... je pense pas que la vm éxécute le bytecode aussi vite que le processeur intèrprète le code. Ca doit se ressentir quand même pas mal sur la fluidité du jeu (Halo ??).

Tu sais, le seul overhead qu'il y a, c'est que la VM doit compiler le code avant son exécution. Dans le cas d'un jeu, il y a de toute façon un gros tps de chargement, et la taille du code en RAM est très inférieure à la taille des données, donc ça ne pose pas vraiment de pb. J'ai même fait 2-3 tests de progs bidon avec du calcul sur les entiers en C#, et c'est quasiment aussi rapide que l'équivalent en C++ Il faudrait que je teste des trucs garbage-collectés, ou des floats pour voir s'il schedule bien les instructions...

Et pour ce qui est de la comparaison avec Halo, les routines critiques peuvent tjs être en C++...

Sinon, le GC, c koi ??

Le Garbage Collector... Mais c pas forcément adapté à des gros trucs bourrins temps réel (risques de freeze de qqs centièmes de seconde, temps d'allocation de la mémoire un peu plus élevé qu'avec malloc(), la mémoire allouée n'est pas libérée immédiatement => conso de RAM légèrement plus élevée)

"Quasiment aussi rapide", sur un jeux, ça se ressent

GC: ok

"Comment ça? Le C# est garbage-collecté, donc c'est tout sauf pète-couilles... Par contre, je me demande si le fait qu'il soit garbage-collecté ne risque pas de ralentir les choses."

ben si, c'est justement ca le truc pete couilles, quand le langage s'occupe de toute la gestion memoire a ta place. dans le cas de "gros trucs bourrins temps reel", la plupart du temps, tu ne te sers meme pas de malloc, mais tu code un memory manager dans le kernel du moteur adapte specifiquement a ce que t'aura a allouer. ca sert aussi enormement pour le debug des fuites memoires en temps reel. je sais pas si tu peux faire ca en C#.. en tout cas avec VC++, en C et C++, le seul truc que je connaisse est en mode debug, le compilo te sort tous les blocs mem non free-es quand tu quitte l'app, mais dans le cadre d'un truc temps reel, c'est aussi utile qu'un profiler classique qui te sort ses stats a la fin de l'execution du prog. d'ou l'interet de coder un profiler temps reel integre au moteur, idem pour un memory manager ou tu peux suivre l'evolution des blocs alloues pendant que le truc tourne.

c'est un peu comme coder un memory manager pour la vram. la en ce moment j'utilise malloc uniquement pour allouer de gros blocs de memoire, que le mem. manager du kernel du moteur redecoupera et redispatchera comme il veut.
dans le cadre d'un truc temps reel, t'as aussi une coherence frame a frame qui peut s'averer _enormement_ utile, et un memory manager bien fait s'adapte tout seul en fonction des demandes memoire d'une frame a l'autre, ou sur plusieurs frames. c'est le genre de trucs que tu peux pas faire quand t'as toute la gestion memoire qui est faite par le langage, et que t'as pas suffisemment de controle dessus (enfin peut etre que tu peux le faire, je connais pas C# suffisemment, en fait je le connais pas du tout, j'ai juste lu 2-3 trucs dessus)

fin bref... je dis pas que le C# est mauvais, juste qu'il est pas adapte a certains types de jeux (evidemment si c'est pour faire un tetris je pense pas que ca pose pbl )

C'est vrai qu'il peut ^etre plus intéressant point de vue performances de gérer la mémoire soi-m^eme: Le système ne gère pas toujours la mémoire comme on le souhaiterait...
Je n'ai jamais essayé de programmer en C#, qu'est-ce que c'est excatement? un langage dérivé du C?

PS: Au fait, puisque vous parlez de HALO: C'est normal qu'il seccade sur mon gros PC au point de donner l'impression qu'il calcule la 3D en software?

Link>Halo à été fait en C#
Sinon C# est, en gros, le concurent de java.

link > vire les lumières dynamique ça va devenir bcp plus fluide tout d'un coup

De toute manière la conversion de Halo sur Pc a été torchée par Gearbox...

En attendant la solution de Vark marche très bien, merci à lui...

il a l'air prometteur ce jeu quand même...