Reprise du message précédent :
goldorak go ! rétro laser ! astero hache  transfer !

Chuis OK aussi pour ces principes
Au sujet de l'interface, je verrais bien une interface style First Encounters (que j'appelle Elite 2'), dans laquelle les boutons sont intégrés au tableau de bord, façon Captain Blood. ça rend mieux que les immondes interfaces des autres Elite(s), et ça me semble plus ergonomique.
 
En ce qui concerne les langages de script, j'ai testé Squirrel. Mon avis est le suivant : je pense effectivement qu'il pourrait accélerer le développement, mais au prix d'une perte de performances assez flagrante. Pour info, j'ai réalisé le test suivant : un calcul de Mandelbrot en 5000 itérations en C. L'affichage était géré par la SDL, et le calcul dans un thread géré par Squirrel. Le résultat fut assez flagrant :
Version "full C" => ~4000 ms pour tracer l'ensemble
Version Squirrel => ~10000 ms
Version SIMD (partie calcul réalisée en assembleur, avec MMX) => ~1500 ms
Version SIMD (calcul réalisé en assembleur, avec SSE) => 900 ms
 
les resultats sont là
 
 
edit: j'ai eu le 1000è post \o/

Moi j'aurais pas osé mettre un calcul de Mandelbrot en script Ce n'est pas à ça que je pensais utilisé les scripts mais plustot a des trucs du genre :
- Placer les boutons de l'interface et definir les evenements
- Ecrire les règles du jeu. Un bon exemple serait pour coder l'EMP :

+1 c'est pas trop l'utilisation qu'on veut en faire
 
par rapport à la tâche exécutée, je trouve qu'il s'en sort pas trop mal
 
Bon, puisque j'ai l'accord des deux co-fondateurs du topic, je poursuis mes analyses ce soir

 
Un ralentissement d'un facteur 2,5 seulement par rapport au C, et non de 10 ou 20 comme on pouvait s'y attendre.  Je ne sais pas ce que vous en pensez, mais je trouve que ce simple résultat parle très nettement en faveur du langage de script (sachant que d'après mes propres tests, Lua me semble plus rapide que Squirrel, mais bcp moins expressif).  
En défaveur de Squirrel : le quicksort est buggé (je l'ai signalé à l'auteur), et il ne gère pas la notation scientifique (aussi signalé). Je pense que ces deux pb sont facilement corrigeables nous-mêmes en attendant la prochaine version. Le pb principal étant qu'à part l'auteur lui-même, il n'y a guère de support.
Je suis tout à fait de l'avis de Kristoph sur l'utilisation du script. Il n'est pas question de faire les opérations coûteuses en script, seulement le "bookkeeping".
 
Harko, ça ne t'ennuierait pas de poster tes codes, histoire qu'on voit à quoi ça ressemble ?

moi ce que je vois c'est qu'en un truc tout pourri et un cerveau y'a un facteur 100

Pas 100, 10 seulement entre le langage de haut niveau et l'asm optimisé pour SSE. Je suis franchement étonné par ce résultat.

wow encore un "vivant" ...
Toujours pas d'évolution en ce qui concerne ta compilation d'ogre sous nunux ?

Non, mais je m'y remets. Je te préviendrai par mp dès que c'est fait.

ok ok ..  
au fait, j'ai trouvé encore un autre engine ... mais ils sont chiant pour le d/l ( register et tout le bazard )
enfin bon juste pour voir : http://www.v3x.net/v3x/v3x_3d_engine.html
 
Il y a quand même qques petits tools utiles ( notament le OpenGL Extensions Viewer )
 
Mais bon niveau moteur, c'est quand même Ogre qui a mes faveurs pour le moment ...

 
Euh, oui, 5000 euros la licence...    
Ogre3d est clairement le meilleur moteur open source, avec Nebula.
Il est compatible avec les shading languages Cg, HLSL et depuis peu avec GLSL (dans la version CVS seulement), ce dont, je pense, peu de moteurs commerciaux sont capables.
 
Bon, finalement, j'ai tout compilé.
 
Pour info, voici tous les packages que utilisés :
 
DevIL-1.6.5.tar.gz
freetype-2.1.7.tar.gz (sur SourceForge) ou +
Cg-1.2.1-Linux.tar.gz : qu'on trouve sur le site de Nvidia (attention, la v1.3 n'est pas supportée par Ogre, et il faut détarer dans /)
libSDL 1.2.7 ou +
boost 1.31
NVIDIA-Linux-x86-1.0-6111-pkg1.run
Mesa 6.1 ou +
 
Bizarrement, nvidia a choisi de placer ses en-têtes dans /usr/share/doc/NVIDIA_GLX-1.0/include/GL. J'ai créé un lien dans /usr/X11R6/include/GL au cas où.
Il faut les en-têtes d'OpenGL de chez SGI fournies avec la librairie Mesa 6.1 ou 6.2, car les drivers de nvidia ne sont pas fournis avec (il manque notamment glu.h).
 
