Messages

16

Général / Re : [Erreur] iterateur prend valeur impossible

« le: Février 25, 2017, 11:27:01 pm »

Pas sûr mais peut-être que ce sont les conversions de float à int qui posent problème.
Je suppose également que tes attributs m_size.x et y sont des float.
Essaye sans conversion pour voir (float i et id).

17

Général / Re : Compilation sous Linux

« le: Février 23, 2017, 09:22:42 am »

Yep !

Mais c'est bon, moi qui suis habitué à CodeBlocks, j'ai pu me refaire un environnement de développement et de compilation sain avec ce logiciel. Parfaite auto-completion et reconnaissance des fonctions (types des arguments etc.) aussi bien de la STL que de la SFML.

J'ai juste installé un compilateur plus récent que celui de ma distro, recompilé wxWidgets et Codeblocks, et surtout supprimé les anciens fichiers de configuration de ce dernier. Et là pouf, magie !

Sinon effectivement j'utilise Vim et Geany de façon assez intensive pour tout ce qui n'est pas "projet de compilation C/C++".

18

Général / Re : Re : Re : Compilation sous Linux

« le: Février 21, 2017, 01:21:17 pm »

Ça m'intéresse , as tu des liens s'il te plaît?

http://www.commentcamarche.net/faq/17019-l-autocompletion-c-c-sous-vim

Cette page semble récente et à partir de là tu as des liens vers des plugins vim et vers le logiciel ctags, + des explications pour l'envoyer lire les includes des bibliothèques de ton choix.

19

Général / Re : Compilation sous Linux

« le: Février 19, 2017, 06:36:14 pm »

Yep yep, c'est bien GDB que j'utilisais déjà, graphiquement intégré à CodeBlocks.
Ce matin je l'ai d'ailleurs désinstallé et compilé la dernière version
Il y a également un tuto assez complet sur openclassrooms.
Merci pour la page Ubuntu, ça donne des infos aussi.

Mais je vais d'abord voir si le fait de compiler la dernière version de C::B ne règle pas mes problèmes.
Sinon j'ai déjà des onglets ouverts qui expliquent comment ajouter l'autocompletion de bibliothèques particulières à Vim

20

Général / Re : Compilation sous Linux

« le: Février 17, 2017, 01:47:41 pm »

Je te remercie de ta réponse !

Oui, j'avais simplement oublié de lier les bibliothèques avec les paramètres -lsfml-xxx lors de la compilation en ligne de commande. Maintenant je peux compiler et exécuter en ligne de commande sans soucis, j'ai même supprimé les variables d'environnement $LD_LIBRARY_PATH et $LD_RUN_PATH.

Il va falloir que j'apprenne à me servir correctement du débugger en ligne de commande je suppose. J'aimais bien son intégration dans CodeBlocks.

Dans CodeBlocks je ne peux toujours pas lancer un programme SFML, ça me fait toujours le même genre de petite erreur, malgré que je l'ai configuré autant que je le pouvais comme indiqué. Les autres programmes se compilent très bien, avec ou sans --std=c++11 dans CodeBlocks.

21

Général / [Résolu] Compilation sous Linux

« le: Février 16, 2017, 02:33:05 pm »

Bonjour !

Ça fait un bon moment que je suis passé au monde Linux, que j'apprécie beaucoup. Je commence à parler shell plus ou moins couramment, enfin, je me débrouille disons.

Mais je suis resté en dual boot sous Windows notamment car j'ai des soucis pour compiler / faire tourner mes programmes construits avec la SFML.

Après des heures de lectures afin de tenter de comprendre globalement comment tout cela fonctionne, je me tourne vers vous car vous allez voir, je crois que je ne suis pas loin de toucher au but. Il doit manquer un petit détail ou deux pour tout faire fonctionner correctement.

