OVH Cloud OVH Cloud

Question d'implementation

14 réponses
Avatar
julien
Bonjour
Je vais essayer de faire un petit casse-brique. Pour l'insatnat, je me
content d'afficher plusieurs balles qui rebondissent sur 4 murs. Mais
j'éhsite sur la façon de l'implémenter:

1/ faire un thread pour chaque balle. A l'intèrieur de chaque thread,
prévoir une fonction qui déssine la balle à l'écran.
Problèmes:
- dessiner une balle va effacer toutes les autres je pense.
- comment partager le même "graphics" entre les thread? D'habitude, sans
thread, je surcharge la méthode paint(Graphics g). Mais comment faire
dans chque thread?

2/ faire un thread pour chaque balle + un thread (ou timer?) pour
dessiner chaque ball. paint(Graphics g) ressemblera à ça:
ball1.draw(g);
ball2.draw(g);
ball3.draw(g);
...

ou bien utiliser des variables de chque thread:
g.draw(ball1.x, ball1.y, ...);
g.draw(ball2.x, ball2.y, ...);
g.draw(ball3.x, ball3.y, ...);
...

-est-ce posssible: puis-je un appel externe à une fonction d'un thread
quand celui-ci est en exécution?

La méthode 2 me semble la plus simple.

Un avis/conseil?

Merci
Julien

10 réponses

1 2
Avatar
KiLVaiDeN
"julien" wrote in message
news:41886ca5$0$32016$
Bonjour
Je vais essayer de faire un petit casse-brique. Pour l'insatnat, je me
content d'afficher plusieurs balles qui rebondissent sur 4 murs. Mais
j'éhsite sur la façon de l'implémenter:

1/ faire un thread pour chaque balle. A l'intèrieur de chaque thread,
prévoir une fonction qui déssine la balle à l'écran.
Problèmes:
- dessiner une balle va effacer toutes les autres je pense.
- comment partager le même "graphics" entre les thread? D'habitude, sans
thread, je surcharge la méthode paint(Graphics g). Mais comment faire
dans chque thread?

2/ faire un thread pour chaque balle + un thread (ou timer?) pour
dessiner chaque ball. paint(Graphics g) ressemblera à ça:
ball1.draw(g);
ball2.draw(g);
ball3.draw(g);
...

ou bien utiliser des variables de chque thread:
g.draw(ball1.x, ball1.y, ...);
g.draw(ball2.x, ball2.y, ...);
g.draw(ball3.x, ball3.y, ...);
...

-est-ce posssible: puis-je un appel externe à une fonction d'un thread
quand celui-ci est en exécution?

La méthode 2 me semble la plus simple.

Un avis/conseil?

Merci
Julien


La méthode 2 parait plus logique, en fait, tu devrais avoir un thread par
balle, puis un thread contrôleur pour l'affichage, éventuellement un autre
thread pour le score par exemple ? à voir, bonne chance !

K

Avatar
Laurent Bossavit
Julien,

Un avis/conseil?


Sauf si c'est spécifiquement un exercice pour apprendre à quel point la
programmation multithread en Java fais souffrir, je me contenterais d'un
seul thread.

Laurent

Avatar
jocelyn
Je suis entierement d'accord avec Laurent !
Dans ton jeu les balles ne devraient etre que des objets
possédant un état et gérés par un modèle de jeu. A intervalles
réguliers, tu lis ce modèle de jeu et tu génères un affichage en
conséquence. Bon mon truc est tres succinct et pas forcément
clair :)
Donc je te file une tres bonne adresse si tu lis anglais:
http://fivedots.coe.psu.ac.th/~ad/jg/

Tous ceux qui s'interessent a la prog de jeux en Java devraient lire ca
d'ailleurs !

--
Celui qui lutte contre des monstres doit prendre garde, dans le combat, à ne
pas devenir un monstre lui-même
Avatar
kpdpbis
julien wrote in message news:<41886ca5$0$32016$...
Bonjour
Je vais essayer de faire un petit casse-brique. Pour l'insatnat, je me
content d'afficher plusieurs balles qui rebondissent sur 4 murs. Mais
j'éhsite sur la façon de l'implémenter:

1/ faire un thread pour chaque balle. A l'intèrieur de chaque thread,
prévoir une fonction qui déssine la balle à l'écran.
Problèmes:
- dessiner une balle va effacer toutes les autres je pense.
- comment partager le même "graphics" entre les thread? D'habitude, sans
thread, je surcharge la méthode paint(Graphics g). Mais comment faire
dans chque thread?

