IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Développement 2D, 3D et Jeux Discussion :

Besoin d'explications et de conseils sur les threads


Sujet :

Développement 2D, 3D et Jeux

  1. #1
    Membre du Club Avatar de matteli
    Profil pro
    Inscrit en
    Décembre 2006
    Messages
    85
    Détails du profil
    Informations personnelles :
    Âge : 47
    Localisation : France

    Informations forums :
    Inscription : Décembre 2006
    Messages : 85
    Points : 57
    Points
    57
    Par défaut Besoin d'explications et de conseils sur les threads
    Salut,

    Je programme actuellement un jeu (du type Europa Universalis, pour ceux qui connaisse). J'ai besoin de séparer 2 parties de programme.

    Une partie (A) contient : la gestion des events clavier et souris et le rendu. Cette partie est cadencée à 25 i/s et est prioritaire sur B

    Une autre (B)contient le reste : IA, évolution des paramètres du jeu ... Cette partie évolue avec l'échelle du temps du jeu. Ca veut dire qu'elle peut ralentir si les calculs le nécessite.

    La partie B peut être interrompue pour laisser la partie A se réaliser et se finir après.

    J'utilise SDL, opengl, GLUT comme librairies.

    J'ai vu la notion de thread dans la SDL. J'imagine que c'est ça qui va résoudre mon problème.

    D'où ma question : Est ce que tout peut être résolu avec les threads ? (séparation des programmes, priorité d'un thread sur l'autre, interruption d'un thread puis reprise...)

    De façon générale, si vous connaissez des tutos ou des sources qui traitent de mon problème?

    Merci


    PS : J'imagine que le sujet a déjà été traité et j'ai fait quelques recherches mais rien de bien concluant.

  2. #2
    Expert éminent sénior

    Avatar de fearyourself
    Homme Profil pro
    Ingénieur Informaticien Senior
    Inscrit en
    Décembre 2005
    Messages
    5 121
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : Ingénieur Informaticien Senior
    Secteur : Industrie

    Informations forums :
    Inscription : Décembre 2005
    Messages : 5 121
    Points : 11 877
    Points
    11 877
    Par défaut
    Bonjour,

    Comme souvent, on conseille aux gens de ne pas mettre des threads en place avant que cela soit vraiment nécessaire. Il est possible que ton programme puisse tourner sans en avoir recours.

    Ensuite, je ne comprends pas vraiment comment tu peux utiliser SDL et Glut... Qui fait quoi dans ce contexte ?

    Dernier point, je ne pense pas que les threads te permettront de définir exactement ton système comme cela. La seule chose que tu peux vraiment faire c'est te débrouiller pour que ton code (B) sache s'arrêter rapidement et se reprendre.

    Par contre, si tu lances les deux threads sans t'occuper de ces détails, il est possible que tu aurais un bon résultats.

    Ma conclusion serait : écrit le programme sans thread mais en préparant pour leur présence si nécessaire. Ensuite, tu peux les ajouter et voir s'il faudra, par la suite, faire des réglages pour obtenir ce que tu cherches.

    Jc

  3. #3
    Membre du Club Avatar de matteli
    Profil pro
    Inscrit en
    Décembre 2006
    Messages
    85
    Détails du profil
    Informations personnelles :
    Âge : 47
    Localisation : France

    Informations forums :
    Inscription : Décembre 2006
    Messages : 85
    Points : 57
    Points
    57
    Par défaut
    J'utilise GLUT pour l'affichage de caractères.
    Je trouve SDL_ttf pas adapté pour la SDL associé à opengl. J'ai utilisé ton code (CTexte) mais pour faire du temps réel, je trouve que ça ralentit.

    En tout cas merci pour ta réponse.

    Je ne pense pas que mon code sans thread puisse passer. Le code de la partie B peut être assez long.

    Mais je vais suivre ton conseil et commencer sans.

    Au fait, je me suis trompé de sous-forum, je voulais mettre ça dans le sous-forum SDL.

    Je viens de me rendre compte que c'est toi qui a fait les tutos pong et morpion.

    Il m'ont beaucoup servi et me serve toujours.

    bon apparemment le timer de la SDL me permettra de faire ça.

  4. #4
    Expert confirmé

    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2007
    Messages
    1 895
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Septembre 2007
    Messages : 1 895
    Points : 4 551
    Points
    4 551
    Par défaut
    Citation Envoyé par fearyourself Voir le message
    Bonjour,

    Comme souvent, on conseille aux gens de ne pas mettre des threads en place avant que cela soit vraiment nécessaire. Il est possible que ton programme puisse tourner sans en avoir recours.
    Tournons nous vers l'avenir ! Comme l'a dit Herb Sutter, "the free lunch is over" - il est grand temps d'entrer dans l'ère de la gestion concurrentielle des données. D'autant que pour le coup, cela simplifie énormément l'architecture de l'application.

    Une application tel que présentée par matteli (basé sur 2 threads dont l'une gère controler+view et l'autre le modèle de l'application) est une bonne idée. En fait, il s'agit d'un modèle de plus en plus utilisé dans le cadre du développement de jeux vidéo.

    La première thread effectue la capture des entrées utilisateur et les stocke dans une zone prévue a cet effet (après traitement si besoin est (par exemple, pour transformer une combinaison de touches en un flag "combo")). Une fois cette tâche effectuée, elle effectue le rendu du dernier état connu du modèle de l'application.

    Pendant ce temps, la deuxième thread récupère les dernières entrées utilisateur et modifie le modèle en conséquence. Une fois modifié, le modèle est stocké de manière à ce que la thread de rendu puisse le lire sans perturber les calculs subséquents.

    On a besoin de 2 points de synchronisation (2 mutex) :
    1) lecture (thread 2) et écriture (thread 1) des entrées utilisateur capturée
    2) lecture (thread 1) et écriture (thread 2) du modèle de l'application mis à jour et prêt pour le rendu.

    A noter que ce découpage impose une architecture logicielle particulière et (selon moi) plus à même de résister au temps qui passe qu'une architecture basée sur l'idée que le programme est mono-thread.

    Citation Envoyé par fearyourself Voir le message
    Ma conclusion serait : écrit le programme sans thread mais en préparant pour leur présence si nécessaire. Ensuite, tu peux les ajouter et voir s'il faudra, par la suite, faire des réglages pour obtenir ce que tu cherches.
    Jc
    Pour le coup, ça veut dire que la thread B est transformée en un automate (puisqu'il faut pouvoir reprendre à certaines tâches particulières). On ne gagne pas grand chose à garder un modèle monothread.
    [FAQ des forums][FAQ Développement 2D, 3D et Jeux][Si vous ne savez pas ou vous en êtes...]
    Essayez d'écrire clairement (c'est à dire avec des mots français complets). SMS est votre ennemi.
    Evitez les arguments inutiles - DirectMachin vs. OpenTruc ou G++ vs. Café. C'est dépassé tout ça.
    Et si vous êtes sages, vous aurez peut être vous aussi la chance de passer à la télé. Ou pas.

    Ce site contient un forum d'entraide gratuit. Il ne s'use que si l'on ne s'en sert pas.

  5. #5
    Expert éminent sénior

    Avatar de fearyourself
    Homme Profil pro
    Ingénieur Informaticien Senior
    Inscrit en
    Décembre 2005
    Messages
    5 121
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : Ingénieur Informaticien Senior
    Secteur : Industrie

    Informations forums :
    Inscription : Décembre 2005
    Messages : 5 121
    Points : 11 877
    Points
    11 877
    Par défaut
    Citation Envoyé par Emmanuel Deloget Voir le message
    Pour le coup, ça veut dire que la thread B est transformée en un automate (puisqu'il faut pouvoir reprendre à certaines tâches particulières). On ne gagne pas grand chose à garder un modèle monothread.
    Si... la simplicité.

    Le problème souvent rencontré est de perdre du temps sur des détails d'implémentation au début. Lorsqu'on commence un projet, ce n'est pas forcément bon de s'attaquer directement au problème des threads.

    Après, c'est une question de qualité du programmeur et ce qu'il/elle sait faire. Dans le meilleur des mondes, je dirais : oui on fait des threads et en plus on se débrouille pour que chaque thread tourne sur un des coeurs du super dual/quad core...

    Jc

  6. #6
    Expert confirmé

    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2007
    Messages
    1 895
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Septembre 2007
    Messages : 1 895
    Points : 4 551
    Points
    4 551
    Par défaut
    Citation Envoyé par fearyourself Voir le message
    Si... la simplicité.

    Le problème souvent rencontré est de perdre du temps sur des détails d'implémentation au début. Lorsqu'on commence un projet, ce n'est pas forcément bon de s'attaquer directement au problème des threads.
    Je concède ce point.

    Citation Envoyé par fearyourself Voir le message
    Après, c'est une question de qualité du programmeur et ce qu'il/elle sait faire. Dans le meilleur des mondes, je dirais : oui on fait des threads et en plus on se débrouille pour que chaque thread tourne sur un des coeurs du super dual/quad core...

    Jc
    Choisir l'affinity des thread soit même, c'est aussi empêcher l'OS de le faire - et donc modifier le comportement des autres programmes. Dans un système ou un seul process tourne à un moment donné, cela peut valoir le coup. Dans le cas ou plusieurs process tournent, dont un certain nombre en tâche de fond (comme sur Windows, Mac OS X ou Linux), on risque de diminuer les performances du système.

    Dans leur présentation "Practical multi-threading for game performance" à la GCDC, Leigh Davis (Intel) et Doug Binks (CryTek) ont tous les deux insisté sur ce point : il peut être utile d'assigner une thread a un coeur, mais cela doit être fait d'une part dans le respect des opérations de l'OS et d'autre part avec une délicatesse infinie (lire: il faut faire très attention, et le faire uniquement si c'est vraiment utile; donc mesurer, comparer, etc).

    (PS: cf cet article sur mon blog (extrait d'un article publié sur Gamedev.net)).
    [FAQ des forums][FAQ Développement 2D, 3D et Jeux][Si vous ne savez pas ou vous en êtes...]
    Essayez d'écrire clairement (c'est à dire avec des mots français complets). SMS est votre ennemi.
    Evitez les arguments inutiles - DirectMachin vs. OpenTruc ou G++ vs. Café. C'est dépassé tout ça.
    Et si vous êtes sages, vous aurez peut être vous aussi la chance de passer à la télé. Ou pas.

    Ce site contient un forum d'entraide gratuit. Il ne s'use que si l'on ne s'en sert pas.

  7. #7
    Expert éminent sénior

    Avatar de fearyourself
    Homme Profil pro
    Ingénieur Informaticien Senior
    Inscrit en
    Décembre 2005
    Messages
    5 121
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : Ingénieur Informaticien Senior
    Secteur : Industrie

    Informations forums :
    Inscription : Décembre 2005
    Messages : 5 121
    Points : 11 877
    Points
    11 877
    Par défaut
    Citation Envoyé par Emmanuel Deloget Voir le message
    Choisir l'affinity des thread soit même, c'est aussi empêcher l'OS de le faire - et donc modifier le comportement des autres programmes. Dans un système ou un seul process tourne à un moment donné, cela peut valoir le coup. Dans le cas ou plusieurs process tournent, dont un certain nombre en tâche de fond (comme sur Windows, Mac OS X ou Linux), on risque de diminuer les performances du système.
    Attention, nous partons dans un troll et ce n'est pas le rôle de ce fil. Je pense qu'on est tous les deux d'accord sur le mérite des threads lorsque c'est maîtrisé. Que cela soit avec l'aide de l'OS ou non pour l'affectation aux coeurs du processeur. Par contre, pour un débutant, cela est rarement le cas puisqu'il se bat avec d'autres concepts en même temps.

    C'est pour cela et seulement cela, qu'on déconseille les threads au début.
    Jc

  8. #8
    Membre du Club Avatar de matteli
    Profil pro
    Inscrit en
    Décembre 2006
    Messages
    85
    Détails du profil
    Informations personnelles :
    Âge : 47
    Localisation : France

    Informations forums :
    Inscription : Décembre 2006
    Messages : 85
    Points : 57
    Points
    57
    Par défaut
    Il semblerait que de mettre la gestion des évènements dans un autre thread que la boucle main ne marche pas.

    Du coup, j'ai implanté la gestion des évènements et le rendu dans le main et j'ai crée un thread pour le reste.

    On verra bien.

  9. #9
    Nouveau membre du Club
    Inscrit en
    Mars 2007
    Messages
    29
    Détails du profil
    Informations forums :
    Inscription : Mars 2007
    Messages : 29
    Points : 29
    Points
    29
    Par défaut
    L'utilité principale des threads en programmation (et la raison pour laquelle ils ont été inventé justement) C'est pour éviter d'avoir une application qui se gèle pendant un traitement bloquant.

    Ça n'a pas été inventé pour accélérer un jeu au départ. Aujourd'hui en tend à faire des threads pour obtenir plus de vitesse et on s'égare.

    Mettre la gestion des événements dans un autre thread que la boucle principale d'un jeu me semble très casse gueule.

    Voici les choses qui me semblent plus appropriés pour un thread :
    - Charger les éléments de la prochaine map en arrière plan
    - Effectuer le traitement de l'IA pour les prochains frames pendant le rendu des frames précédents
    - Gérer l'arrivée des messages dans un jeu multi-joueur
    - Faire une sauvegarde automatique à un checkpoint sans que le jeu ne lag

    Donc, si on veut faire des threads, s'assurer qu'on les fait pour quelque chose d'utile et non pas "threader" pour le plaisir de "threader".

    Enfin, ça reste mon opinion

  10. #10
    Membre expérimenté

    Profil pro
    Programmeur
    Inscrit en
    Août 2002
    Messages
    1 091
    Détails du profil
    Informations personnelles :
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : Programmeur

    Informations forums :
    Inscription : Août 2002
    Messages : 1 091
    Points : 1 679
    Points
    1 679
    Par défaut
    Citation Envoyé par matteli Voir le message
    Il semblerait que de mettre la gestion des évènements dans un autre thread que la boucle main ne marche pas.
    Si si cela marche, mais il faut comprendre que le main thread (le thread qui est automatiquement lancé lors du démarrage de l'appli et qui fait quitter l'application si il sort de la fonction main) n'est pas forcément celle qui gère les evenements que reçoit le thread qui a créé la fenètre (qui là par contre doit être le même).

    LeGreg

    Mon site web | Mon blog | Mes photos | Groupe USA
    > BONJOUR, JE SUIS NOUVEAU SUR CE FORUM
    > presse la touche caps lock, stp
    > OH.. MERCI C EST BEAUCOUP PLUS FACILE COMME CA

  11. #11
    Membre expérimenté

    Profil pro
    Programmeur
    Inscrit en
    Août 2002
    Messages
    1 091
    Détails du profil
    Informations personnelles :
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : Programmeur

    Informations forums :
    Inscription : Août 2002
    Messages : 1 091
    Points : 1 679
    Points
    1 679
    Par défaut
    Citation Envoyé par vanacid Voir le message
    Ça n'a pas été inventé pour accélérer un jeu au départ. Aujourd'hui en tend à faire des threads pour obtenir plus de vitesse et on s'égare.
    Je crois que tu as raté le coche des CPU multicores, et du Cell.
    Aujourd'hui une grande partie des PCs vendus ont plusieurs cores (2, voire quatre, bientot 8, j'ai même vu un PC faisant tourner Windows avec 32 cores AMD). Donc pour exploiter leur puissance à 100% il n'y a pas d'autres solutions que de faire tourner ton application dans plusieurs threads.
    Ceci dit le chemin de la parallalélisation (efficace !) est long et ardu pour beaucoup de gens (même pour les pros).

    LeGreg

    Mon site web | Mon blog | Mes photos | Groupe USA
    > BONJOUR, JE SUIS NOUVEAU SUR CE FORUM
    > presse la touche caps lock, stp
    > OH.. MERCI C EST BEAUCOUP PLUS FACILE COMME CA

  12. #12
    Nouveau membre du Club
    Inscrit en
    Mars 2007
    Messages
    29
    Détails du profil
    Informations forums :
    Inscription : Mars 2007
    Messages : 29
    Points : 29
    Points
    29
    Par défaut
    Citation Envoyé par LeGreg Voir le message
    Je crois que tu as raté le coche des CPU multicores, et du Cell.
    Non, j'ai vu le train passer...
    J'ai un dual-core sur ma machine. La principale raison pour laquelle j'aime le dual-core c'est pour augmenter la réactivité du système quand plein d'applications roulent en même temps.
    Lancer une compilation pendant qu'on écoute de la musique et qu'on chat sur MSN par exemple.

    Citation Envoyé par LeGreg Voir le message
    Donc pour exploiter leur puissance à 100% il n'y a pas d'autres solutions que de faire tourner ton application dans plusieurs threads.
    C'est sur que vu comme ça c'est vrai, par contre, je ne vois pas comment on peut surcharger des processeurs aussi puissant que ceux d'aujourd'hui.

    On a déjà assez de puissance en utilisant un minimum de thread :

    - Un thread qui gère le jeu en tant que tel
    - Un autre qui s'occupe du chargement en arrière-plan pour éviter les fameux "Loading" (Half-Life 2 est particulièrement irritant sur ce point).
    - Si possible, un thread qui s'occupe de l'IA.

    Citation Envoyé par LeGreg Voir le message
    Ceci dit le chemin de la parallalélisation (efficace !) est long et ardu pour beaucoup de gens (même pour les pros).
    C'est qu'on essaie de paralléliser des trucs qui se parallélisent mal. J'ai de la difficulté à comprendre pourquoi.

    Je ne crois pas que monopoliser tous les cores quand on fait un jeu fasse en sorte que le jeu soit meilleur. On doit penser à paralléliser lorsqu'on sait qu'on va manquer de puissance CPU. Ce qui est loin d'être le cas pour la majorité des jeux. C'est la carte graphique qui manque de puissance avant le processeur la majorité du temps.

    Enfin, si on veut se casser la tête à penser comment paralléliser des choses simples au lieu de passer son énergie à affiner le gameplay et améliorer l'algorithme de base, c'est le choix de chacun.

    Selon moi, avec des délais de 7 mois à 2 ans, je ne pense pas que tout le monde ait le temps de se couper les cheveux en quatre. On veut un bon jeu, point.

  13. #13
    Membre du Club Avatar de matteli
    Profil pro
    Inscrit en
    Décembre 2006
    Messages
    85
    Détails du profil
    Informations personnelles :
    Âge : 47
    Localisation : France

    Informations forums :
    Inscription : Décembre 2006
    Messages : 85
    Points : 57
    Points
    57
    Par défaut
    Je ne tiens pas à multiplier les threads (ce sera 2 maxi).

    Je fais des tests pour voir comment la priorité des threads est gérés.
    Quand je lance 2 thread (hors main thread), il tourne à la même vitesse (logique).

    Par contre si je lance un thread et le main thread, j'obtiens une différence de 10% en terme de performance au profit du thread.

    Voilà le code que j'utilise :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
     
    #include <iostream>
    #include <SDL/SDL.h>
    #include <SDL/SDL_thread.h>
    long i;
    long j;
    long k=100000000;
    long m;
    SDL_mutex* myMutex;
    int last;
     
    int bthread (void* data)
    {
        //SDL_mutexP(myMutex);
        while (SDL_GetTicks()-last<1000)
        {
            ++i;
        }
        return (0);
        //SDL_mutexV(myMutex);
     
    }
    int bthread2 (void* data)
    {
        //SDL_mutexP(myMutex);
        m=i;
        while (SDL_GetTicks()-last<1000)
        {
            ++j;
        }
        return (0);
        //SDL_mutexV(myMutex);
     
    }
    int main ( int argc, char** argv )
    {
        myMutex = SDL_CreateMutex();
        atexit(SDL_Quit);
        SDL_Thread *thread= NULL;
        SDL_Thread *thread2= NULL;
        last=SDL_GetTicks();
        thread = SDL_CreateThread( bthread, NULL );
        //thread2 = SDL_CreateThread(bthread2, NULL );
     
        //SDL_WaitThread(thread2, NULL);
        //SDL_WaitThread(thread, NULL);
     
        //SDL_mutexP(myMutex);
     
        m=i;
        while (SDL_GetTicks()-last<1000)
        {
            ++j;
        }
        //SDL_mutexV(myMutex);
     
        std::cout<<"thread : "<<i<<std::endl;
        std::cout<<"boucle : "<<j<<"-"<<m<<"="<<j-m<<std::endl;
        return 0;
    }
    Vous avez des explications à ça ?

Discussions similaires

  1. Conseil sur les thread dans une dll
    Par ksoft dans le forum C
    Réponses: 2
    Dernier message: 30/03/2009, 16h12
  2. besoin de conseils sur les ouvertures de connexion
    Par maxidoove dans le forum JDBC
    Réponses: 1
    Dernier message: 11/06/2008, 14h09
  3. Réponses: 2
    Dernier message: 15/01/2008, 08h35
  4. besoin de conseil sur les procédures stockées et vues.
    Par zenfantasy dans le forum MS SQL Server
    Réponses: 2
    Dernier message: 28/11/2007, 22h41
  5. Besoin de conseil sur les classes
    Par SuperWeight dans le forum MFC
    Réponses: 1
    Dernier message: 04/06/2007, 22h44

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo