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?
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
"julien" <julien@sobrier.net> wrote in message
news:41886ca5$0$32016$636a15ce@news.free.fr...
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 !
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
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
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.
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
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
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
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
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
julien <julien@sobrier.net> wrote in message news:<41886ca5$0$32016$636a15ce@news.free.fr>...
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 ?
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
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é.
"julien" <julien@sobrier.net> a écrit dans le message de news:
41886ca5$0$32016$636a15ce@news.free.fr...
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.
"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é.
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
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.
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
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 .... ?
"julien" <julien@sobrier.net> a écrit dans le message de news:
418b0f17$0$5412$636a15ce@news.free.fr...
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 .... ?
"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 .... ?
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
"Vincent YSMAL" <vincent.ysmal@laposte.net> wrote in message
news:418bac75$0$19818$626a14ce@news.free.fr...
"julien" <julien@sobrier.net> a écrit dans le message de news:
418b0f17$0$5412$636a15ce@news.free.fr...
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.
"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
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
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.
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
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
"julien" <julien@sobrier.net> wrote in message
news:418c6462$0$30957$636a15ce@news.free.fr...
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.
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.