2/ faire un thread pour chaque balle + un thread (ou timer?) pour
dessiner chaque ball. paint(Graphics g) ressemblera à ça:
ball1.draw(g);
ball2.draw(g);
ball3.draw(g);
...

ou bien utiliser des variables de chque thread:
g.draw(ball1.x, ball1.y, ...);
g.draw(ball2.x, ball2.y, ...);
g.draw(ball3.x, ball3.y, ...);
...

-est-ce posssible: puis-je un appel externe à une fonction d'un thread
quand celui-ci est en exécution?

La méthode 2 me semble la plus simple.

Un avis/conseil?

Merci
Julien


Bonsoir,

Pourquoi ne pas faire un MVC ? ;-) ( Plus facile à dire qu'à faire ? )

En fait, tu as tes x threads de traitements qui calculent les
coordonnées de tes objets. Je ne vais pas rentrer dans le détail mais
c'est "naif" de faire un thread par objet. ( Mais bon ça ne change
rien pour la suite. )

Arrive ensuite un élément important de la chaine : La FIFO. Quand un
thread a calculé la nouvelle coordonnée, il l'insère dans une FIFO (
L'insertion doit être synchronisée )

A l'autre bout du tuyau, tu as le thread du controller qui sur boucle
le déplilage synchronizé de la FIFO et qui update le modèle. L'aspect
trés important du pattern est que le modèle est updaté en monothread !
C'est beaucoup plus facile à gérer.

Evidemment ;-) l'update du modèle provoque par une relation
observer/observable le réveil de l'objet graphique ( la Vue ) qui
recoit la liste des nouvelles coordonnées. Sur la syntaxe, c'est
g.draw(ball1.x, .. ). Pourquoi ? Parce que la balle est un objet
métier. Ce n'est pas à elle de savoir se dessiner. C'est à un objet de
la vue de le faire. Dans le même ordre d'idée, il est inconcevable que
la balle implemente Runnable ;-) C'est à un objet de traitement
délégué de le faire.

En théorie tu devais consacrer un thread au rafraichissement
graphique, c'est un peu choquant que ce soit le thread du controller
qui rafraichisse vraiment. Avec Swing tu ferai un invokeLater(), le
thread graphique étant un thread à part. Un autre intéret est que cela
te permet de définir proprement ta fréquence de rafraichissement : Ton
thread graphique utilise effectivement un timer pour se rafraichir
toutes les x ms.

Et voilà ! Bon courage !

Comme je passe rarement j'en profite pour féciliter Jérome Molère pour
son livre sur J2EE avec une question : Pourquoi JBoss et pas Jonas ?

kpdp

Avatar
Vincent YSMAL
"julien" a écrit dans le message de news:
41886ca5$0$32016$
Bonjour
Je vais essayer de faire un petit casse-brique. Pour l'insatnat, je me
content d'afficher plusieurs balles qui rebondissent sur 4 murs. Mais
j'éhsite sur la façon de l'implémenter:

1/ faire un thread pour chaque balle. A l'intèrieur de chaque thread,
prévoir une fonction qui déssine la balle à l'écran.
Problèmes:
- dessiner une balle va effacer toutes les autres je pense.
- comment partager le même "graphics" entre les thread? D'habitude, sans
thread, je surcharge la méthode paint(Graphics g). Mais comment faire dans
chque thread?

2/ faire un thread pour chaque balle + un thread (ou timer?) pour dessiner
chaque ball. paint(Graphics g) ressemblera à ça:
ball1.draw(g);
ball2.draw(g);
ball3.draw(g);
...

ou bien utiliser des variables de chque thread:
g.draw(ball1.x, ball1.y, ...);
g.draw(ball2.x, ball2.y, ...);
g.draw(ball3.x, ball3.y, ...);
...

-est-ce posssible: puis-je un appel externe à une fonction d'un thread
quand celui-ci est en exécution?

La méthode 2 me semble la plus simple.

Un avis/conseil?

Merci
Julien
Bonjour,

m'on avis personnel sur la question, est quand règle général, lorsque je
programme des jeux, je n'utilise pas de thread ....
Pour la simple et bonne raison, que l'on est pas sur du timing.
Je préfère une boucle (sans fin), ou je calcule le temps ecoulé (temps pris
par la machine pour calculer les déplacement précédents et les afficher)
entre deux boucles, puis je calcule le déplacement des entités par rapport
à leur vitesse, les entrées claviers ou autre, et ensuite je calcul
l'affichage, et j'affiche.

