Messages

1

Graphique / Re: Affichage décalé

« le: Septembre 15, 2017, 12:47:28 pm »

Entre temps il y a eu de nouvelles versions de la SFML. Compilées avec d'autres versions de MinGW et GCC.
Donc tu devrais à mon avis re-télécharger la SFML et installer la version de MinGW précise qui correspond au build que tu prendras, ou la compiler toi-même. Et dans les deux cas recompiler tes programmes avec le même compilateur.
Essaye aussi d'enlever les options d'optimisations à la compilation si tu en as mis, je ne sais pas, je dis ça au pif.

2

Graphique / Re: Question généraliste de compréhension sur les VertexArray

« le: Septembre 09, 2017, 11:16:21 am »

Merci de ta réponse !

En fait peut-être que ma question n'a pas trop de sens je sais pas; il y a un manque de compréhension théorique de ma part derrière.
Je vais faire quelques tests et recherches avant de préciser mieux cette question ou pas. Notamment sur le fait que tu m'as dis que je ne peux appliquer qu'une texture à un VertexArray, je vais voir comment je peux jouer avec ça ou pas.

3

Graphique / Re: Affichage décalé

« le: Septembre 09, 2017, 11:08:27 am »

Du coup là ça sonne étrange comme problème effectivement ^^
Quand tu as fait tes nouveaux tests, tu as bien pris la bonne version de SFML qui va avec le bon MinGW de ton CodeBlocks ?
Faut qu'il y ait une cohérence parfaite, entre la compilation de la lib et de ton programme.
(Au mieux, recompiler la SFML avec le même compilateur que ton programme).

Il y a une fonction dans l'API de la SFML qui permet de convertir les coordonnées d'un point de la fenêtre (qui a une dimension donnée, donc des limites fixes) en une valeur du "monde" de l'affichage SFML, qui s'étend à l'infini dans toutes les directions depuis le point 0,0. Je ne me rappelle plus du nom de la fonction mais ma question c'est : est-ce que tu l'utilises dans ton programme où les collisions sont maintenant décalées ?

4

Graphique / Re: Affichage décalé

« le: Septembre 06, 2017, 06:29:30 pm »

Le point 0, 0 se trouve en haut à gauche.
Quand tu augmentes la valeur y d'une position tu descends sur l'écran.

Edit : j'avais pas vu la dernière ligne de Guitox. Sinon t'as peut-être des décalages liés à tes vues où à la transformation entre les coordonnées locales des sprites et les coordonnées globales "du monde" SFML.

5

Graphique / Re: Procédure introuvable _ZSt24_throw_out_of_range_fmtPKcz

« le: Septembre 06, 2017, 06:27:17 pm »

C'est pas simplement que, lorsque tu lances sous CodeBlocks, il prend en compte le chemin source du projet OU le chemin bin/Debug (je me rappelle plus), et quand tu le lances par l'explorateur il ne prend en compte que le chemin du dossier duquel tu lances le programme ?

