Messages

31

Fenêtrage / Re : Gérer plusieurs fenêtres

« le: Mai 06, 2013, 06:40:12 pm »

Bon en effet ça fonctionne. Par contre quelle est l'utilité de WaitEvent par rapport à PollEvent ? WaitEvent attend un événement, donc utile si on a rien à rafraîchir, rien du CPU n'est utilisé. Mais dans ce cas là, cela ne permet pas de gérer plusieurs fenêtres si une seule et unique boucle est utilisée. Dans quel cas se révèle-t-il alors utile ?


Sinon pour revenir sur le sujet, c'est bien comme tu me dis si c'est codé en dur. Mais si je crée un programme permettant avec un simple bouton de créer une fenêtre (par exemple), comment l'inclure dans la boucle alors pour qu'elle puisse réagir à des événements (ou tout simplement quelle puisse afficher quelque chose en particulier) ? Parce que codé en dur c'est simple, mais de façon dynamique y doit bien y avoir un moyen non ?

32

Fenêtrage / Re : Gérer plusieurs fenêtres

« le: Mai 06, 2013, 06:08:21 pm »

Ah bon ? Comment tu sais ça ? Tu as regardé le code source de Gimp ?

Gimp utilise GTK, je doute qu'il modifie à la volée son propre code pour inclure dans la même boucle les différentes fenêtres, hors comme pour Qt je doute qu'ils puissent prévoir le nombre de fenêtres à afficher. Qt a résolu d'ailleurs le soucis en créant leur propre système d'évènement avec les Qt::Connect.


Si je gère tout dans la même boucle en prenant ton exemple, si je ferme une des deux fenêtres la boucle ne s'exécute plus puisqu'un des membres de test de la dite boucle ne renvoi plus true mais false. Il faudrait dans ce cas là une boucle while sans fin, mais alors comment l'interrompre pour quitter le programme ? Avec un break ou un return en plein milieu ? Le problème de la boucle infinie c'est que le programme sera toujours à 100 % non ?

Pourquoi ? Tant que ton propre code ne dit pas de fermer les autres lorsqu'une est fermée, cela ne se produira pas. Je te l'ai dit, la condition qui stoppe la boucle principale, tu y mets ce que tu veux. Si c'est "boucler tant que la fenêtre principale est ouverte" plutôt que "bloquer tant que toutes les fenêtres sont ouvertes", et bien pas de souci, tu peux le faire aussi... C'est ton programme, tu codes ce que tu veux.

Je ne l'avais pas compris comme cela lol, dans ce cas je peux éventuellement mettre une simple variable comme condition au lieu de l'habituel isOpen, variable qui passe à false si les conditions de fermeture du programme sont réunis.

Je vais voir ça de suite.


Oui je crois que je me pose beaucoup trop de question lol.

33

Fenêtrage / Re : Gérer plusieurs fenêtres

« le: Mai 06, 2013, 01:25:42 pm »

Bon je viens de faire des essais, je crée les fenêtres dans le main et les boucles sont mises dans des thread séparés. Les fenêtres s'affichent, mais elles sont incapables de répondre par contre.

Le problème est que je ne peux fournir le sf::Window en paramètre de la fonction pour le thread, si je met un &sf::Window comme argument, il m'envoi baladé en disant que ça ne va pas avec un retour void. Et en mettant les fenêtres en tan que variables globales, ça démarre mais les fenêtres plantes.

Donc je ne vois pas comment faire autrement que faire la création au sein du même thread que celui qui gère la boucle de la fenêtre en question.

34

Général / Re : [SFML2] Compilation avec CMake

« le: Mai 06, 2013, 01:02:15 pm »

Ben j'ai au départ essayé celle pour DW2 puis SJLJ et les deux j'avais le soucis, ce qui n'est maintenant plus le cas après recompilation donc je me suis dit que le soucis devait venir de là. Je verrais ce soir à la maison sur la version de Codeblocks que j'ai (10.5 pas mis à jour encore ) si j'ai aussi un problème ou non et je testerais en le mettant à jour pour voir.

Peut être que le problème était lié au fait que c'est sur clé USB va savoir


Pour la path ben désolé j'avais pas vu lol, cela dit j'aurais été alors obligé de mettre le path puis le supprimer ensuite ou alors le mettre en console et démarrer cmake-gui en console. Bref je le saurais pour la prochaine fois, le fait est qu'au final tout fonctionne

35

