Discussion :

[Pill_S]

Bonjour a tous,

je ne suis pas certain d'être sur le bon forum, mais bon allez je me lance.
J'aurais une question de conception:

je suis sur un jeu du serpent (en java mais on s'en fout). Je souhaiterais utiliser des threads afin d'arriver à une plus grande régularité dans les déplacements du serpent.

Pour l'instant, voilà où j'en suis : Applet jeu du serpent


Ma question est:
1) est-ce bien en utilisant des threads que je vais arriver à stabiliser les déplacement du reptile ?
2) si oui, auriez vous une idée de la structure à leur donner ? Par exemple, un thread qui réaffiche, un qui déplace le serpent, etc... ?


Merci de vos réponses !

[Selenite]

Je ne vois pas en quoi les thread pourrait accroitre la régularité de l'animation.


Tu as principalement deux manière de faire fonctionner ton jeu. Aucune des deux ne nécessite des thread pour être homogène.


1. Tu gère tout avec des entiers. Toutes les X ms, tu appelle une fonction qui lit déplace le serpent, qui vérifie si la tête du serpent n'est pas sur une pomme, qui éventuellement replace une nouvelle pomme... Le jeu en sera pas fluide uniquement si ladite fonction est parfois plus longue à l'éxécution que X ms.


2. Tu gère tout avec des flotant. La fonction principale est la même sauf que tu la rapelle dès qu'elle est achevé. Dans la fonction, tu gère tous en fonction du temps écoulé depuis le calcul de la dernière image.
Exemple: positionX += vitesse * tempsEcoulé
Avec cette méthode ton jeu est aussi fluide si l'ordinateur est assez puissant. Mais ton taux d'image pas seconde est variable. Par exemple quand tu prendra une pomme, le temps d'exécution de la fonction sera plus longue et ton frame rate chutera. Mais c'est variation de frame rate seront imperceptible pour un serpent.

[Pill_S]

Je ne vois pas en quoi les thread pourrait accroitre la régularité de l'animation.

bin moi non plus, mais je me suis dit que ça pourrait aider, de fractionner les tâches...

Toutes les X ms, tu appelle une fonction qui lit déplace le serpent, qui vérifie si la tête du serpent n'est pas sur une pomme, qui éventuellement replace une nouvelle pomme... Le jeu en sera pas fluide uniquement si ladite fonction est parfois plus longue à l'éxécution que X ms.

bin justement, c'est mon cas, je tourne dans une boucle qui me fait les déplacements, les réaffichages et les tests (placer une nouvelle pomme, agrandir le serpent, etc...)

Tu admettras que le jeu n'est guère jouable pour l'instant, car les variations de vitesse sont penibles... Moi je cherche un moyen d'améliorer

[Selenite]

Est-ce que tu appelle ta fonction à intervalle régulier ?
Si tu ne fais pas ça, c'est comme si tu appliquais la deuxième méthode mais sans prndre en compte les variation du temps d'éxécution.

PS: je ne peut pas voir ton applet. Je en sais pas pourquoi, je en peux pas voir les applet Java sur mon PC. Il faudra que j'élucide ça...

[Pill_S]

non, en effet, je ne prend pas en compte les variations... je me contente d'attendre X ms entre chaque cycle... tu crois que ça pourrait venir de ça ?

comment faire alors ? faut-il relever le clock horloge, et attendre le bon nombre de cycles machines pour réguler la vitesse ? (ça ne me semble pas être génial...)

[Selenite]

Bien sur que ça vient de ça.

A chaque appelle de la fonction, le serpent avance de 1. Or il est inévitable que la fonction prend plus ou moins de temps pour s'éxécuter. La vitesse du serpent va donc varier. De plus, plus la machine est puissante, plus le serpent ira vite, ce que est inacceptable.

Je te renvoie à mon premier post dans ce topic pour plus de détails sur les méthodes à utiliser.


Je en connais pas JAVA mais il doit surement y avoir une fonction qui en appelle une autre à intervalles réguliers.

[mat.M]

Blawk a parfaitement raison un thread n'est pas vraiment fait pour cela .

