Discussion :

[Kurisu]

Bonjour, je cherche des idées, voire tutoriels, pour créer un petit programme de test qui permet d'avoir un rendu OpenGL dans un thread séparé du reste de la logique du programme (AI ou physique ou encore musique). Je pensais utiliser boost::thread parce que quasiment standard et relativement facile à utiliser (je pourrais aussi réaliser cela avec des pthreads, mais bon...).
Je suppose bien qu'il y a de la synchronisation à faire et d'autres problèmes propres au thread, d'où cette question.

Je voudrais utiliser GLUT (FreeGLUT) au possible pour limiter la surcharge de bibliothèques de fenêtrage.

Merci d'avance pour toutes vos contributions.

[Eusebe]

Bonjour,

Tu as regardé les tutos de Miles ?
http://miles.developpez.com/tutoriels/cpp/boost/thread/

[loufoque]

GLUT, tu veux dire ce truc qui est incapable de faire du plein écran sous X ?

[Kurisu]

glutGameMode() pour le plein écran, mais le débat n'est pas là.

Eusebe>merci pour le lien, fort instructif.

Pour continuer le fil, quel serait la meilleure stratégie pour le multithreading, justement?

(PS: Je sens que je vais devoir retourner sur la théorie des systèmes concurrents...)

[Ti-R]

Je ne suis pas sur que d'afficher dans un thread séparé soit la meilleur solution, même si il n'y a logiquement aucune contre indication , mais la boucle principale doit servir à quelque chose et pourquoi séparer l'affichage qui sert de référence dans le logiciel ?

Personnellement je fais le contraire, mon thread principal permet de gérer l'affichage, tous les autres threads sont pour gérer le reste.

Sons, réseau, animation…

[Kurisu]

A en conclure que tu initialises les threads pour les sons, anims etc avant d'entrer la boucle principale et que tu te sers du callback "onIdle" ou "onDisplay" (pour rester dans la terminologie de GLUT) pour synchroniser le tout.
Je suppose que j'ai besoin d'un Mutex pour accéder et affichers mes données 3D sans provoquer un problème de mise-à-jour. Vois-je juste?