Fenêtrage / Re : Gérer plusieurs fenêtres

« le: Mai 06, 2013, 12:13:54 pm »

J'y ai pensé à ta solution, mais imagine un programme où depuis la fenêtre principale, tu en crée une autre avec un bouton, il faut bien une boucle séparée pour les deux.


Pour Mac, les programmes comme Gimp font comment alors ? Puisque chaque fenêtre à sa propre boucle. Si on met une boucle commune, cela veut dire que fermer une fenêtre les fermes toutes. Gimp par exemple te permet de toute les fermer sauf la fenêtre principale qui elle fermera toute les autres, donc à un moment donné il doit y avoir une séparation des boucles non ?

Après je prend Gimp comme exemple, mais c'est en fait GTK qui est concerné et c'est pareil pour Qt d'ailleurs

Ou autre solution, les fenêtres en question sont créer dans le thread principal, mais les boucles sont dans des threads séparés. Tu penses que ça peut marcher ? Fournir un argument à la fonction du thread : l'instance ici de sf::Window.

Je verrais pour tester cet aprem car là je vais aller manger, sinon je testerais ce soir en arrivant à la maison. Parce que, que tout soit dans le même thread j'ai alors du mal à comprendre comment Qt/GTK font, à moins qu'ils crées la fenêtre dans le thread principal mais gère la boucle dans un thread séparé.


Je sais je me pose des questions que sans doute personne s'est posé ici mais bon, je suis fan du dessin animé CodeLyoko et j'ai toujours voulut reproduire le pupitre du SuperCalculateur ; du coup plusieurs fenêtres c'est ce qu'il faudrait. Et puis ça ouvre de nouvelles perspectives d'utilisation que de pouvoir le faire sans trop de pertes en performance.

36

Graphique / Re : Les Vues??

« le: Mai 06, 2013, 12:02:06 pm »

Bonjour Gorf,

De ce que j'en ai compris (reprend moi Laurent si je me plante), les vues te permettent le déplacement de ta scène, la rotation ainsi que le zoom.

En effet, sur une map mettons de 1600x1200 avec une fenêtre 800x600, tu as une map deux fois plus grande. Certains et c'été le cas en SDL 1.2 (la nouvelle  je ne sais honnêtement pas comment elle gère), il fallait alors afficher les 800x600 pixels de ta map et au bon moment affiché les 800x600 autres pixels (en gros hein ).

Là, sur la SFML2 (et 1.6 fait pareil je crois), tu affiches 1600x1200 mais ta fenêtre faisant que 800x600, tu n'auras que cette première partie. Au bon moment, tu te contente de simplement déplacer la vue sur les 800x600 pixels restant.

La fenêtre est en deux parties :
- Rendu théorique
- Rendu pratique

Le rendu théorique correspond à ta map : 1600x1200. Ta fenêtre SFML a cette information de rendu et toi tu y gères ce qui s'y passe quoi qu'il arrive, donc toute ta map est chargée (au contraire de SDL1.2 où tu ne charges que le visuel).

Le rendu pratique, correspond à ce que ta fenêtre affiche : 800x600. C'est donc ce que Laurent nous a appelé la vue. La vue est la partie de la fenêtre qui affiche.


Comme c'est ce qui affiche à l'écran, tu peux aussi faire une rotation ou un zoom de ce qui est affiché, mais derrière tu ne produit aucun calcul pour cela, c'est la vue qui s'en charge toute seule à l'affichage.

Pour exemple, tu as un personnage allant du point A à gauche à B à droite. Tu lui dit donc de se déplacer vers la droite, mais tu demandes à la vue de faire une rotation à 180°.

Visuellement tu auras donc le point B à gauche et A à droite. On se dit alors qu'on doit faire déplacer à gauche donc dans ce cas là et c'est vrai mais UNIQUEMENT avec la SDL1.2.
La tu as utilisé la vue, donc le rendu pratique. Le rendu théorique dit toujours : B est à droite de A, ton code fait donc déplacer à droite.

Le rendu pratique fait alors quoi ? Au moment du déplacement, il dit : "oui mais on m'a fait faire une rotation 180°, donc droite devient gauche", il va donc afficher un déplacement gauche et rejoindre le fameux point B comme prévu.



La comparaison est celle-ci : tu fais un code pour une chose standard, ici déplacement à droite. La vue est ce qui est affiché et ne dépend pas de ton code, les changements visuels à faire ne seront donc pas dépendant de ce que tu as codé derrière mais dépendant des instructions que tu as donné à la vue en question.