Enfin, Ogre3d semble rechercher le répertoire /usr/lib/python2.2 lors de la compilation (si on met l'otion Python). Si vous avez Python 2.3, un lien symbolique /usr/lib/python2.2 -> /usr/lib/python2.3 fait l'affaire ou ajouter l'option --with-python-version=2.3.
 
Dans le répertoire ogrenew, comme d'hab,
./configure -help  
liste les options de compilation. Les options par défaut marchent bien.
 
Donc:
./configure --with-cfgtk=cli --with-python-version=2.3 --with-platform=SDL
make
make install
 
Prévoir environ 30 minutes (Athlon 1,5 GHz) et ~840 Mo d'espace libre pour la génération et l'installation des libs d'Ogre (plus le temps et l'espace nécessaire pour installer les autres packages, l'Ogre est gourmand ).

 
heuuuuuu ben il y a une version gratuite ...

 
.. je me suis enregistré mais j'attends toujours une réponse !!!
 
Je vais laisser tomber ça ...
 
 
Bon boulot pour l'Ogre nunux ... ça va honnêtement me faire gagner un sacré bout de temps !

tu comptes le tester sur ta nouvelle station O2?

 
clair si je trouve le moyen de le recompiler sur Irix ...

J'ai updaté mon draft d'analyse (liens en second post) et j'ai ajouté un gros point 2. "Analyse fonctionnelle" où j'ai commencé à détailler les features que le jeu devrait intégré. Tout ça est sujet à discussion bien entendu.
 
Je propose donc qu'on passe en phase 2: choix des features
De plus, il faudra également définir ce qu'on veut en priorité, et ce qu'on garde au chaud pour plus tard. Je n'ai pas encore mis de priorités sur le draft mais ça viendra

(jviens juste de me dire que si ogre gere les collisions a l'aide de bounding box, zallez pas avoir l'air fin )

Bof, il suffit de faire des planètes carrées et voilà

 
lol
 
pour les combats ca serait embêtant aussi
 
Faut voir comment ogre implemente opcode via ode, mais opcode fait les per-poly detections donc...

Opcode gère les collisions trimesh-trimesh, mais Ode ne le fait pas (encore). Ce qui risque de poser problème pour la collision entre 2 vaisseaux si vous approximez ces 2 vaisseaux par leur OBBs.

et encore, de vaisseaux a vaisseaux ca peut aller (au pire une hierarchie de OBB), mais avec une planete...

Il n'y a aucun problème pour gérer une collision vaisseau/planète car il s'agit d'un test OBB vs trimesh, qui est supporté aussi bien par Opcode que par ODE.
 
Vaisseau vs vaisseau, cela dépend du type de vaisseau. Evidemment si on parle de fighters de quelques dizaines de mètres, ça va, mais pour des vaisseaux géants avec des formes non-conventionnelles... arg.

Oui mais le modèle de la planète n'est pas fixe. Il dépend du LOD car il est pratiquement impossible de dessiner une planète entière avec 1 seul niveau de LOD. Et si on prend donc le niveau de LOD qui permet de représenter la surface, on se retrouve avec des modèles gigantesques.
 
Au fait, les float n'ont pas assez de precision pour placer un objet à la surface de la terre avec une precision convenable.

LOD ou pas, cela reste du tri-mesh.
 
Quand a la precision des floats, c'est ce que je dis depuis le début

m'amuserais pas a faire de la detection de collision avec une precision au triangle sur un engin de la taille d'une planete sans au moins passer par des systemes hierarchiques

la planète est un cas particulier.
 
généralement un test de collision c'est tester contre une heightmap.

Page 5, alors ça y est c'est mort ?

phase 2 \o/

page 5?

Le topic était en page 5 avant que je le up

Aaaaaah ok. J'uppe jamais les topics (à part blabla@prog), va-t-il falloir que j'en prenne l'habitude? (ça polluerait pour rien )

sinon tu fais comme moi avec mon topic sur l'IA... tu le laisses s'embourber dans les noires profondeurs du forome...

le laisser s'embourber, c'est pas vraiment ça mon idée
(pis bon ya déjà plein de gens qui ont un drapeau dessus donc c'est pas comme s'il était perdu)

En fait, ce topic est le seul endroit où l'on peu obtenir des infos sur ce qu'il se passe. Alors quand je le vois tomber en page 5, je suppose donc qu'il ne se passe plus rien

Plus rien de visible, mais ce projet occupe très fréquemment mes pensées
 
Je rappelle que j'ai dit que j'étais intéressé par des propositions de features vu que nous sommes maintenant en phase 2
 
Mais personne n'en a ou tout le monde s'en fout

t'as suffisament de feature listée sur ce topic pour rendre ce projet infaisable, de quoi tu te plains ?

je trouvais ça frugal
 
qu'est-ce qui pourrait bien rendre ce projet infaisable, dis-moi?

la liste de feature gigantesque balancée au petit bonheur sans que personne ait commencé a reflechir a comment l'implanter et l'equipe actuellement inexistance (pour commencer)

Je sais pas si t'as remarqué mais il y a une équipe, justement (on voit les gens qui lisent la doc)
Et je ne trouve pas que la liste de features soit gigantesque
 
Quant à l'implémentation, ce n'est pas encore le moment de s'en préoccuper.

Faudrait essayer de faire un Wiki pour organiser les discussions sur le sujet.
 
Si vous voulez, j'ai quelques idées assez avancées pour gérer les vaisseaux, leur cargo, leur equipement et aussi la notion de contrebande.

La question ne se pose pas: on en veut
 
Tu peux tout coucher ici de toute façon, je lis tout attentivement pour la rédaction de mon document
 
edit: pour le Wiki, je sais pas si ça convient à une discussion. Un forum à part serait sûrement plus adéquat.

 
bon jveux bien, mais c'est bien beau de dire j'veux ca, ca et ca pour au final se trouver avec la moitié de ci paske personne a une idée de comment ca ca et ca peuvent etre fait.  
 
(sinon l'equipe, bon, les projets qui partent en vrille a cause d'equipe qui se dissout ca s'est deja vu plus d'une fois, alors bon)