Discussion :

[Chen norris]

Je me suis mis aux threads avec la SDL en suivant la FAQ de developpez.com. J'ai une classe qui gère l'intégralité du fonctionnement de mon application, et dont le rôle est de lancer des threads :

Code :

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

1
2
3
4
5
6
7
 
threadClavier = SDL_CreateThread(&THREAD_CLAVIER::foncThreadClavier, &clavier);
threadEcran = SDL_CreateThread(&THREAD_ECRAN::foncThreadEcran, &ecran);
 
// Attente de la fin des threads
SDL_WaitThread(threadClavier, NULL);
SDL_WaitThread(threadEcran, NULL);

En parallèle, il y a 2 classes (THREAD_ECRAN et THREAD_CLAVIER) qui contiennent chacune une fonction statique pour le déroulement du thread.

THREAD_ECRAN.cpp

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
 
class THREAD_ECRAN {
	public:
		static int foncThreadEcran(void *data) {
			// Conversion du paramètre en type ECRAN
			ECRAN *ecran = (ECRAN*)data;
			bool erreur;
 
			erreur = ecran->afficher();
 
			while(!erreur) {
				// rien ici pour l'instant...
			}
 
			return 0;
		}
};

THREAD_CLAVIER.cpp

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
 
class THREAD_CLAVIER {
	public:
		static int foncThreadClavier(void *data) {
			// Conversion du paramètre en type CLAVIER
			CLAVIER *clavier = (CLAVIER*)data;
 
			SDL_Event event;
			string fonctionLancee;
			bool continuer = true;
 
			while (continuer) {
				SDL_WaitEvent(&event);
				switch(event.type) {
					case SDL_KEYDOWN :	fonctionLancee = clavier->action(event.key.keysym.sym);
								continuer = false;
								break;
					case SDL_QUIT :		continuer = false;
				}
			}
			MessageBox (NULL, "Thread clavier quitté", "Info", MB_OK | MB_ICONINFORMATION);
 
			return 0;
		}
};

Bien entendu, mes classes ECRAN et CLAVIER ont bien été écrites et testées : aucun problème de ce côté-là.

Mon problème est le suivant : l'écran fonctionne très bien, mais le clavier ne semble pas recevoir d'événement puisque quelle que soit la touche clavier pressée, aucun message d'information n'apparaît (la ligne MessageBox de THREAD_CLAVIER.cpp n'est donc pas atteinte).

Je me suis demandé si ça venait de l'utilisation de SDL_WaitEvent, mais même en utilisant SDL_Poll_event, aucun événement clavier ne semble intercepté.

Une idée ?

PS : je travaille sous Dev C++ 4.9.9.2.

[fearyourself]

Bonjour,

Faire un thread pour le clavier me semble pas une bonne idée. Tu dois avoir une seule boucle pour tes événements et tu es en train de les séparer. Que feras-tu par exemple, lorsque tu vas vouloir gérer la souris ?

Ceci ne répond pas vraiment au problème mais bon...
Jc

[Chen norris]

Je pensais effectivement créer un autre thread pour la souris, un 4ème pour un éventuel joystick, ... Je me suis lancé dans les threads en me disant que gérer clavier, souris, écran, ... dans une même fonction risquait de poser des problèmes quant à la variation de vitesse d'exécution du programme. Imaginons que l'appui sur une touche du clavier déclenche un traitement beaucoup plus important que le déplacement de la souris : les itérations de la boucle des événements n'auront plus la même durée d'exécution, non ?

J'avais trouvé un tuto SDL qui permettait de gérer plus ou moins cette histoire de vitesse d'exécution en passant par du SDL_Delay, mais je me suis dit qu'avec des threads, ce serait sans doute moins complexe...

[fearyourself]

Je pensais effectivement créer un autre thread pour la souris, un 4ème pour un éventuel joystick, ... Je me suis lancé dans les threads en me disant que gérer clavier, souris, écran, ... dans une même fonction risquait de poser des problèmes quand à la variation de vitesse d'exécution du programme. Imaginons que l'appui sur une touche du clavier déclenche un traitement beaucoup plus important que le déplacement de la souris : les itérations de la boucle des événements n'auront plus la même durée d'exécution, non ?

Si tu veux faire les choses très proprement, alors il faudrait avoir un thread maître (celui de base) qui vérifie les événements et après signale au thread concerné qu'un traitement est nécessaire.

Le plus simple est une liste chaînée des éléments à traiter avec un mutex qui le protége.

Jc

[Chen norris]

Si je reprends ton idée, le thread maître correspondrait donc à mon programme principal (celui qui crée les threads esclaves). La liste chaînée contiendrait quoi exactement ? Des objets communs aux threads esclaves ?

Autre question : dans ce cas de figure, est-ce que écran, clavier, ... sont créés au niveau des threads, ou est-ce le programme principal qui passe des handles de périphériques déjà déclarés lors de la création des threads ?

[fearyourself]

Si je reprends ton idée, le thread maître correspondrait donc à mon programme principal (celui qui crée les threads esclaves). La liste chaînée contiendrait quoi exactement ? Des objets communs aux threads esclaves ?

Autre question : dans ce cas de figure, est-ce que écran, clavier, ... sont créés au niveau des threads, ou est-ce le programme principal qui passe des handles de périphériques déjà déclarés lors de la création des threads ?

J'aurais vu ceci :

Thread principale :

- Creation des threads auxiliaires (Ecran, Clavier)

- Boucle infinie avec un SDL_PollEvent
Si événement clavier, ajouter à la liste liste_clavier un noeud contenant l'information sur la touche appuyée.

- Boucle auxiliaire clavier :
Parcours de la liste chainée liste_clavier
Pour chaque élément dans la liste, gérer l'événement et enlever le noeud.

Ceci permet de garder les événements séparés, si la gestion d'un événement clavier est long, cela ne ralentira pas l'événement souris par exemple, etc.

Bien sûr, la première question est : As-tu vraiment besoin de ceci ? Un programme sans thread fonctionne généralement très bien

Jc

[Chen norris]

OK. Je crois que j'ai pigé le concept.
Pour ce qui est de vraiment mettre ceci en place, non, c'est loin d'être indispensable. Mon but était surtout d'avoir un programme le plus propre possible Je vais donc revenir sur des concepts plus simples comme l'utilisation de SDL_Delay, ... pour garder une bonne gestion du temps et je ne m'attaquerai au threads qu'en cas de gros besoin.

Merci pour les solutions que tu m'as apportées...