J'espère t'avoir un peu plus éclairé.

P.S. : Ma comparaison avec la SDL1.2 est  pour mieux expliquer le fait que tu n'as pas à changer ton code comme on pourrait le croire (et serait obligé de faire en SDL1.2 qui ne gère pas les vues), il suffit d'utiliser les vues qui s'occupent de traduire l'ordre donné afin d'afficher visuellement ce que tu as demandé indépendamment de ton code.

37

Fenêtrage / Gérer plusieurs fenêtres

« le: Mai 06, 2013, 11:48:01 am »

Bonjour,

Je me demandais si certains avait une méthode fiable pour gérer 2 (ou plus) fenêtres SFML. Vu qu'il faut une boucle testant d'ailleurs si la fenêtre est ouverte, je me suis toujours dit que ce n'été pas possible.

Hors à force d'y réfléchir, j'ai pensé à un truc : c'est le cas de l'API Win32, Cocoa pour Mac et X11 pour Linux ; pourtant cela n'empêche pas que certains programment ont plusieurs fenêtres affichées en même temps et qui sont interactive.

J'ai donc fait des tests, je peux afficher deux fenêtres, mais la seconde ne sera interactif qu'une fois la première boucle finie donc la première fenêtre fermée.


J'ai donc fait un nouveau test : chaque fenêtre est dans une fonction et j'utilise un thread par fenêtre. Les deux fenêtres sont alors réactives et fonctionnent parfaitement.

Ma question est alors la suivante : est-ce que sur un système mono-CPU, cela ne risque pas de faire perdre en performance le fait d'avoir plusieurs thread sur le programme juste pour gérer des fenêtres de rendus ?

Laurent, as-tu une meilleur solution que celle-ci ?


Merci d'avance pour la réponse.

38

Général / Re : [SFML2] Compilation avec CMake

« le: Mai 06, 2013, 11:38:53 am »

Bonjour Laurent,

C'est bon j'ai résolu le soucis. En fait quand je voulais lancer un programme SFML compilé au boulot, il refusait en renvoyant une erreur de point d'entrée dans libstdc++-6.dll.
En cherchant sur le net, ils disaient que c'est la version gcc qui correspond pas ; en effet tu as compilé en 4.7 et je suis en 4.7.1 avec la dernière version de codeblocks.

Pour CMAKE_MAKE_PROGRAM oui je l'ai compris après, j'ai donc pu le lui fournir et c'est bon tout marche nickel, SFML2 est compilée et plus d'erreurs de libstdc++-6.dll


Pour l'emplacement compilateur, faut savoir que rien n'est installé au boulot, j'ai tout sur clé USB donc je ne pouvais pas lui dire de prendre nativement sur le système j'ai donc remplis les trois cases : gcc, g++ et fortran comme demandé, mais il avait pas demandé pour make et j'ai pas réagit de suite


Je te rappel, rien installer par morceaux, j'utilise la version mingw fournie de codeblocks afin d'éviter cela, même si j'ai du séparé mingw de codeblocks sur ma clé USB (car comme je pouvais pas faire une vrai installation de codeblocks, j'utilise le programme cameyo qui crée une sorte de launcher, j'ai du mettre mingw à part du coup car rassemblé ça ne fonctionnait pas).


Bref tout est corrigé, plus de soucis. Ce n'est pas comme si de la maison j'avais pas du compiler (avec CMake) SFML2 sous Linux (les dépôts Ubuntu fournissent encore la 1.6 hélas).

39

Général / [SFML2] Compilation avec CMake

« le: Mai 06, 2013, 10:41:03 am »

Bonjour,

J'essai depuis 10 minutes au boulot de compiler (sous windows 7) la SFML2 avec CMake. Hélas j'ai ceci comme erreur :

CMake Error: CMake was unable to find a build program corresponding to "MinGW Makefiles".  CMAKE_MAKE_PROGRAM is not set.  You probably need to select a different build tool.
CMake Error: CMake was unable to find a build program corresponding to "MinGW Makefiles".  CMAKE_MAKE_PROGRAM is not set.  You probably need to select a different build tool.
CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly.
Missing variable is:
CMAKE_C_COMPILER_ENV_VAR
CMake Error: Could not find cmake module file:C:/Users/tertiaire33/Downloads/SFML-2.0-build/CMakeFiles/2.8.10.2/CMakeCCompiler.cmake
CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly.
Missing variable is:
CMAKE_CXX_COMPILER_ENV_VAR
CMake Error: Could not find cmake module file:C:/Users/tertiaire33/Downloads/SFML-2.0-build/CMakeFiles/2.8.10.2/CMakeCXXCompiler.cmake
Configuring incomplete, errors occurred!