Je suis sous Mint (base Ubuntu donc). J'ai compilé GCC 5.4.0 et l'ai installé de façon globale (remplaçant donc GCC-4.8, je n'ai pas utilisé le système d'update-alternatives, j'ai complètement remplacé gcc-4.8 ).

J'ai compilé la SFML avec ce même compilateur. Et l'ai installé de manière globale sur le système.

J'ai configuré Code::Blocks et il compile les programmes SFML sans problème. L'auto-completion concernant la SFML fonctionne très bien également.

Par contre il ne lance pas les programmes SFML. Par exemple pour un programme de test tout simple il renvoie une erreur : "free(): invalid pointer".

Par contre j'ai exporté de manière globale les variables LD_LIBRARY_PATH et LD_RUN_PATH contenant le chemin vers /usr/local/include/SFML.
Ce qui me permet de lancer les programmes SFML en ligne de commande sans problème.
Alors que pour rappel, ils sont compilés avec C::B et je n'arrive pas à les compiler en ligne de commande (en ajoutant à tâtons -L /chemin/de/SFML).

Donc voilà, j'aimerais savoir ce que je dois faire :
- pour que CodeBlocks lance les programmes SFML
- optionnellement pouvoir compiler les programmes SFML en ligne de commande.

Si cela est possible, j'aimerais une solution globale, qui n'implique pas de rajouter des options sur la ligne de commande. Mais peut-être n'est-ce pas possible.

Je vous remercie pour votre lecture.

22

Réseau / Re : N'envoie que au dernier client qui l'a contacté.

« le: Février 03, 2017, 05:11:04 pm »

Cool
Est-ce que tu as découvert précisément quel était le problème, ou le ménage a résolu tout en gardant le mystère?

23

Réseau / Re : Résolution du problème d'endianness

« le: Février 03, 2017, 05:01:09 pm »

Ok merci, j'irai voir de plus près dans le code de sf::Packet. Merci pour la SFML, personnellement ça a été mon point d'entrée dans de nombreux domaines de la programmation. Et c'est du beau code. J'ai pas encore vu les sources de la dernière version, mais si j'ai bien compris c'est du C++11 maintenant. C'est classe

24

Réseau / Re : Résolution du problème d'endianness

« le: Février 03, 2017, 01:19:00 pm »

Ok merci !

Mais alors, pour être allé farfouillé dans le code de la fonction receive des socket TCP pour les sf::Packets, elle effectue un memcpy d'un seul coup si je me souviens bien. Cela permet-il cette résolution de différence d'endianness ? Il n'y aurait pas besoin d'inverser les octets sur une machine à l'endianness inverse ?

25

Réseau / Re : N'envoie que au dernier client qui l'a contacté.

« le: Février 03, 2017, 01:15:15 pm »

As-tu résolu le problème depuis ?

Si je comprends bien, tu utilises un socket UDP c'est bien ça ?
Je n'ai pas l'habitude de les utiliser mais regarde dans la doc quels codes de renvoi tu peux récupérer sur la fonction send(), rien ne garantit qu'un packet UDP arrive dans le bon ordre ou arrive tout court.

Peut-être que ta boucle fait que les packets sont bien envoyés mais pas reçus du côté des clients. Si tu veux envoyer des messages textes et être sûr de les recevoir tu pourrais utiliser des sockets TCP (un socket par client que tu stockerais dans ta liste à la place de l'IP), ou alors mettre en place un système de vérification de bonne réception, que le client renvoi l'info qu'il a bien reçu le packet sinon on lui renvoi. Enfin bon, rien ne sert de réimplémenter les fonctions de TCP par dessus UDP.

Regarde du côté de tes clients s'ils sont bien prêts à recevoir tes messages. Autrement je vois pas.

26

Réseau / Re : Impossible à une connexion extérieure de se connecter à mon programme..

« le: Février 03, 2017, 01:07:05 pm »

Je vois que le problème est résolu. Mais je te pose une réponse au cas où à l'avenir.

Si tu es sous windows tu as du avoir une fenêtre qui s'est ouverte pour demander si ton programme pouvait accéder au réseau. Quelque soit ton pare-feu logiciel tu peux quelque part y paramétrer les autorisations pour chaque programme.

Mais le problème venait plus probablement de ton pare-feu matériel, la box derrière laquelle tes ordinateurs sont branchés pour accéder à Internet (je suppose que c'est le cas, que tu es derrière une box). C'est dans la configuration de cette box que tu doit faire des redirections de port, par exemple lui dire que lorsqu'elle reçoit une requête depuis l'extérieur sur le port P, elle relaye la requête vers l'IP 192.160.0.X, celle de ta machine sur laquelle le serveur du jeu tourne, sur le port P.

Autrement, une solution plus rapide, si la configuration du pare-feu de ta box te propose de mettre une adresse en DMZ, tu peux y mettre l'adresse locale de ta machine (192.168.0.X) et elle sera accessible depuis l'extérieur sur tous les ports (sauf ceux qui ont été redirigés vers une autre adresse, je pense).

27

Réseau / Résolution du problème d'endianness

« le: Février 03, 2017, 12:59:16 pm »

Bonjour !

Je viens poser une question d'ordre totalement général pour combler mes lacunes. J'aurais pu le faire sur un autre forum éventuellement, mais comme j'ai été introduis à ce problème par le tuto sfml sur les socket et les sf::Packet et que j'utilise la SFML, je me permets de poster ici.

Dans le tuto sur l'envoie de sf::Packet il est dit que pour éviter les problèmes de différence d'endianness entre les machines, plutôt que d'utiliser les types numériques pré-inclus dans le C++ (int, long...) il valait mieux utiliser les types de la SFML tels que sf::Int8, sf::Uint16 etc. Mais il est dit dans la documentation que c'est types ne sont ni plus ni moins que des alias pour les types du C++. Comme le sont les types uint8_t etc. du header cstdint.h.

Du coup je me demandais par quel procédé le fait d'utiliser des alias réglait le problème d'endianness lors de la communication sur le réseau ?

J'espère vraiment que ma question a sa place ici et qu'elle trouvera quelque passionné de l'informatique bas niveau pour me répondre.

28

Graphique / Re : Carré blanc et changement d'adresse?

« le: Novembre 09, 2016, 08:49:28 pm »

Yep, une texture ça prend pas mal de place en mémoire et c'est long à charger, alors il faut la charger une seule fois pour tous les sprites qui l'utilisent. Tu en viendras rapidement à te coder un petit gestionnaire de textures (ou a en utiliser un déjà fait, y'a pas de honte à ne pas réinventer la roue si ça t'intéresse pas de le coder toi-même).

29

Système / Re : Rendu et logique dans des threads séparés

« le: Novembre 09, 2016, 03:03:42 am »

A mon avis si tu ne comprends pas les mutex tu n'as pas besoin de tutoriels plus complexes, plutôt plus complets. Cherche un tuto qui prend le multithreading de zéro.

Le mutex sert à faire en sorte de protéger différentes parties du programme pour s'assurer qu'elles ne s’exécutent pas en même temps. Donc elles doivent être protégées par le même mutex.

Par exemple si tu as un bout de code qui écrit dans un tableau, et un autre qui lit dans le même tableau, tu ne veux pas que ces deux morceaux de codes puissent s’exécuter en même temps dans deux threads de ton programme. (A moins d'utiliser un conteneur threadsafe.) Ainsi, tu "lock" les morceaux de code à protéger avec le mutex. Lorsqu'un thread lock le mutex, si l'autre thread arrive à la partie du programme qui est protégée par le même mutex, il devra attendre que le mutex soit libéré pour pouvoir le locker à son tour et exécuter la suite du code.

Utilise plutôt des lock que des mutex. Un lock bloque un mutex dans son constructeur et le débloque dans son destructeur. Ainsi en cas d'exception, le lock est détruit et libère automatiquement le mutex, ce qui évite que ton programme reste bloqué.

30

Graphique / Re : [Résolu] Dessinner un objet à une taille constante

« le: Novembre 09, 2016, 02:50:48 am »

Je pense que tu pourrais de manière beaucoup plus simple créer une view, que tu appliques à la fenêtre et tu affiches tout ce que tu as à afficher, sauf ta flèche. Le niveau de zoom est appliqué à cette view.
Ensuite tu appliques à la fenêtre à nouveau sa view par défaut et tu y dessines ta flèche, qui aura donc une taille constante non affectée par le zoom de l'autre view. Tu fais cela à chaque tour de boucle, c'est une façon performante de procéder.
Ou alors j'ai rien compris à ton problème.