Ou encore, les chemins des libs sont peut-être (je sais même pas si c'est possible) indiqués dans l'exécutable lors de la compilation.

Bref, pour résoudre le problème place les dll à la fois dans le dossier racine de ton projet ET dans le dossier de ton exécutable, comme ça tu dois pouvoir le lancer des deux façons.

Sous Linux il y a moyen d'indiquer l'emplacement des librairies au système, de sorte que le programme se lance quelque soit l'emplacement depuis lequel on l'appelle, sans avoir à copier les fichiers de librairies, qui résident tranquillement dans le dossier d'installation de la SFML. Peut-être est-ce possible sous Windows aussi, je ne sais pas ! Mais probablement.

6

Discussions générales / Re: Ma petite chaîne youtube avec des tutoriaux SFML.

« le: Septembre 06, 2017, 11:31:36 am »

Hey, super sympa ta chaîne !
Elle va m'être utile aussi, car les titres des vidéos semblent répondre à des questions que je me pose.

Seul bémol : pourquoi ne pas trouver moyen de prendre des screencast de meilleure qualité ? Tes vidéos sont en 360p maximum. Monter en 720 permettrait de lire le code à l'écran, ce qui pour le moment n'est pas possible (pas chez moi en tous cas).

Edit : Par contre les + : j'aime beaucoup ta façon de parler, sans faute, et le rythme, qui pour moi est pile à la bonne vitesse. Tu n'en dis ni trop ni pas assez, tu vas suffisamment vite par rapport au niveau du public auquel tu t'adresses, sans aller trop vite non plus. Vraiment, bonnes vidéos je trouve ! Donc si tu peux juste améliorer la qualité de l'image sur yt ce serait parfait !

7

Discussions générales / Re: Des signaux, des slots, et SFML

« le: Septembre 06, 2017, 10:56:04 am »

Pour l'instant je n'ai pas regardé les GitHubs mais je voulais juste dire que je suis enthousiaste face à des projets comme celui-ci. C'est intéressant, il y a toujours des choses à en apprendre, et ça peut même être utile dans des projets. Donc je voulais dire bravo pour le travail accompli, même si je n'ai pas encore regardé je sais qu'il y a eu du temps et de la bonne volonté derrière, c'est déjà ce qui compte pour moi

Je m'en vais shouffer le code.

8

Discussions générales / Re: fonction sleep et compatibilité os

« le: Septembre 06, 2017, 10:49:04 am »

Aussi, dans la foulée, en lisant  SleepImpl.cpp je lis #include <windows.h>, j'apprends que windows.h est une librairie de windows. Je revois la page d'entrée du site sfml et je lis "SFML est multi-plateforme".
D'où ma seconde question: comment avoir cette compatibilité entre différents os si le fichier src appelle du code spécifiquement pour windows?

C'est toute l'astuce du côté multi-plateforme avec look natif d'une appli de fenêtrage ! Et ça représente beaucoup de boulot aussi. SFML appelle les fonctions natives des OS sur lesquels elle fonctionne, lors de la compilation. Elle abstrait ces fonctions avec une API cohérente qui est la même sur tous les OS.

Le seul autre choix pour faire du multi-plateforme pour une bibliothèque de fenêtrage (mais là je parle plus d'une bibli comme Qt ou WxWidgets, qui ont tous les widgets type "boutons", "barre de défilement" etc.), serait de créer un seul look qui soit le même sur toute les plateformes (ou plusieurs thèmes de looks pourquoi pas). Mais on n'aurait pas le look natif de la plateforme sur laquelle on compile.

On pourrait à la limite tenter d'imiter, de reproduire parfaitement une fenêtre de MacOS (par exemple) avec l'apparence de ses boutons, de ses textes, de ses formulaires... Mais quand demain MacOS change de look, ou si simplement aujourd'hui l'utilisateur choisi un autre thème que celui par défaut pour son OS, on voit tout de suite que notre application n'a pas le look natif.

Donc par exemple dans le cas de la création d'une fenêtre, ou dans le cas de l'ouverture d'un socket, dans notre bibliothèque on écrit une seule classe avec son API, et selon la plateforme sur laquelle on est, la compilation appellera le fichier d'implémentation (***Impl.cpp) correspondant.

Donc le mot "multi-plateforme" ici implique que ça ne fonctionne quand même que sur les plateformes pour lesquelles un grand boulot à été fait : le travail de connaître le fonctionnement des bibliothèques natives de la plateforme et de traduire les appels de ces bibliothèques au sein de fonctions génériques.

9

Graphique / Question généraliste de compréhension sur les VertexArray

« le: Septembre 05, 2017, 07:52:42 pm »

Bonjour !

A force d'utiliser la SFML (bien que cela fasse maintenant un moment que je n'ai pas trop touché au C++), j'ai fini par comprendre certaines choses sur son fonctionnement, notamment le fait qu'une des clefs de la performance se trouve dans la limitation des appels à la fonction draw().

Ainsi j'ai compris le tuto qui explique comment créer un niveau sous forme de tilemap en utilisant un sf::VertexArray plutôt qu'un sf::Sprite par tile.

Maintenant, j'aimerais savoir si je dois rechercher toujours au maximum le passage par les VertexArray ? Exemple : prenons le cas farfelu où je voudrais me lancer dans la création d'une bibliothèque d'UI basée sur SFML, une collection de "widgets" tels des boutons et zones de textes éditables ou non, des "fenêtres" affichées à l'intérieur de la RenderWindow, avec du drag & drop à la souris.

Est-ce qu'il est réaliste de vouloir "assembler" tout ça, ou une grande partie de tout ça, en un VertexArray, en sachant que certains éléments peuvent bouger ?

Dans un autre cas, qui pourrait être inclus dans ce premier exemple, celui où je voudrais faire des boîtes de textes dont les retours à la ligne s'adaptent au redimensionnement de la taille de la boîte. Est-ce que là, je devrais créer ma propre classe plutôt que de passer par sf::Text, et ainsi finir avec un VertexArray ?

Est-ce que tout ça est mélangeable ? Est-ce que je peux avoir des éléments qui bougent, qui font des rotations, mais sont au final toujours inclus dans un VertexArray général qui gère l'affichage ?

Finalement la réponse peut simplement se résumer à "oui ou non". Comme il reste un flou dans ma compréhension, je voudrais seulement savoir si ma recherche est orientée dors et déjà vers une impasse, ou une solution over-compliquée, ou bien si c'est raisonnable.

Je vous remercie pour votre lecture !

Ren.

10

Réseau / Re: Problème de réception de données côté Client..

« le: Juillet 29, 2017, 07:20:17 pm »

Du coup j'ai pas compris comment le problème a été résolu, et en quoi c'est du à un Selector (ça fait beaucoup de code à lire ).

A la base je t'aurais dis de faire attention dans ton instruction chaînée d'être bien sûr que l'opérateur ' << ' retourne bien une référence vers ton sf::Packet quand tu l'utilises avec des types personnalisés.

Pour ta question plus générale d'échange de paquets, il n'y a aucun obstacle à ce que le serveur contacte un client sans avoir au préalable reçu un message de celui-ci. Il suffit que ton serveur connaisse la liste des clients (connectés ou non (UDP)), et qu'il leur envoi un paquet quand tu le veux.

Il y a beaucoup de façons de procéder. Tu peux envoyer ton paquet immédiatement quand le serveur décide qu'il doit envoyer quelque chose à tel client. Tu peux aussi créer une file de paquets sortants, qui sera traitée, soit en la vidant complètement lors d'un tour de boucle de ton programme, soit en envoyant le paquet du bout de la file à chaque tour (permet d'équilibrer les opérations, premier arrivé premier servi, mais la boucle doit tourner vite et sans interruption).
Soit encore en ayant un thread qui s'occupe d'envoyer les paquets à destination lorsque la file n'est pas vide, mais là c'est plus compliqué et probablement pas le plus performant.

C'est juste que selon la complexité de ton programme tu peux en arriver à désirer un gestion "centralisée" de l'échange de messages, plutôt que d'avoir des fonctions send() un peu partout dans le code. Par exemple créer une class Transaction qui contient le paquet à envoyer et l'adresse du destinataire (ou le pointeur vers le socket), mais qui reste en vie après l'envoi, et ne disparaît que lorsqu'elle a reçu la réponse attendue, et qu'elle la transmise où il faut. Elle ne doit évidemment pas être bloquante. Les Transactions sont dans un conteneur, vérifiées à chaque tour du programme, et en sont effacées lorsque leur job est fini.

Ce sont juste des idées générales. Et probablement pas les meilleures.

11

Réseau / Re: Serveur / Client.. Comment faire une bonne gestion ?

« le: Juillet 29, 2017, 07:00:05 pm »

Hey ! J'avais pas vu ta réponse et comme il y a pas masse de topic dans le forum je me permets de remonter pour te dire : de rien ^_^ Avec plaisir

12

Graphique / Re: Problème lors de l'appel de loadFromFile

« le: Mai 11, 2017, 12:21:59 am »

Pour t'aider à localiser l'erreur, c'est LD, le linker, qui renvoyait un code d'erreur. Il ne savait pas où trouver la définition de la fonction loadFromFile() de la classe sf::Texture.
La compilation de la SFML sur ta machine a mis tout le monde d'accord apparemment

13

Fenêtrage / Re : sf::RenderWindow fail sans variable d'environnement

« le: Mars 19, 2017, 04:00:36 pm »

Sur Linux on aime utiliser le principe de bibliothèques partagées.
Si tu tapes 'ldd ton_executable' tu verras toutes les bibliothèques dont ton programme a besoin pour fonctionner.

Il est fort probable que ton programme se serve de certains chemins déclarés dans des variables d'environnement pour aller chercher ces bibliothèques. Car il y a plusieurs façon de faire fonctionner un programme qui a besoin de ces bibliothèques, notamment, si on veut en indiquer le chemin au moment de l'exécution, ça peut passer par les variables LD_LIBRARY_PATH et/ou LD_RUN_PATH. Ces variables sont-elles définies dans ton environnement habituel ?

Je pense que ton programme plante car il ne trouve pas la classe, donc puisqu'elle n'existe pas elle ne peut pas lever d'exception.

La solution serait de compiler ton programme avec des bibliothèques statiques, ou peut-être peux-tu passer certaines options au linker/compilateur pour que lors de l’exécution, le programme aille chercher ces bibliothèques dans son propre répertoire racine, dans lequel tu les auras copié.

14

Fenêtrage / Re : affichage de shapes dans la deuxieme fenêtre

« le: Mars 19, 2017, 03:50:54 pm »

Si j'ai bien compris ton problème, c'est tout le côté C++ "orienté objet", classes et héritage que tu dois revoir.
Mais ne t'inquiète pas, c'est normal de galérer un peu au début.

Je ne vois pas tes fichiers hpp mais j'ai l'impression que tes classes NE SONT PAS des sf::RenderWindow.

Normalement, ta classe de fenêtre perso devrait être déclarée comme suit :

#include <SFML/Graphics.hpp>

class MaFenetre : public sf::RenderWindow // On hérite de sf::RenderWindow, ce qui fait que MaFenetre EST une RenderWindow
{
    //...
};
 

Et dans ton main(), tu dois déclarer ta fenêtre et appeler ses méthodes à partir du nom d'objet de ta fenêtre, pas en appelant le nom de la classe (d'une façon totalement obscure pour moi, je savais pas que ça compilait).

#include "MaFenetre.hpp"

int main()
{
   //...
   MaFenetre premiereFenetre(/* arguments */);

   while ( premiereFenetre.isOpen() )
   {
     // Gérer les événements, faire des trucs...
     // Puis afficher :
     premiereFenetre.clear();  // On efface la fenêtre à chaque frame.
     premiereFenetre.draw(/* un objet dérivant de sf::Drawable */);  // On dessine dans la fenêtre.
     premiereFenetre.display(); // On affiche ce qu'on a dessiné.
   }

   return 0;
}
 

15

Réseau / Re : Serveur / Client.. Comment faire une bonne gestion ?

« le: Mars 19, 2017, 03:34:19 pm »

Savoir si c'est le client ou le serveur qui gère les collisions, les positions des joueurs etc., ça répond à la question de la triche. Veux-tu réduire au maximum toute possibilité de triche ? Alors c'est le serveur qui calculera si le client peut aller dans la direction qu'il demande, ou s'il est bloqué par un mur. Si c'est le client qui calcule, alors il peut influer sur le déroulement du programme et envoyer au serveur une position pour lui signaler qu'il a traversé le mur.

Voilà déjà une chose à considérer.

D'un autre côté, si le serveur doit envoyer tout le niveau à charger au client, ça prendra beaucoup de bande passante et influera sur les performances du serveur, possiblement mêmes celles ressenties par les autres clients qui n'ont rien demandé.
Il est plus judicieux que les fichiers map soient stockés localement chez le client, après pourquoi pas tenter d'éviter la modification des maps en faisant vérifier le checksum de celles-ci par le serveur.

Bon, à part ça, je ne m'y connais pas plus que ça, je ne sais pas comment ils font dans l'industrie, surtout pour les gros MMO avec des milliers de joueurs par serveurs.
Il me semble que la plupart du temps les positions sont calculées à la fois côté serveur et client, ainsi l'affichage chez le client est ultra-rapide, pas besoin d'attendre la confirmation du serveur, et de l'autre côté, le serveur met régulièrement à jour la position du client s'il y a un décalage entre là où le client croit se trouver et là où le serveur l'a positionné.