Et je ne comprend pas comment corriger le problème. J'ai bien choisis Mingw Makefiles, j'ai bien indiqué l'emplacement du compilateur (qui est présent sur ma clé USB) ; bref j'ai fait ce qu'indique le tuto.

Je ne comprend pas surtout ce qu'est ce CMAKE_MAKE_PROGRAM qu'il semble réclamer.


Merci d'avance pour l'aide.

40

Graphique / Re : [SFML 2.0] Vitesse de déplacement variable au lieu de constante...

« le: Mars 28, 2013, 10:28:34 am »

Coucou,

J'ai hélas pas eu le temps hier soir de concocter mon exemple. Cependant sur mon compte google drive j'ai retrouvé un exemple que j'avais fait : http://www.mirorii.com/x98ldwcxvbbu/sprites-2013-03-28_Mirorii.com.zip (prend n'importe quel lien de téléchargement proposé par mirorii).

L'exemple est complet : code source, DLL et exécutable pour tester.

41

Général / Re : La protection des données est-elle réelement nécéssaire ?

« le: Mars 28, 2013, 10:16:05 am »

Il faut voir aussi que plus on sécurise, plus on attire les pirates qui vont de toute façon réutiliser et cracker illégalement ton jeu.

Il est gratuit  ? T'embête donc pas, au pire comme dit Laurent, tu zippes et basta ou crée ton format d'archive (compressé ou non au choix, avec la zlib tu peux compresser sans créer un fichier, du coup tu peux compresser et mettre dans ton propre format), 99 % des petits curieux pourront rien faire.

Mais bon ce faire ***** je ne trouve pas ça utile. Après ça peut te permettre d'apprendre comment est conçus un format de fichier ce qui n'est qu'un plus dans l'apprentissage.

42

Général / Re : SFML2 pour Dreamcast ?

« le: Mars 28, 2013, 10:11:52 am »

Le problème des anciennes consoles aussi c'est le langage de programmation. Par exemple pour GameBoy, il faut obligatoirement faire de l'assembleur, pour GameBoy Advance tu as le C++ mais il faut compilé pour de l'ARM (la lib standard n'existe pas non plus). Bref c'est assez complexe.

43

Graphique / Re : [SFML 2.0] Vitesse de déplacement variable au lieu de constante...

« le: Mars 27, 2013, 09:02:27 am »

Je pense que le soucis est ailleurs, en effet tu te sers d'un timer (sf::clock) dans ta condition. Tu n'en n'as pas besoin.
Normalement, dans ta condition tu regardes si la touche est pressée, si oui alors tu appels ta méthode de "déplacement" du sprite. Là aucune condition, tu te contentes de faire un move sur les nouvelles coordonnées.

Là ton erreur c'est que ton move dépend du temps, en clair plus ta machine est rapide plus ça va vite au niveau de l'animation.

Là je suis au boulot, ce soir je te fais un petit exemple.

44

Projets SFML / Re : MyMapEditor

« le: Mars 27, 2013, 08:53:18 am »

Bonjour Antho,

Ton programme semble chouette, je le testerais ce soir en rentrant du boulot. Cela dit si ça bogue dans des cas "hors normalité" d'utilisation, il te faudrait faire les corrections quand même

45

Graphique / Re : Afficher un sprite

« le: Novembre 11, 2012, 06:55:12 pm »

Bon là je ne comprend plus rien. Je viens de tester en en mettant 3, les trois s'affichent. Si je les retires et que j'en ai laisse qu'un, ça s'affiche aussi alors que quand j'ai posté, ce n'était pas le cas un seul ça fonctionnait pas.

Et là je viens à l'instant sans rien toucher au code, de lancer le programme pour l'exposé (le début donc de code pour refaire mario sokoban), et ça s'affiche.

J'y comprend plus rien du tout, j'ai du avoir un bogue de windows ou de la carte graphique.

Du coup finalement j'aurais pu le faire le mario sokoban pour l'exposé, hélas j'ai peu de plus avoir le temps. Dommage, bref finalement je t'ai dérangé pour rien lol.