Discussion :

[Zeil]

Bonjour à tous,


venant de terminer à grand peine la première étape de mon projet de jeu, je vais bientôt commencer à plancher sur la deuxième partie mais un problème de taille se pose: je n'ai jamais utilisé de moteurs graphiques.


Afin de vous permettre de me répondre en connaissance de cause, je vais brièvement exposer mon projet.



Il s'agit d'un RPG online temps réel, architecture client-serveur bien sur.
Actuellement l'implémentation est simple.

La connexion ne pose aucun problème et lancera une classe héritant de Thread appelée ConnexionThread qui lui-même lancera une classe héritant de JFrame appelée JeuFrame.

La JeuFrame est pourvue d'un gestionnaire de clavier (extends KeyListener) qui s'occupe de transformer les divers événements claviers en Msg devant être envoyés au serveur via le ConnexionThread.

Le ConnexionThread recoit fréquemment des informations de la part du serveur, qu'il envoit à la JeuFrame devant les gérer.

Ces événements sont de deux types:

* L'entrée ou le départ d'un autre personnage de votre zone de visibilité
* Un événement signifiant qu'un personnage (le votre ou un autre) se déplace en telle position



Jusque là, rien de bien sorcier donc.


Mais le problème est de taille lorsqu'on s'attache au comportement actuel de la JeuFrame, ou plus exactement du JeuPanel qu'elle contient.

En effet, ce JeuPanel (extends JPanel donc) recoit tous les événéments.
Il stocke et maitient à jour en permanence la description des personnages actuellement visible par le votre. (le détail est sans importance)

