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

AWT/Swing Java Discussion :

Baisser progressivement la largeur d'un JLabel


Sujet :

AWT/Swing Java

  1. #1
    Nouveau Candidat au Club
    Homme Profil pro
    Développeur Java
    Inscrit en
    Octobre 2019
    Messages
    5
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : Octobre 2019
    Messages : 5
    Points : 1
    Points
    1
    Par défaut Baisser progressivement la largeur d'un JLabel
    Bonjour à tous,

    Je développe actuellement un petit jeu avec un système de barre de vie. J'arrive bien à changer l'affichage de ma barre de vie en fonction des coups pris par le joueur en jouant sur la largeur du rectangle représentant la barre, toutefois le changement est brutal alors que je voudrais qu'il soit progressif (en gros que la largeur de la barre descende ou augmente progressivement vers la bonne valeur).

    Voici ma classe "HpBar", très basique, actuelle :
    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
    import java.awt.*;
    import javax.swing.*;
     
    public class HpBar extends JLabel
    {
    	Color c= Color.green;
    	private static final long serialVersionUID = 1L;
    	public void paint(Graphics g) 
    	{
            super.paint(g);
            g.setColor(c);
            g.fillRect(0, 0, (int) 100, (int) 20);
        }
     
    	public void changeColor(Color c)
    	{
    		this.c = c;
    	}
    }
    Voici le bout de code qui correspond à la gestion de la largeur de la barre :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    if (playerBar == null)
    	this.playerBar = new HpBar();
    float hpLeft = ((float) p.getCurrentHp()/p.getBaseHp()) * 100;
    this.hpCounter.setText("HP : "+p.getCurrentHp()+"/"+p.getBaseHp());
    if (hpLeft <= 20)
    	this.playerBar.changeColor(Color.red);
    else if (hpLeft <= 50)
    	this.playerBar.changeColor(Color.orange);
    this.playerBar.setBounds(535,530,(int)hpLeft,25);
    this.add(playerBar);
    (Autres traitements pour un affichage complémentaire)
    this.repaint();
    J'ai essayé de bricoler un truc avec un while et une valeur qui se décrémente, mais je n'arrive pas à obtenir cette augmentation ou dégression progressive (et fluide si possible) de la barre... Une idée ?

    PS : désolé, c'est probablement basique mais je suis une vraie quiche dès qu'il s'agit de faire de l'affichage...

    Merci d'avance

  2. #2
    Modérateur
    Avatar de joel.drigo
    Homme Profil pro
    Ingénieur R&D - Développeur Java
    Inscrit en
    Septembre 2009
    Messages
    12 430
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur R&D - Développeur Java
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2009
    Messages : 12 430
    Points : 29 131
    Points
    29 131
    Billets dans le blog
    2
    Par défaut
    Salut,

    Tout le fonctionnement de l'UI (affichage, traitement des événements, layout) à quelques très rares exceptions se déroulent dans un seul thread, appelé Event Dispatch Thread. Un thread ne pouvant exécuter qu'une seule chose à la fois, lorsqu'on fait varier un affichage dans l'EDT, on voit le résultat final à la fin de l'exécution de la séquence en question. Par exemple, si sur une action de bouton, tu fais appelles une méthode qui fait varier la taille d'un JLabel, on ne voit le résultat (donc la taille finale du JLabel) que lorsque le code de l'ActionListener du bouton se termine.

    Pour faire une animation, il faut :

    1. soit faire varier les variables, mettre à jour l'affichage, et rendre la main, plusieurs fois de suite, par exemple avec un Timer Swing
    2. soit utiliser un autre thread qui fait des micros mise à jour en demandant à l'EDT de se réveiller pour faire correspondre l'affichage. Si on peut faire ça avec un Thread de base, la classe SwingWorker est spécialement faite pour faire ce genre de choses. Attention, il faut bien penser à l'aspect accès concurrentiel par les deux threads : le SwingWorker résout cette problématique par un système de publication :
      1. la méthode doInBackground sert à produire les "modifications" (dans un thread parallèle) et on appelle la méthode publish pour les publier
      2. la méthode process exécutée dans l'EDT sert à traiter ce qui a été publié pour modifier l'affichage
      3. la méthode done permet de finaliser le process
    L'expression "ça marche pas" ne veut rien dire. Indiquez l'erreur, et/ou les comportements attendus et obtenus, et donnez un Exemple Complet Minimal qui permet de reproduire le problème.
    La plupart des réponses à vos questions sont déjà dans les FAQs ou les Tutoriels, ou peut-être dans une autre discussion : utilisez la recherche interne.
    Des questions sur Java : consultez le Forum Java. Des questions sur l'EDI Eclipse ou la plateforme Eclipse RCP : consultez le Forum Eclipse.
    Une question correctement posée et rédigée et vous aurez plus de chances de réponses adaptées et rapides.
    N'oubliez pas de mettre vos extraits de code entre balises CODE (Voir Mode d'emploi de l'éditeur de messages).
    Nouveau sur le forum ? Consultez Les Règles du Club.

  3. #3
    Nouveau Candidat au Club
    Homme Profil pro
    Développeur Java
    Inscrit en
    Octobre 2019
    Messages
    5
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : Octobre 2019
    Messages : 5
    Points : 1
    Points
    1
    Par défaut
    Merci pour ton retour !
    En fait pour être tout à fait complet, il ne se passe rien pendant que la barre de vie diminue : le jeu doit "attendre" que la diminution ait eu lieu pour que le jeu reprenne son cours. Donc si je comprends bien, dans le "doinbackground" il faudra que je mette la modification de largeur de mon rectangle (éventuellement dans un while pour pouvoir gérer le fait qu'il faut descendre unité par unité), dans "publish" un repaint (pour que la modification soit prise en compte) et dans "done" la suite de mon code ?
    Je suis complètement novice quand il s'agit de multithreading mais le sujet m'intéresse, évidemment.

    EDIT : j'ai quelque chose qui marche presque :
    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
    SwingWorker sw = new SwingWorker()
    {
    	protected Object doInBackground() throws Exception 
    	{
    		while (playerBar.getWidth() != (int) hpLeft)
    		{
    			if (playerBar.getWidth() > hpLeft)
    				playerBar.setBounds(535, 530, playerBar.getWidth() - 1, 25);
    			else
    				playerBar.setBounds(535, 530, playerBar.getWidth() + 1, 25);
    			Thread.sleep(10);
    		}
    		return null;
    	}
    	public void done()
    	{
     
    	}
    };
    sw.execute();
    Si ce n'est quel'exécution ne s'arrête pas le temps que la barre soit arrivée à la bonne valeur (logique, puisque j'ai choisi doinbackground...). Je continue d'explorer.

  4. #4
    Modérateur
    Avatar de joel.drigo
    Homme Profil pro
    Ingénieur R&D - Développeur Java
    Inscrit en
    Septembre 2009
    Messages
    12 430
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur R&D - Développeur Java
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2009
    Messages : 12 430
    Points : 29 131
    Points
    29 131
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par DJCrispyRice Voir le message
    Merci pour ton retour !
    En fait pour être tout à fait complet, il ne se passe rien pendant que la barre de vie diminue : le jeu doit "attendre" que la diminution ait eu lieu pour que le jeu reprenne son cours.
    Je crois deviner le genre d'effet mais ce n'est pas tout à fait clair. Tu as une action dans le jeu (genre je sais pas, le perso se prend un coup), le jeu se met en pause, pendant ce temps là on voit la barre de vie qui diminue, puis le jeu reprend ? Pendant la pause, le joueur n'a aucun contrôle. C'est un peu différent de ce que je pensais.

    Normalement, la programmation des jeux ne se fait pas tout à fait avec les mêmes principes qu'un programme de gestion, qui aurait besoin d'une animation (par exemple, une barre de progression, pour laquelle un SwingWorker est très adapté, ou encore une requête à une db qui prend 10 minutes, alors qu'on veut voir les lignes récupérées qui s'affichent au fur et à mesure et qu'on veut pouvoir annuler à tout moment sans attendre les 10 minutes pour voir le résultat). Même le modèle est spécifique pour les jeux.

    Gestion : MVC (Model View Controler), EDT et éventuellement SwingWorker
    Jeu: ECS (Entity Component System), boucle de jeu, multibuffering

    Commençons par éviter de tout te faire réécrire en restant dans un environnement de gestion :
    1. mettre en pause veut dire arrêter de traiter les événements
    2. faire l'animation (faire varier dans un thread, rafraîchir l'affichage dans l'edt) : un thread ou un swingworker
    3. relancer veut dire reprendre le traitement des évenements


    On peut envisager aussi une sorte t'indermédiaire :

    1. un thread qui fait varier des états (dans ton cas la valeur représentée par la barre de vie)
    2. un thread qui périodiquement rafraichit l'affichagent (genre toutes les 33ms pour faire du 30 images par secondes)
    3. une routine de dessin qui tient compte des états modifiés évidemment




    Citation Envoyé par DJCrispyRice Voir le message
    Donc si je comprends bien, dans le "doinbackground" il faudra que je mette la modification de largeur de mon rectangle (éventuellement dans un while pour pouvoir gérer le fait qu'il faut descendre unité par unité),
    exactement
    Citation Envoyé par DJCrispyRice Voir le message
    dans "publish" un repaint (pour que la modification soit prise en compte)
    plutôt dans process, publish sera appelé par doInBackGround

    en gros :

    doInBaground
    Code pseudo : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
     
    while( c'est pas fini ) {
        faire varier largeur rectangle
        publish( nouvelle largeur rectangle)
    }
    attention à ne pas modifier la variable largeur de rectangle du composant graphique à cet endroit :
    1. si la variable n'est pas volatile et qu'il n'y a pas de synchro, la modification sera "invisible"
    2. si volatile ou synchron, on risque de perdre du temps à faire des choses qui ne seront jamais visibles (parce que l'affichage ne peut pas se mettre à jour aussi vite), et donc d'avoir des effets indésirables
    3. et sinon, risque de cafouillage (exception, effets graphiques bizarres (scintillement, saccades)...)

    attention également à ne pas utiliser une information du composant graphique comme variable d'ajustement du processus parallèle pour les mêmes raisons et surtout parce que cette information ne varie pas dans la même "temporalité" : ce qui est publié n'est pas instantanément à jour dans l'affichage, mais seulement quand il se réveillera (quand il aura le temps)...

    process standard :
    Code pseudo : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    for(i =0; i<nombre de publications; i++) {
        modifier un composant graphique pour refléter le changement i 
    }

    Dans ton cas évidemment, en théorie, il n'y a que la dernière taille de rectangle qui compte, donc on aurait :
    process :
    Code pseudo : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    if ( nombre de largeur rectgangle publiées > 0  {
        modifier la largeur du  rectangle graphique pour refléter le dernier changement publié (et repaint) 
    }

    ensuite il te faudra peut-être filtrer ce que tu publies, ou introduire des pauses entre chaque itération. si tu publies 1000 modifs et que l'affichage n'en traite jamais que 20 maxi, tu feras beaucoup de chose pour rien (qui consomme de la ressource pour rien d'autres que la gêne que ça procure, niveau conso mémoire donc swapping et conso cpu), tu auras forcément des effets indésirables, comme des saccades, ou un peu de lag.* voir ma remarque sur les animations à la fin.

    Citation Envoyé par DJCrispyRice Voir le message
    et dans "done" la suite de mon code ?
    Disons pour simplifier ce qui permet de revenir à l'état avant le lancement du SwingWorker. Dans ton cas, à priori, reprendre le traitement des événements.

    Citation Envoyé par DJCrispyRice Voir le message
    Je suis complètement novice quand il s'agit de multithreading mais le sujet m'intéresse, évidemment.
    Manipuler un SwingWorker est beaucoup plus simple que de faire ça soi-même, mais c'est déjà un très bon début : ça a le mérite de montrer le mécanisme producteur-consommateur en masquant tout l'aspect câblage (accès concurrentiel,, sémaphores, ordonnancement...)

    *
    Remarque : intuitivement, pour faire des animations, on a souvent envie de faire varier une variable de 0 à n, d'un pas p, en attendant un peu entre chaque, pour avoir l'impression par exemple qu'un truc se déplace de 0 à n.
    Résultat : un mouvement non continu, des sauts, et des saccades parce qu'en plus on ne fait pas de double buffering. et une fin parfois en retard, en avance, enfin décalée. Si on fait des enchaînements, ça donne plus d'effets foireux (les effets foireux ont tendance à se combiner pour empirer, on a rarement la chance qu'ils s'annulent pour donner un résultat nickel).

    Une autre façon d'envisager le problème est de déterminer la valeur que devrait avoir n au moment où on la calcule. Ainsi, si le code accélère ou ralenti, le mouvement perçu lui est quand même continu, parce qu'à chaque étape on compense. Et à la fin on force la position finale, au lieu de compter sur le fait que la variation arrivée à son terme est dans le bon état final. Pas de problème de décalage dû aux erreurs de calculs, ou à l'instabilité de l'exécution.

    Dans le premier cas, on va vouloir calculer de combien de pixel il faut faire varier la variable pour qu'on fasse mettons 25 variations en 3 secondes. Dans le second cas, on va faire 25 variations en 3 secondes, et chacune d'entres elles on va déterminer le nombre de pixels qu'on devrait avoir ajouté à la valeur de départ de la variable vu l'heure qu'il est (enfin plus exactement vu le temps en ms qui s'est écoulé depuis le début de l'animation). Il y a une API externe qui orientée vers cette orientation qui s'appelle Timing Framework. Piccolo fournit également une api du genre interfacée avec la boucle de l'EDT pour le traitement de la boucle d'affichage.
    L'expression "ça marche pas" ne veut rien dire. Indiquez l'erreur, et/ou les comportements attendus et obtenus, et donnez un Exemple Complet Minimal qui permet de reproduire le problème.
    La plupart des réponses à vos questions sont déjà dans les FAQs ou les Tutoriels, ou peut-être dans une autre discussion : utilisez la recherche interne.
    Des questions sur Java : consultez le Forum Java. Des questions sur l'EDI Eclipse ou la plateforme Eclipse RCP : consultez le Forum Eclipse.
    Une question correctement posée et rédigée et vous aurez plus de chances de réponses adaptées et rapides.
    N'oubliez pas de mettre vos extraits de code entre balises CODE (Voir Mode d'emploi de l'éditeur de messages).
    Nouveau sur le forum ? Consultez Les Règles du Club.

  5. #5
    Modérateur
    Avatar de joel.drigo
    Homme Profil pro
    Ingénieur R&D - Développeur Java
    Inscrit en
    Septembre 2009
    Messages
    12 430
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur R&D - Développeur Java
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2009
    Messages : 12 430
    Points : 29 131
    Points
    29 131
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par DJCrispyRice Voir le message
    [...]
    Tu as fait une première erreur en faisant tout dans le thread parallèle, tout ce que tu fais c'est déplacer la partie "état" de l'animation dans un autre thread, tout en manipulant des états que seuls l'EDT devrait manipuler, sans demander à Swing de repaint()...

    En attendant de retrouver un exemple dans mes archives ou d'en faire un spécifiquement, voici un exemple de SwingWorker à la fois assez simple et assez évolué, pour le principe : https://www.developpez.net/forums/d1.../#post10002547
    L'expression "ça marche pas" ne veut rien dire. Indiquez l'erreur, et/ou les comportements attendus et obtenus, et donnez un Exemple Complet Minimal qui permet de reproduire le problème.
    La plupart des réponses à vos questions sont déjà dans les FAQs ou les Tutoriels, ou peut-être dans une autre discussion : utilisez la recherche interne.
    Des questions sur Java : consultez le Forum Java. Des questions sur l'EDI Eclipse ou la plateforme Eclipse RCP : consultez le Forum Eclipse.
    Une question correctement posée et rédigée et vous aurez plus de chances de réponses adaptées et rapides.
    N'oubliez pas de mettre vos extraits de code entre balises CODE (Voir Mode d'emploi de l'éditeur de messages).
    Nouveau sur le forum ? Consultez Les Règles du Club.

  6. #6
    Nouveau Candidat au Club
    Homme Profil pro
    Développeur Java
    Inscrit en
    Octobre 2019
    Messages
    5
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : Octobre 2019
    Messages : 5
    Points : 1
    Points
    1
    Par défaut
    Eh ben, j'ai de la lecture

    Si tu veux plus d'élément de contexte, je refais le système de combat de la série Pokémon dans un style textuel : j'ai donc une "console" où des événements sont consignés (X a utilisé l'attaque Y, l'attaque a touché/échoué, etc). La console affiche également les actions possibles. Typiquement :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    0. Switch Pokémon
    1. Attack 1
    2. Attack 2
    3. Attack 3
    4. Attack 4
    L'utilisateur tape le numéro de l'action qu'il veut, le tour se déroule, puis le tour suivant démarre etc...
    En fait si je veux faire cet effet de barre de vie qui diminue progressivement, c'est tout simplement pour coller au jeu. Dans l'original (si tu ne connais pas), la mécanique est la suivante :
    1. Le jeu affiche dans la boîte de dialogue "X lance l'attaque Y"
    2. S'il y a une notion de dégâts : la barre de vie de l'adversaire fait son animation (tout en laissant dans la boîte de dialogue le texte ci-dessus, le joueur ne peut rien faire à part attendre que l'animation soit finie)
    3. Le jeu affiche un éventuel texte lié à l'attaque ("C'est super efficace", "Coup critique", autre...) puis l'attaque suivante a lieu

    J'espère que, pour toi, le contexte est maintenant plus clair.

    Concernant le fond, j'avoue que je patauge un peu. En fait, actuellement ma barre de vie a une longueur de 100 pixels. Je fais en sorte qu'il s'affiche un pourcentage de cette valeur en calculant tout simplement ce même ratio entre les PV actuels et les PV max. Comme la classe chargée de l'affichage n'a accès qu'à la valeur de PV finale (après que le calcul de dégâts ait eu lieu donc), je fais une manip un peu crado qui consiste à me baser la largeur actuelle de la barre de vie... et je fais moduler avec la différence avec la nouvelle valeur (imaginons que le pokémon avait toute sa vie, cela signifie que la barre fait 100px. S'il a perdu 50% de sa vie, je vais faire 100-50 grossièrement). Autrement dit, je fais mon ratio, je compare avec la largeur de la barre avant application des dégâts et je fais varier ensuite de +1 ou -1 avec des tempo. A ce propos, j'ai du mal à voir comment je peux faire autrement sauf à utiliser une API externe, comme tu le soulignes.

    Dans ton explication, je ne suis pas sûr de comprendre ce que change le for par rapport au while que je fais actuellement. L'animation a bien lieu en fait, c'est juste qu'elle a lieu en même temps que le reste de mon algorithme qui continue à tourner... Idéalement, je voudrais mettre en pause le thread principal, faire l'animation dans le SwingWorker puis relancer le thread principal. C'est là que j'ai du mal à comprendre comment ça se passe.

  7. #7
    Modérateur
    Avatar de joel.drigo
    Homme Profil pro
    Ingénieur R&D - Développeur Java
    Inscrit en
    Septembre 2009
    Messages
    12 430
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur R&D - Développeur Java
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2009
    Messages : 12 430
    Points : 29 131
    Points
    29 131
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par DJCrispyRice Voir le message
    Dans ton explication, je ne suis pas sûr de comprendre ce que change le for par rapport au while que je fais actuellement.
    Ce n'est pas un problème de for ou de while, mais un problème de thread (de pas faire les choses dans l'EDT déjà, mais aussi de ne pas risque des problèmes de concurrences d'accès _ tu remarqueras que je ne lis ni ne modifie aucune même variable dans les deux threads (EDT et SwingWorker)).

    Citation Envoyé par DJCrispyRice Voir le message
    L'animation a bien lieu en fait, c'est juste qu'elle a lieu en même temps que le reste de mon algorithme qui continue à tourner...
    C'est-à-dire, algo qui continue de tourner ? il fait quoi cet algo ? J'avais cru comprendre que tu voulais bloquer tout pendant l'anim...
    Citation Envoyé par DJCrispyRice Voir le message
    Idéalement, je voudrais mettre en pause le thread principal, faire l'animation dans le SwingWorker puis relancer le thread principal. C'est là que j'ai du mal à comprendre comment ça se passe.
    C'est quoi le thread principal ? L'EDT ou un autre ? De toute façon, y'a rien qui permette de faire "pause" sur un thread. Un thread peut s'attendre, ou arrêter d'attendre, ou faire semblant de ne rien faire en faisant une boucle vide (ce qui n'est une bonne manière de faire, ça peut causer en particulier une famine).
    Si ton thread c'est l'EDT, tu ne peux pas le mettre en pause si tu veux voir une animatiion. Si c'est un autre thread, ça dépend du thread. Si c'est un thread de boucle de jeu, tu dois avoir des états, et il y a un état "pause", ou plusieurs s'il faut différencier. Sinon, c'est disons fastidieux...


    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
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
    99
    100
    101
    102
    103
    104
    105
    106
    107
    108
    109
    110
    111
    112
    113
    114
    115
    116
    117
    118
    119
    120
    121
    122
    123
    124
    125
    126
    127
    128
    129
    130
    131
    132
    133
    134
    135
    136
    137
    138
    139
    140
    141
    142
    143
    144
    145
    146
    147
    148
    149
    150
    151
    152
    153
    154
    155
    156
    157
    158
    159
    160
    161
    162
    163
    164
    165
    166
    167
    168
    169
    170
    171
    172
    173
    174
    175
    176
    177
    178
    179
    180
    181
    182
    183
    184
    185
    186
    187
    188
    189
    190
    191
    192
    193
    194
    195
    196
    197
    198
    199
    200
    201
    202
    203
    204
    205
    206
    207
    208
    import java.awt.BorderLayout;
    import java.awt.Color;
    import java.awt.Graphics;
    import java.awt.GridBagConstraints;
    import java.awt.GridBagLayout;
    import java.awt.Insets;
    import java.util.Arrays;
    import java.util.List;
     
    import javax.swing.BorderFactory;
    import javax.swing.JButton;
    import javax.swing.JFrame;
    import javax.swing.JPanel;
    import javax.swing.SwingWorker;
     
    public class BarreDeVieExample1 {
     
    	public static final long TIME = 1000; // la durée de l'animation
    	public static final long RATE = 15; // le temps entre deux rafraîchissements lors de l'animation
    	public final static int LIFE = 200; // la durée de vie initiale
    	public final static int BARHEIGHT = 75; // la hauteur de la barre de vie (on part sur une barre horizontale qui
    											// s'étend dans le composant)
    	public final static int SPACE = 5; // une taille de goutière pour les grilles
     
    	public final static int[] POWER = { 20, 50, 100 }; // les puissances d'attaques possibles
     
    	public static void main(String[] args) {
     
    		// on créer la fenêtre
    		JFrame frame = new JFrame("");
    		frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
     
    		// le panneau de la barre de vie
    		LifeBarPanel lifeBarPanel = new LifeBarPanel();
    		lifeBarPanel.setForeground(Color.ORANGE); // la couleur de la barre de vie
    		lifeBarPanel.setBorder(BorderFactory.createEmptyBorder(SPACE, SPACE, SPACE, SPACE));
     
    		// le panneau des boutons
    		JPanel buttonpanel = new JPanel(new GridBagLayout());
    		GridBagConstraints gbc = new GridBagConstraints();
    		gbc.gridx = 0;
    		gbc.gridy = GridBagConstraints.RELATIVE;
    		gbc.insets = new Insets(SPACE, SPACE, SPACE, SPACE);
    		JButton[] buttons = new JButton[POWER.length + 1]; // un bouton pour chaque attaque plus un reset
    		for (int i = 0; i < POWER.length; i++) {
    			int power = POWER[i];
    			JButton button = new JButton(String.valueOf(power));
    			// l'action du bouton d'attaque
    			// - désactiver les actions sur tous les boutonsn
    			// - lancer l'animation d'attaque (barre de vie qui baisse)
    			// - à la fin on réactive tous les boutons
    			button.addActionListener(e -> {
    				Arrays.stream(buttons).forEach(b -> b.setEnabled(false));
    				lifeBarPanel.attack(power, () -> Arrays.stream(buttons).forEach(b -> b.setEnabled(true)));
    			});
    			buttonpanel.add(button, gbc);
    			buttons[i] = button;
    		}
    		// bouton de resett
    		JButton resetbutton = new JButton("Reset");
    		resetbutton.addActionListener(e -> lifeBarPanel.reset());
    		buttons[buttons.length - 1] = resetbutton;
    		buttonpanel.add(resetbutton, gbc);
     
    		// on compose la fenêtre
    		frame.add(buttonpanel, BorderLayout.WEST);
    		frame.add(lifeBarPanel);
     
    		// on affiche la fenêtre
    		frame.setSize(600, 300);
    		frame.setLocationRelativeTo(null);
    		frame.setVisible(true);
     
    	}
     
    	private static class LifeBarPanel extends JPanel {
     
    		private int life; // la vie actuelle
    		private int currentlife; // la dernière vie avant début d'animation (pour gérer un effet)
     
    		public LifeBarPanel() {
    			reset();
    		}
     
    		/**
                     * RAZ le montant de vie
                     */
    		public void reset() {
    			life = LIFE;
    			currentlife = life;
    			repaint();
    		}
     
    		@Override
    		public void paint(Graphics g) {
    			super.paint(g);
     
    			if  (life>0 && currentlife>0 ) {
     
    				Insets insets = getInsets(); // pour éliminer les bordures
     
    				int y = (getHeight() - insets.top - insets.bottom - BARHEIGHT) / 2; // centrage vertical
     
    				int width = getWidth() - insets.left - insets.right; // largeur totale dispo 
     
    				// la valeur courrante au début de l'anim pour faire un petit effet
    				int currentrectwidth = (int) (((double) currentlife / LIFE) * width);
    				g.setColor(getCurrentBarColor());
    				g.fillRect(0, y, currentrectwidth, BARHEIGHT);
     
    				// la valeur de la vie = la longueur de la barre remise à l'échelle du composant
    				int rectwidth = (int) (((double) life / LIFE) * width);
    				g.setColor(getBarColor());
    				g.fillRect(0, y, rectwidth, BARHEIGHT);
     
    				// une bordure pour la barre
    				g.setColor(getBarBorderColor());
    				g.drawRect(0, y, rectwidth, BARHEIGHT);
     
     
    			}
     
    		}
     
    		private Color getBarColor() {
    			return getForeground();
    		}
     
    		private Color getBarBorderColor() {
    			return Color.BLACK;
    		}
     
    		private Color getCurrentBarColor() {
    			return getForeground().darker();
    		}
     
    		public void attack(int power, Runnable done) {
     
    			// ici thread EDT
     
    			int oldlife =  life;
     
    			// on calcule la nouvelle vie
    			int newlife = Math.max(0, life - power);
    			// si pas de changement, on arrête là
    			if (newlife == oldlife) {
    				return;
    			}
     
    			// la différence entre avant et après
    			int diff = oldlife - newlife;
     
    			// la vie au début de l'animation
     
    			// création du worker
    			SwingWorker<Integer, Integer> worker = new SwingWorker<Integer, Integer>() {
     
    				@Override
    				protected Integer doInBackground() throws Exception {
     
    					// ici thread pas EDT
     
    					// le temps au début de l'anim
    					long starttime = System.currentTimeMillis();
     
    					// le temps passé depuis le début
    					long timeelapsed;
    					// tant qu'on a pas atteint le temps d'anim
     
    					while ((timeelapsed = System.currentTimeMillis() - starttime) < TIME) {
    						// on calcule la taille de la vie au moment qu'on est
    						publish(oldlife - (int) ((diff * timeelapsed) / TIME));
    						// on dort ce qu'il faut
    						Thread.sleep(RATE);
    					}
     
    					// à la fin, le résultat final
    					return newlife;
     
    				}
     
    				@Override
    				protected void process(List<Integer> chunks) {
    					// ici thread EDT
    					// ici on traite et affiche les résultats
    					life = chunks.get(chunks.size() - 1); // on ne prend pas les résultats intermédiaire
    					repaint(); // on redessin
    				}
     
    				@Override
    				protected void done() {
    					// ici thread pas EDT
    					life = newlife; // valeur final (on utilise ça au lieu de get, pas d'exception à traiter et on a
    									// le résultat final sans le calculer
    					currentlife = life; // on retombe sur un état stable et cohérent
    					repaint(); // on redessine pour que ça soit clean
    					done.run(); // on finalise
    				}
     
    			};
     
    			worker.execute(); // on exécute le timer
     
    		}
     
    	}
     
    }
    L'expression "ça marche pas" ne veut rien dire. Indiquez l'erreur, et/ou les comportements attendus et obtenus, et donnez un Exemple Complet Minimal qui permet de reproduire le problème.
    La plupart des réponses à vos questions sont déjà dans les FAQs ou les Tutoriels, ou peut-être dans une autre discussion : utilisez la recherche interne.
    Des questions sur Java : consultez le Forum Java. Des questions sur l'EDI Eclipse ou la plateforme Eclipse RCP : consultez le Forum Eclipse.
    Une question correctement posée et rédigée et vous aurez plus de chances de réponses adaptées et rapides.
    N'oubliez pas de mettre vos extraits de code entre balises CODE (Voir Mode d'emploi de l'éditeur de messages).
    Nouveau sur le forum ? Consultez Les Règles du Club.

  8. #8
    Nouveau Candidat au Club
    Homme Profil pro
    Développeur Java
    Inscrit en
    Octobre 2019
    Messages
    5
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : Octobre 2019
    Messages : 5
    Points : 1
    Points
    1
    Par défaut
    Citation Envoyé par joel.drigo Voir le message
    C'est-à-dire, algo qui continue de tourner ? il fait quoi cet algo ? J'avais cru comprendre que tu voulais bloquer tout pendant l'anim...
    Ben oui c'est ce que je veux et c'est ça mon point de blocage : l'animation se passe en même temps que tout le reste alors que je veux que la cinématique suivante se passe :
    1. Attaque
    2. Calcul des dégâts etc
    3. Appel de la fonction "drawPlayerHp" qui se charge de dessiner la barre de vie
    4. On calcule la différence entre la largeur actuelle et celle liée au nouvel état des PV
    5. Tout s'arrête, l'algo doit être "en pause" (il ne lance pas l'attaque suivante, il ne permet pas de choisir une nouvelle attaque si c'était une fin de tour : rien ne se passe), l'animation de la barre de vie a lieu
    6. Une fois la nouvelle largeur de la barre de vie affichée, le programme reprend son cours et passe à la suite (attaque suivante du tour, choix de l'attaque avant le tour suivant...)

    C'est en gros ce qu'il se passe dans le jeu originel Pokémon et c'est ce que je cherche à reproduire. Aujourd'hui avec le code précédent j'ai bien mon animation (même si, selon toi, c'est un peu crado puisque je manipule mon objet directement dans "doInBackground") mais le jeu affiche directement après la suite des événements alors que je veux que tout se stoppe tant que la barre n'a pas atteint sa largeur finale.
    Dans le code que tu as fourni, en fait je ne comprends pas où la taille de la barre de vie varie (pour rappel dans mon cas, j'ai un JLabel qui est un rectangle avec un fond coloré dont je fais varier la largeur selon la quantité de vie que le joueur a). Tu fais un repaint, ok, mais je crois que quelque chose m'échappe...
    En essayant d'adapter à ma sauce ton code (j'ai laissé de côté la question de temps qui n'a pas d'importance pour le moment, j'obtiens ça (mais le problème est toujours le même)
    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
    SwingWorker<Integer,Integer> sw = new SwingWorker<Integer,Integer>()
    {
    	protected Integer doInBackground() throws Exception 
    	{
    		int width = playerBar.getWidth();
    		while (width != (int) hpLeft)
    		{
    			if (playerBar.getWidth() > hpLeft)
    				width = width - 1;
    			else
    				width = width + 1;
    			publish(width);
    			Thread.sleep(50);
    		}
    		if (hpLeft == 0)
    			playerBar = null;
    		return null;
    	}
     
    	@Override
    	protected void process(List<Integer> chunks) 
    	{
    		playerBar.setBounds(535, 530, chunks.get(0), 25);
    		repaint();
    	}
     
    	public void done() 
    	{
    		repaint();
    		run();
    	}
    };
    sw.execute();
    Je suis désolé mais je crois vraiment que je passe à côté d'un truc

    EDIT : je n'ai jamais géré de thread de ma vie donc je pense que tout se déroule dans l'EDT en fait. Est-ce que ça veut dire qu'il faut que je gère un thread dès le départ (par exemple quand je lance un combat) ?

  9. #9
    Modérateur
    Avatar de joel.drigo
    Homme Profil pro
    Ingénieur R&D - Développeur Java
    Inscrit en
    Septembre 2009
    Messages
    12 430
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur R&D - Développeur Java
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2009
    Messages : 12 430
    Points : 29 131
    Points
    29 131
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par DJCrispyRice Voir le message
    [*]Tout s'arrête, l'algo doit être "en pause" (il ne lance pas l'attaque suivante, il ne permet pas de choisir une nouvelle attaque si c'était une fin de tour : rien ne se passe), l'animation de la barre de vie a lieu
    Je vois le principe. Mais le souci c'est que ça dépend de la façon de le faire. Et y'en a beaucoup. En théorie, le fonctionnement d'un jeu est fondé sur une boucle de jeu et là c'est très facile de dire que la boucle fait ça ou ça (un switch()).
    En plus, ça dépend complètement du jeu, que je connais de nom, mais auquel je n'ai jamais joué (j'ai déjà bien assez à faire niveau jeu et ce n'est pas vraiment ma tasse de thé, surtout tout ce qui Nintendo, mais c'est une autre histoire). En tour par tour, on pourra se passer de thread et tout faire sur l'EDT, à moins que ça prenne vraiment du temps, eutiliser une technique de ping pong (entre action swing et thread), et du coup aucun souci pour que le monstre soit bloqué pendant l'anime de la barre de vie.
    En dynamique concurrentiel, où le joueur et l'ordinateur "joue" en même temps, on devra mettre la partie de l'ordinateur dans un thread. Avec une GUI à mettre à jour, autant utiliser un SwingWorker, ou un Timer Swing si le traitement s'y prête, dans les deux cas on utilise un thread sauf que la partie technique est gérée par la classe, donc c'est adapté à ceux qui ne maîtrise pas tous les aspects, et ça simplifie le boulot aussi.

    Ensuite, thread/pas thread, la partie du programme qui correspond au jeu de l'ordinateur est une séquence de statements. Si on a de la chance, on a une boucle de jeu spécifique, qu'on peut résumer par :


    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    tant que le monstre est en vie {
         switch(état) {
              case ETAT_1: faire ce qu'il faut...
              case ETAT_2: faire ce qu'il faut...
              case ETAT_3: ...
         }
         rafraichir l'affichage
    }
    on peut facilement introduire un état : JEU_EN_PAUSE et ne rien faire quand le monstre est dans cet état. On peut aussi mettre le thread en attente : enfin, plus exactement le thread peut se mettre en attente
    en gros on va avoir :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    tant que le monstre est en vie {
         switch(état) {
              case ETAT_1: faire ce qu'il faut...
              case ETAT_2: faire ce qu'il faut...
              case ETAT_PAUSE: attendre
         }
         rafraichir l'affichage
    }
    et un autre thread va pouvoir dire au monstre "passe dans l'etat "pause"
    ensuite un autre thread (celui qui gère l'anim de la barre de vie) pourra dire au thread réveille-toi

    Un thread peut se mettre en attente via une instance d'objet qu'il a verrouiller dans un bloc synchronized par la méthode wait :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    synchronized(objetverrou) {
              objetverrou.wait();
    }
    un thread pourra débloque 1 thread en attente ou tous les threads en attente, par notify, ou notifyAll, via une instance d'objet qu'il a verrouiller dans un bloc synchronized par la méthode wait :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    synchronized(objetverrou) {
              objetverrou.notify();
    }
    Peu importe l'objet, on peut faireObject objetverrou=new Object() par exemple. En revanche, il doit être accessible forcément pour appeler les méthodes.

    On peut aller plus loin que ce système basique en implémentant des verrous (api java.util.concurrent.Lock).

    Il y d'autres systèmes qui peuvent être mieux adapté, comme le CountDownLatch : c'est une classe qui permet qu'un thread se mette en attente qu'un certain nombre de trucs soient réalisés avant de continuer. Par exemple, dans ton cas, un process pourrait lancer le traitement sur la barre de vie en disant j'attends qu'elle varie de 100 et la routine pour la barre de vie faire une boucle de 0 à 100 en indiquant à chaque itération au countdownlatch qu'elle a fait une itération. Au bout de 100 itérations, le thread qui attendais continue, puis le countdownlatch a compté 100 fois. Ou alors un join, qui permet un thread de lancer un autre thread et attendre que celui-ci soit terminé, ainsi
    1. je fais des trucs
    2. je lance l'animation de la barre de vie et j'attends qu'elle se termine
    3. je continue de faire des trucs

    mais on ne fait pas ça avec un SwingWorker



    maintenant si tu n'as pas un point de bouclage par lequel tu passes très régulièrement, il faudrait mettre ces points d'attente partout, et c'est très fastidieux

    en tout cas il n'est pas possible de dire à un thread : attends et je viens te dire quand tu pourras repartir, tout comme on ne peut pas lui dire de s'arrêter (attention, tu pourras voir que la classe à ce genre de méthode, mais ça ne fonctionne pas du tout et si tu lis bien la doc de ces méthodes, tu verras qu'on te dit de ne surtout pas utiliser ces méthodes).


    Citation Envoyé par DJCrispyRice Voir le message
    EDIT : je n'ai jamais géré de thread de ma vie donc je pense que tout se déroule dans l'EDT en fait. Est-ce que ça veut dire qu'il faut que je gère un thread dès le départ (par exemple quand je lance un combat) ?
    Et tu n'as pas de freezes je suppose ? Donc tu n'as pas une grosse boucle qui fait alterner joueur et ordi; Comment ça se passe au juste, le joueur lance une attaque, via une action swing : elle traite l'attaque joueur vs ordi puis elle fait le code qui correspond à l'attaque ordi vs joueur non ? Dans ce cas, c'est plutôt facile, au lieu d'écrire :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    joueur attaque ordi
    anim barre de vie en parallèle
    ordi attaque joueur // donc ça ça se passe pendant l'anim
    il faut faire
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    joueur attaque ordi
    anim barre de vie en parralèle et à la fin ordi attaque joueur
    Le done() du SwingWorker est là pour ça : exécuter du code Swing quand tout est terminé (dans mon exemple, je réactive les boutons)
    L'expression "ça marche pas" ne veut rien dire. Indiquez l'erreur, et/ou les comportements attendus et obtenus, et donnez un Exemple Complet Minimal qui permet de reproduire le problème.
    La plupart des réponses à vos questions sont déjà dans les FAQs ou les Tutoriels, ou peut-être dans une autre discussion : utilisez la recherche interne.
    Des questions sur Java : consultez le Forum Java. Des questions sur l'EDI Eclipse ou la plateforme Eclipse RCP : consultez le Forum Eclipse.
    Une question correctement posée et rédigée et vous aurez plus de chances de réponses adaptées et rapides.
    N'oubliez pas de mettre vos extraits de code entre balises CODE (Voir Mode d'emploi de l'éditeur de messages).
    Nouveau sur le forum ? Consultez Les Règles du Club.

  10. #10
    Expert confirmé Avatar de yildiz-online
    Homme Profil pro
    Architecte de domaine
    Inscrit en
    Octobre 2011
    Messages
    1 444
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Architecte de domaine

    Informations forums :
    Inscription : Octobre 2011
    Messages : 1 444
    Points : 4 563
    Points
    4 563
    Par défaut
    Pour faire du multithread avec un EDT, tu peux faire un bête producer/consumer d'event.

    Ta boucle de jeu fourni des events à l'EDT via autant de thread que tu veux, et ton EDT va calculer de son coté les affichages en fonction de ce qu'il va récupérer dans la collection d'event à traiter.
    Les event peuvent être des actions, mais aussi des changements d'état.
    Tu peux appliquer le même principes pour les autres moteurs de ton jeu (audio, physique, réseau, IA,...)

    Ainsi tu découple ta logique de jeu de la manière dont elle est représentée.

    C'est une solution assez simple et réactive, par contre c'est pas évident à debug(enfin comme tout ce qui est multithread)
    PXL le retro-gaming facile: Essayez-le

    Yildiz-Engine an open-source modular game engine: Website
    Yildiz-Online a 3D MMORTS in alpha: Facebook page / Youtube page

  11. #11
    Nouveau Candidat au Club
    Homme Profil pro
    Développeur Java
    Inscrit en
    Octobre 2019
    Messages
    5
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : Octobre 2019
    Messages : 5
    Points : 1
    Points
    1
    Par défaut
    Je vous remercie pour vos réponses détaillés

    Si vous voulez mieux comprendre comment mon jeu fonctionne, en gros ça fait :
    • Une fonction main qui gère le squelette (la séquence successive des tours en fonction de critères de priorités)
    • Une fonction "aTurn" qui fait parti d'une classe "Battle" qui gère les différentes actions consécutives dans un tour (on dit "un tour" pour représenter l'action effectuée par un Pokémon et ses conséquences. Une fois cela fait, le tour passe et c'est à l'autre Pokémon d'agir)
    • La fonction "aTurn" appelle tout un tas d'autres fonctions à la suite pour gérer le lancement de l'attaque, le calcul des dégâts...
    • La fonction qui nous intéresse est la fonction "checkDead" présente dans la classe "Player" (qui a son dérivé IA, c'est une classe fille de player avec des méthodes en plus liées au fonctionnement de l'IA) qui est la dernière fonction appelée par "aTurn". A ce stade, les divers calculs de dégâts ont déjà été réalisés et celle-ci est appelée uniquement s'il y a eu un changement de point de vie d'un monstre (positif ou négatif - un pokémon peut également se soigner). C'est dans cette fonction que je redessine la barre de vie :

    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
    public boolean checkDead(Window win)
    {
    	win.drawPlayerHp(this.getCurrentPkmn());
    	if (this.getCurrentPkmn().getStatus()==9)
    	{
    		win.removeSprite(win.getPlayer());
    		if (this.getTeam().size()>0)
    		{
    			win.logTrace("Please choose another Pokémon from your team.");
    			for (int i = 0; i < this.getTeam().size(); i++)
    			{
    				win.logTrace(Integer.toString(i+1)+" - "+this.getTeam().get(i).getName());
    			}
    			win.logTrace("*********************** ");
    			win.whatToChoose = "swap";
    			this.getCurrentPkmn().setCanAttack(false);
    		}
    		else
    		{
    			win.removeSprite(win.getPlayer());
    			win.logTrace("You lost the battle, all of your pokémons fainted. :-(");
    			win.logTrace("Wanna play again ? 1 for YES, 2 for NO");
    			win.whatToChoose = "continue";
    		}
    		return true;
    	}
    	else
    		return false;
    }
    win est un objet de ma classe "Window" qui gère toute les routines d'affichage (sprites et barres de vie) ainsi que les retours écrits dans la console (via "logTrace"). La base reste un jeu textuel, j'ai juste ajouté une mini couche graphique :

    Nom : tpg.PNG
Affichages : 163
Taille : 45,3 Ko

    Dans ce cas, on pourrait imaginer ici la création d'un thread dans lequel va s'exécuter "drawPlayerHp" avec une variable booléenne qui passerait à "true" une fois que son exécution est terminée ? Est-ce que ça serait possible ou logique ?
    En tout cas, la mise en place de threads pour gérer d'autres trucs tels que la musique serait pas mal car j'ai aussi des difficultés avec ça (par exemple quand un joueur lance un Pokémon, je voudrais que le cri du pokémon se joue puis que le combat commence. Là j'ai bricolé un truc avec des sleep pour donner l'illusion que le cri doit se jouer en entier mais c'est pas terrible).
    J'imagine qu'on pourrait aussi imaginer faire un thread pour le lancement d'un tour, c'est peut-être mieux en termes de perfs mais ça n'aurait aucun intérêt pour ce qui est du parallélisme (puisque les tours sont successifs quoi qu'il arrive, c'est vraiment du "une chose à la fois").

Discussions similaires

  1. [Look and feel] Texte des JLabels en gras
    Par aliasjcdenton dans le forum AWT/Swing
    Réponses: 11
    Dernier message: 26/01/2006, 11h49
  2. [DBGrid] adpater la largeur de dbgrid
    Par esperances dans le forum Bases de données
    Réponses: 5
    Dernier message: 21/04/2004, 10h18
  3. Réponses: 5
    Dernier message: 27/02/2004, 11h20
  4. [Flash MX] Largeur du MovieClip à l'écran ?
    Par FredericB dans le forum Flash
    Réponses: 6
    Dernier message: 24/02/2004, 16h17
  5. [JMF][MediaPlayer] hauteur et largeur de la video
    Par mbp566 dans le forum Multimédia
    Réponses: 3
    Dernier message: 07/08/2002, 15h19

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