Et bien interessant tout ça ^^ Effectivement les threads ne sont pas à mettre en place à la légère.
Pour faire le lien avec Irrlicht, avec Copland on s'est rendu compte que si l'on devait intégrer un moteur physique, ce dernier devrait être dans un thread du même type que celui que tu décris dans ton dernier paragraphe. (pour qu'il y ait une réelle unité de temps indépendemment de la puissance du pc sur lequel est exécuté l'appli)
Il ne faut effectivement pas hésiter à tester le même programme sur un panel de configurations afin de trouver la meilleure façon de gérer les "actions simultanées"...
Hors ligne
ah effectivement, si les fonction mettent un certain temps a retourner, ca doit etre interressant d'utiliser cette méthode pour controler la vitesse des appels tout en utilisant des threads, j'y avais pas pensé
Hors ligne
"kedu" Ecris:
Pour faire le lien avec Irrlicht, avec Copland on s'est rendu compte que si l'on devait intégrer un moteur physique, ce dernier devrait être dans un thread du même type que celui que tu décris dans ton dernier paragraphe. (pour qu'il y ait une réelle unité de temps indépendemment de la puissance du pc sur lequel est exécuté l'appli)
Hors ligne
@ Jerry kan :
En prenant ta solution de faire un grand loop qui inclut le rendu et la physique, imaginons que tu testes ton code sur un via c3 à 500Mhz avec un sli de 8800GTX (oui bon ok c'est pas possible et le cpu briderait la cg
mais c'est pour l'exemple) La physique pomperait à mort sur le cpu, on serait à 2fps alors que les cg pourraient rendre plus de 1000fps... (exemle reversible avec un Core 2 quadro et un chipset graphique
)
Si on prends la solution threads, le rendu serait fluide, la position des objets serait juste actualisée beaucoup moins souvent. Ca permet d'avoir la "même vitesse" sur des configs différentes, ce qui est d'autant plus important si il y a une partie réseau.
Pis bon, ça fait plus propre ![]()
Il y a surement d'autres avantages
Corrigez-moi si je dis des conneries ![]()
Hors ligne
oui j'ai bien compris qu'on avait tout a gagner avec des threads qui fonctionne par pas de temps, je suis completement d'accord, ce que je vois pas, c'est comment faire précisément , qui dans quel threads, avec quelles priorités, avec timer/sleep, avec du code linéraire, des threads deamon, ou seulement des fonctions lancées comme des threads etc ..
Hors ligne
en fait apres reflexion je le fairai tout simplement avec 2 threads en boucle:
un thread qui fait les graphiques en boucle autant qu'il veut
et un autre qui fait la physique et les Mesh en se lancant tous les X pas de temps
j'ai bon ?
Hors ligne
Oui je pense que lorsqu'on intègre une lib physique c'est très difficile de faire quelque chose de valable sans exécuter la physique dans un thread à part. Je te dirais bien de regarder ce que l'on a fait avec Copland dans la section tutoriaux mais bon c'est en C# et en c++ la gestion des threads pfiou c'est pas la même ^^
Hors ligne
je viens de mettre a jour mon tutoriel, il explique maintenant comment faire des threads posix portables
j'ai uploadé un zip avec un exemple et tous les fichiers requis dans le module du site :
http://irrlichtfr.free.fr/Tutoriaux/thread-portable.zip
Hors ligne
Yes merci beaucoup, cela va m'être d'une grande utilité.
je regarde ça dès que j'ai la tronche disposé ! Encore merci
Hors ligne
Pages: 1
| Options | Liens officiels | Caractéristiques | Statistiques | Communauté |
|---|---|---|---|---|
|
Préférences cookies Corrections |
![]() ![]() ![]() ![]() |
Propulsé par Django xhtml 1.0 css 2.1 |
884 membres 1440 sujets 11337 messages |
Dernier membre inscrit: Saidov17 159 invités en ligne membre en ligne: - RSS Feed |