Cette technique particuliere de programmation est utilisé parfois à tort et à travers ;
Il faut comprendre ce qui se passe lors de l'exécution d'un programme multi-processus : le CPU multitâche alloue un espace temps ( quantum) pour chaque tâche , ceci à travers une gestion de l'OS.
Pour un thread avec Java c'est d'une manière ou d'une autre l'OS qui va gérer cela.
Donc à chaque quantum à intervalles réguliers , le code du Thread sera exécuté.
Et la programmation multiprocessus c'est parfait pour des tâches qui tournent dans le fond..

2) si oui, auriez vous une idée de la structure à leur donner ? Par exemple, un thread qui réaffiche, un qui déplace le serpent, etc... ?

Non pas du tout car cela risque d'être totalement désynchronisé.
Je pense que Blawk a donner la bonne marche a suivre .
Sinon si c'est avec Java il faut jouer avec un tampon mémoire genre double-affichage c.a.d. une technique classique des jeux vidéos.

[Pill_S]

Blawk a parfaitement raison un thread n'est pas vraiment fait pour cela .

Cette technique particuliere de programmation est utilisé parfois à tort et à travers ;

possible, en tout cas je n'en ai jamais servi, et c'est pour cette raison que je voulais 2-3 précisions.

Maintenant je comprend un peu mieux leur principes: les threads sont utilisés pour effectuer des tâches bien spécifiques, sans rapport les unes par rapport aux autres

Merci pour vos conseils. Je vais creuser du côté du double-buffering (même si il me semble qu'il soit déjà implémenté dans les composants swing de java)...

[davcha]

Les threads ne sont pas forcément utilisés pour réaliser des tâches sans aucun rapport les uns avec les autres. Sinon on aurait pas inventé les tubes et les sémaphores.

[Cyr1c]

les threads sont surtout utilisé qd tu as deux traitements parallèles !

il faut savoir que synchroniser deux threads coute beaucoup en traitement!

A mon avis, une simple boucle suffirait pour ton problème !
le mieux serait d'avoir un buffer et de temporiser l'affichage.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
delay = xx;
dernierTps = 0;
boucle infini()
{
 
   lire clavier()
   si(Now() - dernierTps > delay)
   {
     buffer = creerImageSerpent();
     afficher(buffer)
     dernierTps = Now();
   }
}

c'est juste une indication, tu peux largement améliorer, mais l'idée est là.

[bafman]

perso je ferait plutot :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
boucle_infini()
{
     elapsedTime = now() - previousTime;
     previousTime = now();
     position = position + increment*elapsedTime;
     affichage();
}

le temps est compte en ms par exemple
avec increment = la distance que doit parcourir le serpent en 1 seconde
comme ca si l'affichage prend 3s alors la position sera incrementé de 3*increment.
par contre si l'affichage prend 1/1000s la position lors de l'affichage ne sera incrementé que de 1/1000 d'increment.
c'est la technique qui est utilisé dans tout les jeux "time based" ou la synchronisation sur le temp est importante.

par contre ca implique un autre probleme : les collisions.
en effet si la tête du serpent est à 1 pixel du mur et qu'a ce moment la ca rame pendant 3 seconde, la tête se retrouvera à 30 pixel apres le mur (si la tête avance de 10pixel par seconde) et la le test de collision ne marchera plus...
il y a une methode assez simple a mettre en oeuvre pour y remedier c'est qu'a chaque image tu parcourt l'ensemble des position situé entre la position precedente et la position courante pour tester les collisions.

[Pill_S]

je comprend mieux maintenant toutes les implications...

cela change complètement mes idées de départ, à savoir une grille de taille statique et un serpent qui se déplace de case en case... (+10px à chaque déplacement)

en tout cas merci de ces précisions, mais ça va pas être facile à coder... je crois que je vais me rabattre sur un jeu du solitaire ou un jeu d'échecs, où l'animation n'a pas une grande importance...

[slim]

les threads sont surtout utilisé qd tu as deux traitements parallèles !
il faut savoir que synchroniser deux threads coute beaucoup en traitement!

Je crois que les threads sont TOUJOURS utilisés, quand il y a deux traitements parallele certes, mais le multi-traitement est présent dans tous les systemes d'exploitation actuels, je pense, et il est transparent pour l'utilisateur. La synchronisation est tellement rapide que l'on ne s'en rend pas compte. Mais ca depend, bien entendu des performances de la machine.
Les threads sont des portions de processus, et un processus est assimilé à une application, qu'elle soit en arriere ou au premier plan !