Discussion :

[RedSkidy]

enfaite il en faudrais un pour les boutons et un pour l'utilisateur qui veut créer son jeu comme par exemple pour déplacer les personnages

[skeud]

Mouais, en fait l'idéal serait que tu me dise ce que tu es en train de faire pour que je puisse te guider comme il faut .

[RedSkidy]

toujours la même chose j'ai threadé le WidgetManager qui dans une boucle fait un SDL_WaitEvent puis qui l'envoie aux boutons (une boucle parcours une liste de boutons et appelle leur méthode check(event)
et pendant ce temps dans le main il y a un SDL_PollEvent puis les evenement sont gérés (pour l'instant il n'y a que la fermeture de la fenetre avec la croix ou echap) mais là c'est comme si je ne traitait aucun event

[skeud]

tu ne dois pas utilisé deux parties de ton code qui attendes des événement. Le widgetManager était un exemple, dans ton cas, tu as besoin d'un windowManager, qui va intercepter tout les evenement et les transmettre aux bonnes personnes.

Bref: Ne jamais avoir deux ligne de codes dans ton projet contenant WaitEvent ou PollEvent, tu dois choisir l'un ou l'autre, et n'avoir qu'une seule ligne exclusive partout dans ton code. Ensuite, à toi d'adapter ta conception pour pouvoir faire ce que tu veux.

Mes conseils pour le weekend:
Pose tes idées sur un papier.
Renseigne toi sur la gestion des evenement SDL.
Regarde certain moteur de widget comment il fonctionne (j'entends par la mettre le nez dans le code de ces moteur) CEGUI est un tres bon exemple.
Et surtout, réfléchis, ne perdrais-tu pas moins de temps à apprendre à utiliser un moteur tout fait plutot que faire le tiens? (ne me sors pas l'excuse des performances blahblahblah, on me l'a fait trois fois aujourd'hui ).

Avec ça tu devrais etre bien occupé jusqu'a lundi que je revienne.

En passant, normalement, tu ne devrais avoir qu'un thread, si tu as besoin de deux thread, c'est que ta conception n'est pas correct. (on utilise des thread lorsqu'on a une opération bloquante ou par soucis d'optimisation, optimisation qui se fait OBLIGATOIREMENT une fois que le projet est terminé). Et donc encore une fois, refait ta conception correctement, tu gagneras beaucoup de temps par la suite.

hs: t'es mouru leternel? A pu de message de toi depuis un moment ^^.

Sinon bon courage et à lundi

[RedSkidy]

si je veut faire mon propre moteur gui c'est pour l'entrainement (j'ai appris plein de choses) et aussi pour avoir un moteur simple a utiliser et spécialement conçu pour ce dont j'ai besoin et pour les jeux (par exemple choisir facilement un son ou une image a lier au bouton).
je vais peut-être le distribuer sa peut toujours servir ou au moins le passer a des gens que je connais et peut-être le réutiliser dans d'autres programmes, donc il faut qu'on puisse coder le projet comme un programme SDL normal avec juste un include et une création de widget pour l'utiliser, je pense que le windowManager serait un peut contraignant pour les utilisateurs.

sinon a lundi

[skeud]

Le window manager est obligatoire si tu veux récupéré les éléments, à la fois dans ton code et dans le code des widgets.

Dis moi ce que tu veux faire (non pas d'un point de vue gui, mais d'un point de vue projet) que je puisse t'aider à le concevoir .

[RedSkidy]

enfaite je voudrais faire une sorte de mini extension gui de la SDL qui puisse etre utilisée sans ddevoir faire de gros changements dans le code

[skeud]

D'accord, est-ce que tu veux que ce process se fasse dans un thread ou pas?

L'application qui va utiliser ta minigui doit-elle avoir accès aux évènement de la SDL?

[RedSkidy]

puis-ce qu'il faut que le programme soit utilisable comme un programme SDL normal, oui il faudras avoir accès aux évènements SDL et oui la gestiondes widgets seras threadée (grace au WidgetManager)
et c'est bien ça le problème : ces deux choses sont incompatibles

[skeud]

Sisi, en féisant un peu de conception, ça se fait simplement, et pas besoin de threader comme tu veux utiliser les événement.

Voici comment je vois les choses :

L'application (qui utilise ta lib gui) possède la boucle d'évènement de la SDL (le poll_event, ou autre fonction pour récupérer les evenement).
Immédiatement après, passe la structure à ta lib (via le WidgetManager)
Le WidgetManager utilise les meme fonctions qu'a l'heure actuel pour mettre à jour les widget, faire les callback etc......
Le WidgetManager rend la main à ton application ce qui lui permet de traiter elle aussi l'evenement.

ça te va comme fonctionnement? de cette manière, pas de thread (il faut sérieusemment les évité ceux-la, ils sont dangereux).

[RedSkidy]

oui mais comment récupérer les events du main sans avoir une fonction du style sendEvent(event) dans le main ?
et puis l'utilisateur n'auras pas forcement de gestion des events (et il peut aussi utiliser une autre bibliothèque si il n'aime pas la gestion d'event de la SDL)
et pourquoi les threds sont dangereux ?
ce n'est pas directement du multithreading sur processeur (là oui j'ai entendu parler de trucs comme le deadlock) c'est juste un deuxième processus
EDIT : je me demandais si c'était possible de redéfinir une fonction pour que quand on appelle SDL_PollEvent(&event) ça appelle une copie de cette fonction que j'aurais fait pour fonctionner avec ma lib plutot que la fonction de la SDL

[skeud]

oui mais comment récupérer les events du main sans avoir une fonction du style sendEvent(event) dans le main ?

Via la méthode dont je te parlais, ce n'est pas le main qui récupère les event de ta lib mais ta lib qui récupère les event via le main (le main fait un poll_event de SDL puis passe la structure event à ta lib)

et puis l'utilisateur n'auras pas forcement de gestion des events (et il peut aussi utiliser une autre bibliothèque si il n'aime pas la gestion d'event de la SDL)

L'utilisateur, si il utilise ta lib devra forcément utiliser la SDL, tu ne peux pas avoir deux lib graphiques qui affichent sur la même fenêtre (en pratique c'est faux, mais à ton niveau, considère que c'est impossible).

et pourquoi les threads sont dangereux ?
ce n'est pas directement du multithreading sur processeur (là oui j'ai entendu parler de trucs comme le deadlock) c'est juste un deuxième processus

Dans ton cas, tu veux faire du multi-threading avec variable partager, donc ça entraine mutex, et qui dis mutex dis dead lock . C'est un risque avec les thread, donc moins on les utilise, mieux c'est.
Tu peux les utiliser sur des micro-traitement qui ne partage aucune variable (envois via les socket, enregistrement de configuration, calcul simple). Donc:
Soit toute la partie graphique dans un thread et toute la partie traitement dans un autre (en les fesant communiqué par un sémaphore ou un pipe -> notion avancé de programmation).
Soit un seul thread (notion simple de programmation).

[RedSkidy]

admettons que l'utilisateur n'utilise que la SDL et qu'il y ait forcément un poll event dans le main.
le main ressembleras à ça :

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
int main(argc*, argv**)
{
     //initialisation SDL + variables
     SDL_Event event;
     button bouton(...);
     while(!finish)
     {
          SDL_PollEvent(&event);
          sendEvents(event);
          //gestion des events
          //trucs
     }   
     //fermeture
     return 0;
}

il faudrais enlever la fonction sendevent parce-que c'est pas très pratique

[skeud]

ça ressemblerait plutot à ça:

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
int main(argc*, argv**)
{
     //initialisation SDL + variables
     SDL_Event event;
     button bouton(...);
     while(!finish)
     {
          SDL_PollEvent(&event);
          // J'ai modifié ici:
          WidgetManager::getInstance()->sendEvend(event);
          //gestion des events
          //trucs
     }   
     //fermeture
     return 0;
}

il faudrais enlever la fonction sendevent parce-que c'est pas très pratique

C'est la seul solution viable que tu pourrait avoir, de cette manière, le fonctionnement des widget est transparent, et c'est ce que tu voulais.
La ligne

Code :

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

WidgetManager::getInstance()->sendEvend(event);

Est la seul ligne d'interaction avec ta lib (hormis la création des widget). Fonctionnement simple, pas de thread, et transparent pour l'utilisateur, je vois pas de meilleur solution .

[RedSkidy]

par exemple avec Qt il suffit de créer un bouton et de le connecter je voulais que ça marche de la même façon

[skeud]

Sauf qu'avec Qt tu ne dessine pas toi-même sur la fenêtre et tu ne gères pas toi-même les événements :p

Si ensuite tu veux faire ces fonctionnalités, alors je t'aiderais mais sache que tu sors complètement d'un cadre de gestion "simple", car il faudra stocker les évenement, créer une widget qui permette à l'utilisateur de dessiner à l'ecran en appelant une fonction etc ....... Donc beaucoup plus compliqué .

La solution que je te propose est celle qui est la plus simple, et qui colle le plus à ce que tu demandes .

Ensuite si tu veux un truc mieux, forcément, il faudra faire plus compliqué, dans toute ta vie tu auras ce schéma:

Je fais quelque chose avec peu de fonctionnalité <-------------------------------------> quelque chose avec plein de fonctionnalité/sexy
Peu de temps à faire <-------------------------------------> beaucoup de temps à faire
Simple à réalisé <-------------------------------------> Difficile à réaliser
Je réinvente pas la roue <--------------------------------------> Je réinvente la roue
J'ai pas besoin de grosse connaissance <--------------------------------------> J'ai besoin de beaucoup de connaissance
C'est réutilisable par les autres <--------------------------------------> Ce n'est pas réutilisable par les autres (d'une manière générale)

Edit: La mise en page du schéma est pourri, mais pas trouvé comment faire, puis bon c'est l'heure de partir du boulot .

[RedSkidy]

ok je pense que je vais utiliser ta fonction mais on peut pas utiliser une macro ? parce-que
WidgetManager::getInstance()->sendEvend(event);
est un peu barbare
EDIT : je viens de découvrir la fonction SDL_GetMouseState je pense que ça pourrait bien résoudre le problème d'évent
EDIT 2 : ha non enfaite il faut un SDL_PumpEvent() avant

[skeud]

Ce n'est pas barbare, mettre une macro pour réduire la taille, ça c'est barbare, au moins à la lecture du code on sait exactement ce que fais cette ligne, c'est le mieux. Puis l'utilisateur de ta lib n'aura pas à mettre cette ligne partout, donc ce n'est pas compliqué pour lui. Puis lorsque tu seras habitué aux singleton, tu verra que ce genre d'écriture est très fréquente .

Les macro, on les utilise lorsqu'on a des opération peu parlante à faire ou alors répété (comme basculé trois int en un seul pour changer les couleur ):

Code :

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

1
2
#define RGB(r, g, b) (((r&0xFF)<<0x1000)+((g&0xFF)<<0x100)+(b&0xFF))
int color = RGB(0xFF, 0x00, 0xFF);

C'est quand meme plus simple que d'écrire la longue ligne qui nous dis absolument pas ce qu'elle fait dans tout le code .

[RedSkidy]

enfaite c'est surtout que c'est plus simple a retenir de mettre SEND(event)

[skeud]

D'accord mais comment en lisant cette ligne, un développeur (X ou Y) ne connaissant pas ta lib, sauras que cette ligne envois le événement à ton moteur gui? :p