Discussion :

[Seiya]

Vivent les threads ! Là j'ai un beau scrolling fluide, bien plus agréable qu'avant, avec possibilté de faire varier la vitesse facilement (marche ou course).

Je soumets ma technique à validation d'experts :

J'ai créé 2 threads :
- un qui dessine
- un qui augmente la coordonnée y (pour l'instant on ne peut que monter !)

Je les lance comme ça :

Code :

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

1
2
3
4
5
6
7
8
 
Affichage affichage = new Affichage();
affichage.setPriority(Thread.MAX_PRIORITY);
affichage.start();
 
Marche marche = new Marche();
marche.setPriority(Thread.MAX_PRIORITY);
marche.start();

C'est conseillé la priorité MAX ? pour les deux ??

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
 
	public class Affichage extends Thread {
 
		public void run() {
			while(!quitter) {
				afficheEcranJeu();
				try {
					Thread.sleep(1000/24);
				} catch (InterruptedException e) {
					e.printStackTrace();
				}
			}
		}
	}
 
 
	public class Marche extends Thread {
 
		public void run() {
			while(!quitter) {
				if(marche)
					pix_y++;
				try {
					Thread.sleep(1000/48);		// changer la fréquence pour varier la vitesse 
				} catch (InterruptedException e) {
					e.printStackTrace();
				}
			}
		}
	}

on keyPressed : marche = true
on keyReleased : marche = false

[narkotik]

tu vois le multithread c'est top 8)
le mieux c'est un thread avec priorité minimale pour le rafraichissement graphique, étant donné que tu n'es pas a quelques FPS prets et ca permet de garder la priorité pour que les animations des sprites soient toujours nickel
a part ca t'as l'air d'avoir tout compris pour l'indépendance des physiques des objets dans un jeu, à toi de continuer

[Glob]

Code :

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

1
2
3
4
5
6
7
8
9
init() 
while(not quit) { 
  mesureTempsEcouléDepuisDernièreBoucle 
  traiteTouches() 
  bougeObjets/événementsDuMonde // (en fonction du temps écoulé) 
  dessineMonde() 
  dessineObjets() 
  attendre10ms() // pour éviter un CPU à 100%, pas très élégant :mrgreen: 
}

loin de moi l'idée de vouloir critiquer, mais ce thread, je suppose que sa vitesse de rafraichissement (10ms ici) c'est pour les mouvements du héros, ok, mais les ennemis, et autres éléments du monde, ils sont calqués sur le meme système de mouvements ??? honnetement je doute

Non, c'est pas pour les mouvements du héros. C'est pour
1) recalculer les positions/états des objets du monde (perso + montres + etc)
2) afficher une vue, un état du monde à un moment précis. On affiche tout ce qui est visible en fonction de l'endroit de la caméra.

attendre10ms() // pour éviter un CPU à 100%, pas très élégant

ah bah, et mon thread avec yield et setPriority(Thread.MIN_PRIORITY); c'est fait pour quoi a ton avis ?

yield et setPriority servent à gérer les priorités / exécutions des threads dans la JVM. En principe, pas d'incidence sur le CPU alloué à la JVM.

Ma question: pourquoi, systématiquement, vouloir faire des thread dans tous les coins? Je prétends qu'on peut faire un jeu sans faire de new Thread()...

le minimum pour un jeu a mon avis c'est 1 thread, celui du rafraichissement graphique (FPS), les autres qui dirigent le monde peuvent etre seulement des compteurs de temps ou l'utilisation de GageTimer (dll très très utilisées car précise et efficace)

Les DLL c'est chouette, mais c'est pas portable... Répète après moi: "Les DLL n'existent pas"
Je fais tout dans le même thread. Séquentiellement:
1) je dirige le monde (©BillGates)
2) j'affiche le monde
Y'a pas de raison que ça marche pas, au contraire, et en plus y'a pas de problèmes de synchro (1 seul thread), pas de risque de "tuer" un objet pendant qu'on le lit pour affichage... Et le CPU que tu utilises pour ordonnancer les thread, chez moi il est utilisé pour le jeu

Je me suis fait un "monde" d'environ 20'000 x 10'000 px, en dessinant à chaque fois toutes les tiles (optimisations niveau 0)... et bien ça scroll super fluide.

