Discussion :

[Amokrane]

Bonsoir,
Après une longue durée d'inactivité en programmation , je me suis attaqué à la programmation d'un jeu d'echec , j'ai voulu dans un premier temps écrire la routine d'affichage de l'echiquier mais ça bug déjà .

1/ Problème de logique touchant le dessin même de l'échiquier
2/ Problèmes de scintillements ( Apparement je n'ai pas trouvé la bonne méthode pour optimiser mon affichage )

Concernant le 1 :
Voici la partie du code qui nous interresse :

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
31
32
33
34
35
36
 
void CHEchiquier::dessinerEchiquier()
{
 
	glBegin(GL_QUADS);
	for(unsigned int i=1;i<=64;i++)
	{
		if(i!=8 || i!=16 || i != 32 || i != 64) coordCurrent = i%8; 
		if((i==8) || (i== 16) || (i==32) || (i==64))
		{
			coordCurrent = 8;
			cury += ce_sizeTile;
			cury %= 400; // 400 = 8*50
		}
		// Pour l'alternance des couleurs
		if((i>=1 && i<=8)||(i>=17 && i<=24)||(i>=33 && i<=40)||(i>=49 && i<=56)) couleur = coordCurrent%2;
		if((i>=9 && i<=16)||(i>=24 && i<=32)|| (i>=41 && i<=48) || (i>=57 && i<=64))
		{
			if((coordCurrent%2)==0) couleur = 1;
			else if((coordCurrent%2) == 1)
				couleur = 0;
		}
		glColor3ub(ce_clr[couleur].composanteRouge,ce_clr[couleur].composanteVerte,ce_clr[couleur].composanteBleue); 
		glVertex2i(ce_originEchiquierX+(coordCurrent-1)*ce_sizeTile,ce_originEchiquierY+cury);
		glVertex2i(ce_originEchiquierX+(coordCurrent-1)*ce_sizeTile,ce_originEchiquierY+cury+ce_sizeTile);
		glVertex2i(ce_originEchiquierX+coordCurrent*ce_sizeTile,ce_originEchiquierY+cury+ce_sizeTile);
		glVertex2i(ce_originEchiquierX+coordCurrent*ce_sizeTile,ce_originEchiquierY+cury);
 
		cout<<cury<<endl;
 
	}
	glEnd();
	WasEchiquierDraw = true;
 
 
}

Non seulement , l'alternance des couleurs n'est pas comme souhaitée mais en plus j'obtiens une éspèce de colonne grise et blanche tt à gauche que je ne m'explique pas oO !

Pour le 2 , si je laisse le glClear(GL_COLOR_BUFFER_BIT); , l'affichage devient horrible ça scintille !
Que faut t'il faire ?
-Dessiner l'échiquier une seule fois ? Non ,car il sera effacé
-Mettre en place une sorte de timer ?
ou il est juste question d'une erreur bête de programmation ?

Le code source entier est dans le rar en pièce jointe il ya les fichiers suivants :

Main.cpp
CHEchiquier.h
CHEchiquier.cpp
CHPiece.h
CHPiece.cpp

Merci à vous , de vouloir bien m'aider

[Cheps]

Pour le problème se scintillement, est-ce que tu utilises le double buffering?
Désolé, pas trop le temps de me plonger dans ton code

[Amokrane]

Voilà la partie , relative au DB :

Code :

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

1
2
3
4
5
6
7
8
9
 
while(running)
	{
		Display(&Echiquier);
		controle();
		glfwSwapBuffers();
		running = !glfwGetKey(GLFW_KEY_ESC) && glfwGetWindowParam(GLFW_OPENED);
 
	}

Maintenant ai je placé le swap là ou il devait être ? Faut il procéder autrement ?

Merci qd même Cheps

[Cheps]

Non y'a pas de problème de le mettre là, c'était juste histoire d'être sûr que tu utilisais pas du single buffering.

Sinon ta boucle qui détermine la couleur me semble bien compliquée. Plutôt que de faire une boucle sur les 64 cases, tu devrais avoir deux boucles, une sur les 8 lignes et l'autre sur les 8 colonnes.

[Amokrane]

T'as pas tort !
ça va rendre les choses moins compliqués et ya de fortes chances que le problème de logique s'en aille !
Reste le scintillement .... ?

[plegat]

Sinon ta boucle qui détermine la couleur me semble bien compliquée. Plutôt que de faire une boucle sur les 64 cases, tu devrais avoir deux boucles, une sur les 8 lignes et l'autre sur les 8 colonnes.

Encore plus simple, sans boucle:

couleur=(i+partie entière((i-1)/8) modulo 2

Je vous laisse convertir, le C++ n'est pas mon fort!

De même:

Code :

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

1
2
3
4
5
6
7
8
 
if(i!=8 || i!=16 || i != 32 || i != 64) coordCurrent = i%8; 
if((i==8) || (i== 16) || (i==32) || (i==64))
{
	coordCurrent = 8;
	cury += ce_sizeTile;
	cury %= 400; // 400 = 8*50
}

à remplacer par (pas besoin de gros tests inutiles...):

Code :

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

1
2
3
4
 
coordCurrent = (i-1)%8+1;
cury += ce_sizeTile;
cury %= 400; // 400 = 8*50

Pour le scintillement, aucune idée... A part...
Essaye de sortir ta boucle du glBegin... glEnd, je crois me souvenir qu'il vaut mieux simplifier au maximum à des opérations OpenGl ce qui se trouve entre glBegin et glEnd. Tu gardes ta boucle, mais déplaces glBegin et glEnd pour encadrer uniquement le bloc:

Code :

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

1
2
3
4
5
glColor3ub(ce_clr[couleur].composanteRouge,ce_clr[couleur].composanteVerte,ce_clr[couleur].composanteBleue);
glVertex2i(ce_originEchiquierX+(coordCurrent-1)*ce_sizeTile,ce_originEchiquierY+cury);
glVertex2i(ce_originEchiquierX+(coordCurrent-1)*ce_sizeTile,ce_originEchiquierY+cury+ce_sizeTile);
glVertex2i(ce_originEchiquierX+coordCurrent*ce_sizeTile,ce_originEchiquierY+cury+ce_sizeTile);
glVertex2i(ce_originEchiquierX+coordCurrent*ce_sizeTile,ce_originEchiquierY+cury);

[Cheps]

Encore plus simple, sans boucle:

Oui mais il est obligé de boucler pour dessiner les 64 cases de toute façon. Il boucle sur les lignes et colonnes, et à chaque fois il détermine la couleur du quad selon i et j avant de le dessiner.

Essaye de sortir ta boucle du glBegin... glEnd, je crois me souvenir qu'il vaut mieux simplifier au maximum à des opérations OpenGl ce qui se trouve entre glBegin et glEnd. Tu gardes ta boucle, mais déplaces glBegin et glEnd pour encadrer uniquement le bloc:

Si tu suggères qu'il mette le glBegin et glEnd à l'intérieur de la boucle, c'est une très très très mauvaise idée. Déclarer une fois 64 quads est bien plus performant que déclarer 64 fois un quad.

[plegat]

Oui mais il est obligé de boucler pour dessiner les 64 cases de toute façon. Il boucle sur les lignes et colonnes, et à chaque fois il détermine la couleur du quad selon i et j avant de le dessiner.

Je ne vois pas l'intérêt de boucler sur les lignes et les colonnes alors qu'il peut déterminer la couleur directement à partir de la valeur de son indice i.
A moins de vouloir perdre un peu de cycles CPU...
Là, on économise 64 itérations... c'est peanuts, mais vu que ça ne sert à rien, autant simplifier.

Si tu suggères qu'il mette le glBegin et glEnd à l'intérieur de la boucle, c'est une très très très mauvaise idée.

C'était une proposition.
Vu qu'il insère des traitements numériques dans sa boucle glBegin/glEnd, ça peut jouer (j'ai bien précisé "je crois me souvenir" dans ma phrase... je ne suis pas encore graveur sur marbre!)
Cela dit, recalculer les positions et les couleurs des cases de l'échiquier à chaque fois qu'on veut l'afficher, c'est loin d'être optimisé...
Il vaudrait mieux s'orienter vers un tableau calculé dès le départ avec position de la case, couleur, et toute autre propriété utile... ou mettre tout ça dans une DisplayList au départ, que l'on rappelle pour l'affichage ensuite.

Déclarer une fois 64 quads est bien plus performant que déclarer 64 fois un quad.

Euh... avec mes 15000 triangles, quad, tetra, hexa, je sens pas trop la différence sur mon appli... mais c'est vrai que je calcule les propriétés de mes objets avant de les afficher.

Et puis bon, à la limite, peut-être qu'il préfèrera avoir un truc un peu plus lent qui ne scintille pas, qu'un truc qui booste et qui flashe!

[Cheps]

Je ne vois pas l'intérêt de boucler sur les lignes et les colonnes alors qu'il peut déterminer la couleur directement à partir de la valeur de son indice i.
A moins de vouloir perdre un peu de cycles CPU...
Là, on économise 64 itérations... c'est peanuts, mais vu que ça ne sert à rien, autant simplifier.

L'intérêt c'est que de toute façon il doit boucler pour construire les vertex des quads, autant inclure la détermination de la couleur dans la boucle:

for(int i = 0; i < 8; i++)
for(int j = 0; j < 8; j++)
{
glColor3f(...)
glVertex3f(...)
glVertex3f(...)
glVertex3f(...)
glVertex3f(...)
}

Bien sûr il vaudrait mieux utiliser des vertex array ou VBO, mais pour un jeu d'échec et pour apprendre, le mode direct c'est pas si mal

Cela dit, recalculer les positions et les couleurs des cases de l'échiquier à chaque fois qu'on veut l'afficher, c'est loin d'être optimisé...
Il vaudrait mieux s'orienter vers un tableau calculé dès le départ avec position de la case, couleur, et toute autre propriété utile... ou mettre tout ça dans une DisplayList au départ, que l'on rappelle pour l'affichage ensuite.

C'est gagner quelques calculs en perdant un peu de mémoire, mais je pense pas que pour son jeu n'échec ça n'a d'influence

Euh... avec mes 15000 triangles, quad, tetra, hexa, je sens pas trop la différence sur mon appli... mais c'est vrai que je calcule les propriétés de mes objets avant de les afficher.

Oui car c'est une scène assez simple pour ton ordinateur. Mais pour simplifier, c'est un peu le même principe que 100 fichiers de 1MO sont plus lents à copier qu'un seul fichier de 100MO.

Pour en revenir au problème original, je pense qu'en structurant mieux son programme il peut se résoudre par lui-même. Ou sinon qu'il se manifeste

[plegat]

L'intérêt c'est que de toute façon il doit boucler pour construire les vertex des quads, autant inclure la détermination de la couleur dans la boucle:

Ben oui mais non, car il détermine la position du quad à partir de sa variable coordCurrent, qui est calculée à partir de la valeur du i de sa boucle globale.

En gros, soit on fait une seule boucle sur 64 cases, soit deux boucles sur 8 lignes et 8 colonnes. Mais il vaut mieux éviter de combiner les deux.

Bien sûr il vaudrait mieux utiliser des vertex array ou VBO, mais pour un jeu d'échec et pour apprendre, le mode direct c'est pas si mal

Je plussoie.

C'est gagner quelques calculs en perdant un peu de mémoire, mais je pense pas que pour son jeu n'échec ça n'a d'influence

Je plussoie aussi, mais autant en profiter pour lui faire remarquer, ça sera ça de gagné pour le jour où il voudra gagner un peu de temps sur sa méga-scène texturé et illuminée de partout!

Oui car c'est une scène assez simple pour ton ordinateur. Mais pour simplifier, c'est un peu le même principe que 100 fichiers de 1MO sont plus lents à copier qu'un seul fichier de 100MO.

Tu simplifies vraiment là!!!
Toutefois, juste pour préciser, ma remarque ne visait pas à remplacer un glBegin/glEnd sur 64 objets par 64 glBegin/glEnd sur un objet, mais à sortir les calculs numériques "complexes" de la structure glBegin/glEnd. Et je précise encore que c'est un "vague souvenir" d'optimisation qui m'a fait dire ça (et dès que j'arrive à remettre la main sur un papier qui explique ça, je le mets en lien... si il s'avère que mon vague souvenir était bien fondé, et que ce n'était pas une hallucination de mon esprit embrumé!)

Pour en revenir au problème original, je pense qu'en structurant mieux son programme il peut se résoudre par lui-même. Ou sinon qu'il se manifeste

Je te laisse le bébé alors, je me casse en week-end à la montagne!

[Amokrane]

Merci pour vos explications même si j'ai finalement réussi à régler le problème tout seul .
Je n'ai pas touché mon swap , j'ai juste changé cette horrible boucle 64 , en deux boucles et là ça va bcp mieux .

Merci à vous pour ce débat fort instructîf ^^