JavaquariumFX, problèmes de Threads.

Bonjour,
Je voudrais faire l'exercice du javaquarium de SpaceFox, mais avec une interface graphique.
Après de nombreux tests et recherches je suis totalement bloqué. Je ne sis pas comment faire la structure du programme.

En gros l'idée serait d'avoir à droite une console (héritant du ScrollPane) avec une fonction afficher(texte, couleur).
A gauche l'aquarium (au moins sa vue, qui hérite de groupe), dedans il faudrait que les poissons se baladent en permanence.
Ensuite il me faudrait un autre Thread avec une boucle, chaque tout de boucle = un tour de simulation.
Mais ! Pendant cette simulation, à certains moments il faudrait déclencher une animation qui déplacerait un poisson vers sa cible (pour manger par exemple), la simulation reprend quand l’animation est terminée.
Je pensais bien faire un thread quelque part et le "pause/play" régulièrement, mais bon je n'arrive déjà pas à faire console.afficher sans une Exception qui me dit que je suis pas sur le Thread JavaFX.

Bref comment structurer tout ça ? sachant que je voudrais séparer au maximum GUI et Objets (Poisson, Algues,...) pour faire l'exercice correctement.
Dois je utiliser des Transition ou faire une boucle d'animation plus classique? Dans le dernier cas, comment afficher les poissons ? avec une fonction draw() dans leur objet ?

Merci d'avance.

Plutot qu'un thread qui boucle utilise l'AnimationTimer pour changer l’état de ton monde a intervalles réguliers.

Pour le déplacement du poisson, soit justement tu intègre ce déplacement dans les modifs du monde qui sont dans le timer principal (ce que ferai un jeu video normal), soit tu crées une Transition dédiée qui s'en charge.

Alors pour l'affichage c'est ton choix :

• Tu fais tout en vectoriel avec des nœuds et chaque objet est visuellement une entité indépendante qui sera affichée par le SceneGraph
• Tu fais ca en 2D (plus complexe mais sans doute mieux optimise) en bitmaps (pixels morts) en dessinant dans le contexte graphique d'un Canvas ou d'une WriteableImage ou a l'ancienne via Java2D (voir FXGaphics2D - necessite une dependence a java.desktop pour Java2D/AWT/Swing) - dans ce cas la plus de transitions par contre (c'est le timer principal qui fera le rendu).

Merci de ta réponse,

En fait plutôt que l'animationTimer j'ai lancé les calculs dans un autre Thread avec une while, pour l’affichage dans la console j'utilise Plateforme.runLater(), mais pour l'instant j'ai mis un Thread.sleep()d ans la boucle sinon le runLater est dépassé.
Le .wait() et .notify() marchent à condition de mettre syncronized (leThread){...}.

Du coup effectivement, je voulais éviter de devoir gérer tout de manière classique avec un canva, pour me concentrer sur l'exercice de l'aquarium et pour utiliser les possibilités JavaFX.
J'ai créé un objet PoissonView(Poisson p)qui hérite de ImageView, donc il faudra penser à le faire pour chaque poisson créé. Est ce que c'est une bonne idée ?
L'objet PoissonView aura aussi une Transition personnelle, quand elle se terminera elle se modifiera pour le faire aller ailleurs (pour faire un mvm un peu random) où pour aller sur la cible si le calculateur le demande. (qui est dans la classe Aquarium d'ailleurs).

Tu peux effectivement utiliser un Thread si tu veux mais étant donné que tu as une classe déjà toute dédiée à cela c'est un peu dommage de ne pas l'utiliser.

Un Thread avec une boucle infinie et sans appel à sleep() c'est MAL, ça bouffe 100% du temps CPU et ça ne laisse pas le temps à Java d'exécuter ses autres process ni de réclamer ta mémoire. Envoyer une multitude de Platform.runLater() va de plus complètement noyer le thread JavaFX; essaie de collecter toutes tes modifs dans une liste et d'envoyer un seul Platform.runLater() une fois tous les calculs effectués.

En premiere approche si tu veux que ton jeu tourne à 60FPS tu peux tenter de le faire faire dormir 1/60*1000ms. En seconde approche pour maintenir ton frame rate tu dois compenser ton temps de calcul et de rendu et le déduire du temps d'assoupissement. En 3eme approche... tu délègue ton rendu dans un autre thread... en 4ème approche... eh bien l'AnimationTimer est là pour ça en fait.

Pour les poissons vi c'est une bonne idée. A toi après de tester si les transitions ne se genent pas entre elles, si tu n'en oublies pas en route, si tu penses à bien les arrêter et les retirer si tu en changes en route, si pas de fuite mémoire, etc.

Effectivement si j'utilise un AnimationTimer au lieu de mon Thread je n'ai pas besoin de Plateforme.runLater.
Mais si je .wait() mon AnimationTimer, tout JavaFX est freezé :S

Ce n'est pas fait pour faire ça. Quel besoin as-tu d'invoquer wait() ?

Bah justement je fait mais calculs pendant que les poissons se baladent, à plusieurs moment dans les calculs je met en pause les dits calculs et au lieu de se balader, un poisson fait une action particulière (graphiquement parlant).
Quand l'action se termine, le poisson retourne se balader et le Thread calcul reprend avec .notify().
Ça marche plutôt pas mal je suis en train de faire une fonction qui justement dévie le poisson vers une cible au lieu de se balader.

Mais est ce que c'est propre ? Pour l'instant j'ai donc un thread dont le run() boucle, et un Plateforme.runLater() pour chaque affichage d'une ligne dans la "console" (celle que j'ai faites et qui s'affiche dans la fenêtre), puisque l'appelle de la fonction vient du Thread qui n'est pas le Thread JavaFX.
La boucle du run ne fera un tour complet que relativement rarement, le temps de jouer toute les animations de manger, se reproduire,...

Ce n'est pas comme ça qu'on fait une animation (ou un jeu) : ta boucle principale tourne à un rythme régulier, tel un cœur qui bat, pour faire tourner ton monde. S'il peut y avoir des variations dans le rythme, c'est uniquement dans le but de compenser des retard suite à des calculs trop longs/lents mais en aucun cas une mise en pause en attendant que l'affichage ou quelque chose d'autre ait fini de faire sa bidouille. Ensuite c'est à l'affichage de s'adapter au nouvel état du monde quitte à interrompre des animations en cours.

• Comprendre la programmation d'un jeu vidéo par Alexandre Laurent

De la même manière une boucle événementielle principale telle que l'EDT utilisée par AWT/Swing (EDT alterne entre affichage et traitement des évents) ou le JavaFX Application Thread (le rendu est géré par un autre thread auquel tu n'as pas accès) ne saurait souffrir de blocages. C'est bien pour cela qu'une app fonctionne très mal lorsqu'on fait un traitement trop long ( AWT/Swing et FX ont des framework pour les taches de longue durée) ou pire sont bloquées par l'utilisateur.