sur un p'tit pc, il doit souffrir, faut utiliser un systeme de viewport afin d'économiser un maximum la mémoire utilisée

Pas de soucis sur un p333 avec 96MB de RAM... j'ai rien de plus faible sous la main...

Bon, sinon, à chacun son truc, je pense pas qu'on puisse objectivement dire que l'une des deux philosophies (avec ou sans thread) est meilleure que l'autre...

Bien entendu, avec un seul Thread, y'a certains problèmes qu'il faut gérer différemment. Par exemple, change pas la position de ton perso à x=x+5 quand tant que la touche "droite" est enfoncée. Par contre, tu mets sa vitesse vX à 5 quand tu presses la touche, et tu la remets à zéro quand tu la lâche.
Quand on passe dans la partie "mise à jour du monde", on sait combien de temps s'est écoulé depuis la dernière MAJ, disons T, et du coup on peut calculer la nouvelle position du perso: x = x + t*vX.

Même chose pour les monstres, la partie AI décide où ils vont et change leur vitesse.

La partie affichage ajuste la caméra sur le perso et affiche les objets. Voilà...

[Glob]

ben moi je prétend que c'est faux de vouloir faire tourner le thread du main à l'infini. Le thread du main doit lancer un thread de dessin principal qui lui boucle à l'infini avec une condition d'arrêt. Cela permet au thread du main de garder le contrôle suprême sur l'exécution du programme. En tout cas à mon avis cette méthode est bien plus propre...

Je fais un while tout à fait normal, et dedans je teste un boolean qui indique pour savoir si, par exemple, l'utilisateur a pressé ESC... rien ne tourne à l'infini, en tous cas pas plus que dans les autres while que j'ai déjà rencontrés Et le thread "main" garde le contrôle suprême, puisque y'a que lui qui tourne

[Pascmar]

je viens de tester ta méthode, c'est vrai que ça marche bien, seulement, je me demande comment tu fait pour gérer les collisions parce que l'intérêt que je vois à la méthode des "multi-threads" est que comme chaque élément graphique est un objet indépendant, on lui donne un int pour sa position et il est facile de comparer les positions des threads entre-eux et de là, supprimer s'il le faut un des threads impliqués dans la collision. De plus il est assez pratique de gérer un vecteur ou une liste de threads, beaucoup plus qu'un seul qui fait tout. Mais autrement, c'est vrai que côté CPU, c'est pas vraiment la joie

[narkotik]

Code :

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

1
2
3
4
5
6
7
8
9
init() 
while(not quit) { 
  mesureTempsEcouléDepuisDernièreBoucle 
  traiteTouches() 
  bougeObjets/événementsDuMonde // (en fonction du temps écoulé) 
  dessineMonde() 
  dessineObjets() 
  attendre10ms() // pour éviter un CPU à 100%, pas très élégant :mrgreen: 
}

ce système est pas mal mais il comporte malheureusement un point faible, le mouvement n'est pas parfaitement fluide pour des déplacements a grande vitesse, j'm'explique:
le rafraichissement graphique est toute les 10ms:
si ton héros se déplace de 2pixels a chaque rafraichissement, c'est fluide ok
si ton héros se déplace de 100 pixels a chaque rafraichissement, c'est pu fluide du tout, ca va saccader
j'ai pris le cas du héros mais ca peut etre n'importe quoi, un astéroide, un monstre, un missile, une balle, qu'importe...

Les DLL c'est chouette, mais c'est pas portable... Répète après moi: "Les DLL n'existent pas"

La DLL GageTimer est super super connue lol, et il est aussi connue qu'elle existe pour la plateforme Unix
elle a été crée pour faire des jeux et palier le probleme de Java qui ne peut accéder aux nanosecondes (celui ci n'apparait qu'avec Java 1.5), il gere aussi les collisions, le Parallax Scrolling ( scrolling de différents plan à l'écran, style Mario Bros et autres), le Non-blocking sound effects mixer, il permet aussi de gérer la vitesse de keyboard pour récupérer les touches.

Y'a pas de raison que ça marche pas, au contraire, et en plus y'a pas de problèmes de synchro (1 seul thread), pas de risque de "tuer" un objet pendant qu'on le lit pour affichage...

c'est pour ca qu'il existe le mot clé synchronized, pour éviter d'utiliser une ressource en cours d'utilisation