A chaque événement de déplacement d'un personnage, il agit de la sorte:
SOIT il s'agit de votre personnage
=> il met à jour ce qui est considéré comme le centre du panel, à savoir votre position et réaffiche tout (la map centrée en votre personnage, votre personnage et ceux qui lui sont visibles)
SOIT il s'agit d'un autre personnage
=> il fait pareil (je sais, j'aurais du faire en sorte de ne redessiner que la partie qu'il occupait avant et celle qu'il occupe actuellement)




Les événements de déplacements étant sensé être très fréquent (à la base, c'est quand même un jeu multi-joueur espérant se doter d'une panoplie de monstres mobiles), le nombre de réaffichage via la méthode repaint() est considérable.


J'ai un peu lu des documents sur le buffering, double buffering, sur la méthode update etc.... mais je sens qu'il ne s'agira que d'une améliration mineur et je pense vraiment que mon modèle actuel se prêterait facilement au couplage avec un moteur 2D (même si je n'y connais rien, j'ai comme un présentiment).


J'ai donc fait un petit tour sur google mais je n'y ai pas vraiment trouvé mon bonheur.


Je m'adresse donc à vous en espérant que vous pourrez me mettre sur la voie d'un moteur 2D (à la rigueur 3D mais beaucoup de complexité au service d'un gain de dimension non utilisé... :s) qui vous semblerez efficient.


J'espère ne pas avoir fait trop court ni trop long.
Merci à ceux qui m'auront lu

[bafman]

normalemen t avec java2D tu peut utiliser des GIF animé, ce qui permet de ne pas avoir à faire de repaint juste pour l'animation des perso, donc gain de vitesse d'affichage...

[Zeil]

Oui mais en ce qui concerne les déplacements, cela ne marche pas.

[loka]

comment geres tu tes deplacements ?

[FCDB]

Si tu as du scrolling horizontal ou vertical, il faut que tu réaffiches toute la fenêtre. Le plus simple est de faire une boucle qui réaffiche le contenu de la fenêtre réguliérement, toutes les 40ms par exemple. Si un joueur s'en va, sa "disparition" ne sera donc affichée qu'au prochain affichage soit environ 1/24 de seconde plus tard.

Je ne connais pas de moteur 2d mais la classe BufferStrategy gère pour toi le clipping et le double bufferring. Par contre, l'api SDL existe sous Java. Il y a sûrement beaucoup de tutos la concernant sur le net pour sa version en C.

Bon courage.

[Zeil]

Donc, je viens de prendre le coup de main avec BufferStrategy et tout le tralala.

Une autre question se pose, je vais donc modifier le titre.
ancien titre: Choix d'un moteur 2D pour programme Java
nouveau titre[Java]Solutions graphiques pour jeu temps réel


****************************************************************************

Voici de quoi comprendre la solution actuelle.

Le thread s'occupant de l'affichage possède : private Hashtable<String, PersoDesc> persosVisibles;
Il s'agit d'une liste de description de personnage (nom, position, état, ...) indexé par le nom (sorte de clé unique).

Il connait aussi la description du personnage que l'on représente: PersoDesc jeSuis.


Ces descriptions sont maintenues à jour bien sûr.

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
 
 
	private void renderingAvantPlan(Graphics2D g2)
	{
		Point centre = jeSuis.getPos();
		ArrayList<PersoDesc> lesDescs = new ArrayList<PersoDesc>(persosVisibles.values());
		for(int i=0;i<lesDescs.size();i++)
		{
			g2.drawImage(
					imgHandler.getImage(lesDescs.get(i)),
					(int)(lesDescs.get(i).getPos().getX()-centre.getX() + width/2),
					(int)(lesDescs.get(i).getPos().getY()-centre.getY()+ height/2 ),
					null
					);
		}
 
		g2.drawImage(
				imgHandler.getImage(jeSuis),
				width/2,
				height/2,
				null
				);
	}

imgHandler est une classe s'occupant de délivrer l'image correspondant à une description de personnage.

Pour l'instant, c'est assez minimaliste.

Code :

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

1
2
3
4
5
6
7
8
9
10
 
public Image getImage(PersoDesc desc)
	{
		if(desc.getEtat() instanceof EtatPersoBouge)
			return getImage("persoBouge");
		else if(desc.getEtat() instanceof EtatPersoAttend)
			return getImage("persoAttend");
		else
			return null;
	}

Je rappelle que l'on est informé pour chaque dépalcement atomique d'un personnage, ce qui reste néanmoins à l'écran un joli petit saut.

On voit donc les personnages qui se déplacent rester un petit temps (le temps entre deux déplacements en fait) sur une case et puis, BOUM, ils arrivent sur la suivante... et ainsi de suite, jusqu'à ce qu'ils ne se déplacent plus.

Auriez-vous une idée de solution peu gourmande?
Ne devrais pas plutot prévenir uniquement du "commencement" d'un déplacement dans une direction, du changement de direction d'un déplacement ou de son arrêt en laissant le client s'occuper lui-même de gérer les positions entre-temps (en lui envoyant tout de même les positions à certains moments pour "réajuster" les choses) ?

Voilà voilà... merci à tous

[Zeil]

Toujours sur le coup, l'animation est maintenant réalisée dans une classe appelée AnimationHandler.

L'information de mouvement d'un personnage n'update en effet plus sa position !
C'est l'AnimationHandler qui gèrent celà.

Elle dispose d'un timer qui la prévient à chaque 1/X de secondes (je fais par 200ms) de modifier légérement la position des persos qui bougent en fonction de la direction de leur déplacemement.


J'ai choisi le temps en même temps que la taille du déplacement atomique (côté serveur), du temps côté serveur etc pour que tout soit pile poil.

Pour plus de sécurité, un événement "Le perso X attend" update la position du personnage X.


Donc, ca devrait aller.... néanmoins.... il y a un léger "saut" juste avant que le personnage s'arrete et j'ai pu localiser le problème.µ.


A l'aide d'une classe Chrono créée à l'occasion avec un simple swing.Timer, j'ai un peu regardé le temps entre deux instructions, par-ci par-là...
Puis j'ai douté et j'ai testé ma classe Chrono: elle n'est pas précise.

=> Le problème de mon animation est le swing.Timer !

Connaissez-vous un moyen de faire un timer pour mes animations qui soit plus précis ?