Je ne dis pas que ma méthode est la meilleure, mais elle a cet avantage, que
je maitrise le déplacement de mes objets, ils se déplacements "tous" en
même, mais différement selon leur vitesse.

Voila, j'éspère avoir aidé.

Avatar
julien
julien wrote:
Bonjour
Je vais essayer de faire un petit casse-brique. Pour l'insatnat, je me
content d'afficher plusieurs balles qui rebondissent sur 4 murs. Mais
j'éhsite sur la façon de l'implémenter:


Merci à tous. Il va me falloir un peu de temps pour digérer toutes ces
répondes, certains commentaires me surprennent.

Julien

Avatar
Vincent YSMAL
"julien" a écrit dans le message de news:
418b0f17$0$5412$
julien wrote:
Bonjour
Je vais essayer de faire un petit casse-brique. Pour l'insatnat, je me
content d'afficher plusieurs balles qui rebondissent sur 4 murs. Mais
j'éhsite sur la façon de l'implémenter:


Merci à tous. Il va me falloir un peu de temps pour digérer toutes ces
répondes, certains commentaires me surprennent.

Julien


Juste par curiosité, quels sont les commentaires qui te suprennent .... ?


Avatar
KiLVaiDeN
"Vincent YSMAL" wrote in message
news:418bac75$0$19818$

"julien" a écrit dans le message de news:
418b0f17$0$5412$
julien wrote:
Bonjour
Je vais essayer de faire un petit casse-brique. Pour l'insatnat, je me
content d'afficher plusieurs balles qui rebondissent sur 4 murs. Mais
j'éhsite sur la façon de l'implémenter:


Merci à tous. Il va me falloir un peu de temps pour digérer toutes ces
répondes, certains commentaires me surprennent.

Julien


Juste par curiosité, quels sont les commentaires qui te suprennent .... ?




Je me posais la même question, en général on apprend chacun de nos
expériences, Julien si tu pouvais donner plus de détails par rapport à ce
qui te surprend ça pourrait peut-être nous donner une piste de remise en
question.

K



Avatar
julien
Juste par curiosité, quels sont les commentaires qui te suprennent .... ?


De Laurent Bossavit: un seul thread serait mieux
->gérer le balles, puis les briques, + d'autres objet avec un seul
thread, ça me parait plus compliqués que de faire des threads "indépendants"

De kpdp: c'est "naif" de faire un thread par objet
->bon, ça va peut-être dans le sens du message au-dessus

utiliser un FIFO
->je vois pas trop pourquoi: l'affichage devra se faire en une seule
fois en fonction des coordonnées/états des différents objets à l'instant t

Parce que la balle est un objet métier. Ce n'est pas à elle de savoir se
dessiner
->faut que je vois ce que veut dire "objet métier"
->je pense qu'il est plus facile de demander à chaque objet de se
dessiner. Il devrait avoir intrasèquement toutes les données pour se
dessiner lui-même.

Certaines personnes sont pour 2 seul thread unique, kdpd au contraire
pour multiplier le nombre de threads.

Julien

Avatar
KiLVaiDeN
"julien" wrote in message
news:418c6462$0$30957$
Juste par curiosité, quels sont les commentaires qui te suprennent ....
?



De Laurent Bossavit: un seul thread serait mieux
->gérer le balles, puis les briques, + d'autres objet avec un seul
thread, ça me parait plus compliqués que de faire des threads
"indépendants"


De kpdp: c'est "naif" de faire un thread par objet
->bon, ça va peut-être dans le sens du message au-dessus

utiliser un FIFO
->je vois pas trop pourquoi: l'affichage devra se faire en une seule
fois en fonction des coordonnées/états des différents objets à l'instant t

Parce que la balle est un objet métier. Ce n'est pas à elle de savoir se
dessiner
->faut que je vois ce que veut dire "objet métier"
->je pense qu'il est plus facile de demander à chaque objet de se
dessiner. Il devrait avoir intrasèquement toutes les données pour se
dessiner lui-même.

Certaines personnes sont pour 2 seul thread unique, kdpd au contraire
pour multiplier le nombre de threads.

Julien


Si tu suis une bonne logique d'architecture, ton objet ne doit fournir que
des services métiers, "se dessiner" n'est pas un service métier de la balle,
c'est la classe qui implémentera l'espace graphique qui en aura la charge.

K


1 2