On sent un certain raz le bol et peut-être un peu de colère dans ton message - mais pourquoi ? Tous ceux qui sont partage en partie ton avis... Si on a pris un moteur comme Irrlicht, c'est qu'il n'est pas en DarkmachinTruc, il s'agit bien d'une DLL compilée à partir de C++, c'est moins rapide (peut-être, même pas certain grâce aux optimisations du compilateut) qu'un développement en Assembleur (et là, je peux parler, je m'y connais bien ayant réalisé à l'époque un moteur entièrement en assembleur optimisé pour 486 et copro)... Je ne comprend pas ce coup de gueule (ai-je mal lu, sagit-il juste d'une annonce ?).
L'appel au scripting (interprété) a d'autres objectifs que la vitesse : Simplicité de développement et de maintenance, là où on a pas besoin de vitesse. Franchement, pour faire un boucle de jeu pour afficher la scènes, à partir du moment où les fonctions en elles-mêmes sont compilées , il n'y a pas de perte de vitesse. Je ne parle pas de faire le Z-tri des objets en langage interprété !!!
Non, franchement, je comprends pas : Oui Irrlicht est un peu lent, et quoi que - faut bien choisir ses objets, ses textures et surtout un sceneNode qui utiliserait peut-êytre les sharders pour certains calculs comme le travail de SIO2. Irrlicht est une base de travail, adpaté aux débutants qui n'optimiseront pas, et aux autres qui veulent fouiner dans le coeur du système - c'est possible, puisqu'Open Source. Oui, c'est mal documenté, mais c'est un avis perso. Mais bon, en cherhant,, on trouve ou on relit le code.
Bon, je suppose que les messages précédents t-on donné une petite poussée de boutons ... Et peut-être as-tu eu raison de recadrer certaines choses, moi je voulais dire tout de même que le scripting est intéressant, que .NET qui est entre le langage compilé et interprété (à mi chemin) a aussi ses avantages et qu'il n'est pas si lent qu'on le dit, et que l'assembleur, c'est super ... mais ça fonctionne plus d'un proc à un autre quand on optimise, et on passe un temps monstrueux à développer un petit prog et à trouver un bug.

On sent un certain raz le bol et peut-être un peu de colère dans ton message - mais pourquoi ? Tous ceux qui sont partage en partie ton avis... Si on a pris un moteur comme Irrlicht, c'est qu'il n'est pas en DarkmachinTruc, il s'agit bien d'une DLL compilée à partir de C++, c'est moins rapide (peut-être, même pas certain grâce aux optimisations du compilateut) qu'un développement en Assembleur (et là, je peux parler, je m'y connais bien ayant réalisé à l'époque un moteur entièrement en assembleur optimisé pour 486 et copro)... Je ne comprend pas ce coup de gueule (ai-je mal lu, sagit-il juste d'une annonce ?).
L'appel au scripting (interprété) a d'autres objectifs que la vitesse : Simplicité de développement et de maintenance, là où on a pas besoin de vitesse. Franchement, pour faire un boucle de jeu pour afficher la scènes, à partir du moment où les fonctions en elles-mêmes sont compilées , il n'y a pas de perte de vitesse. Je ne parle pas de faire le Z-tri des objets en langage interprété !!!
Non, franchement, je comprends pas : Oui Irrlicht est un peu lent, et quoi que - faut bien choisir ses objets, ses textures et surtout un sceneNode qui utiliserait peut-êytre les sharders pour certains calculs comme le travail de SIO2. Irrlicht est une base de travail, adpaté aux débutants qui n'optimiseront pas, et aux autres qui veulent fouiner dans le coeur du système - c'est possible, puisqu'Open Source. Oui, c'est mal documenté, mais c'est un avis perso. Mais bon, en cherhant,, on trouve ou on relit le code.
Bon, je suppose que les messages précédents t-on donné une petite poussée de boutons ... Et peut-être as-tu eu raison de recadrer certaines choses, moi je voulais dire tout de même que le scripting est intéressant, que .NET qui est entre le langage compilé et interprété (à mi chemin) a aussi ses avantages et qu'il n'est pas si lent qu'on le dit, et que l'assembleur, c'est super ... mais ça fonctionne plus d'un proc à un autre quand on optimise, et on passe un temps monstrueux à développer un petit prog et à trouver un bug.