Messages

1

Réseau / Re : Bug, un caractère en trop dans mon paquet pour les packets perso.

« le: Juillet 23, 2013, 08:54:13 am »

Bref je préfère largement SFML pour le réseau, j'avais essayer QT dans le passé mais ça ne marchait pas et puis je pense que SFML est plus adapté pour les jeux. :/

Oui et non, les deux sont de "simple" wrapper, il n'y pas de réelle implémentation orienté jeux. De plus, ces deux libraries utilisent select en backend ce qui adapté pour un jeu multijoueur mais surement pas pour un jeu 'massivement' multijoueur. ;-)

2

Réseau / Re : Bug, un caractère en trop dans mon paquet pour les packets perso.

« le: Juin 29, 2013, 07:27:02 pm »

OpenSSL, pour Windows : http://slproweb.com/products/Win32OpenSSL.html

3

Fenêtrage / Re : Ma fenêtre ne s'ouvre pas chez tout le monde

« le: Juin 21, 2013, 01:50:54 pm »

EDIT: J'ai mis à jour mon premier post sur mon compilateur qui était ambigüe : j'utilise MinGW, donc sous Windows, pas sous *nix.

Un ami m'a dit qu'il était possible que le problème vienne de MinGW et que si j'utilisais VSC++ je n'aurais certainement pas ce problème. Est-ce possible ?

Oui bien sur. L'implémentation de MinGW est loin d’être parfaite. VC++ et l'implémentation de lib standard n'est pas parfaite loin de la mais ça ne coûte rien d'essayer, la version express est gratuite en plus ;-)
Apres tu n'est pas le seul a utiliser MinGW sur ce forum, sachant qu'il n'y a pas eu de retour comme quoi la fenêtre ne s'ouvrait pas... Il faudrait que tu récupère les caractéristiques précises des ordinateurs ou il y a ce problème, faire un comparatif et trouver le dénominateur commun, c'est la vielle méthode classique mais dangereusement efficace.

4

Réseau / Re : Réception des packets en TCP.

« le: Juin 15, 2013, 11:56:45 pm »

Le module réseau de la SFML est un simple wrapper des sockets de Berkeley, ni plus ni moins.
Je rejoins le post du dessus, plus d'informations sont nécessaires : platforme, naggle on/off etc...

5

Général / Re : SFML et consommation de ressources CPU.

« le: Mai 25, 2013, 07:10:50 pm »

Je te conseil d'abandonner ton architecture multithread, c'est extrêmement compliqué et casse gueule de faire du multithreading et à priori ca t'apporte rien de bon, au contraire. C'est surement la meilleure solution que tu pourras mettre en oeuvre.

6

Réseau / Re : Synchronisation des données client-serveur et sf::clock

« le: Mai 20, 2013, 08:02:48 pm »

Je ne peux t'aider plus qu'en te bifurquant vers la documentation de référence sur le sujet :
http://gafferongames.com/game-physics/networked-physics/
https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
http://en.wikipedia.org/wiki/Dead_reckoning

7

Graphique / Re : Re : Taille d'un sf::Vertex

« le: Mai 11, 2013, 03:38:36 pm »

Bon, je vous suggère d'arrêter là ce troll.
A titre de comparaison, il est plus rapide d'allouer de grandes quantités de mémoire que plein de petites pour une même quantité finale. C'est la raison même d'existence du pooling.

C'est plus ou moins juste. L'allocation de petits blocs de mémoire peut rompre la consistance de ton cache si ton jeu essaie d'y accéder de manière séquentielle. Je ferme cette parenthèse.
Je me dois de nuancer mon propos précédent, que ce soit un petit jeu en 2d ou un jeu 3d AAA, tu gagneras toujours a utiliser les bonnes méthodes et les bons patterns notamment lorsqu'il s'agit de la gestion de la mémoire. Selon la complexité de ton jeu, ton budget et le temps qu'il t'es accordé, tu pourras toujours complexifier ton implémentation pour répondre aux contraintes imposés.
Si l'auteur du thread a eu les réponses désirées alors on peut clore ce sujet.

8

Graphique / Re : Taille d'un sf::Vertex

« le: Mai 10, 2013, 02:30:17 pm »

Les particules et les Vertex Alloués dynamiquement sont bien sûr supprimés après. (pas de fuite de mémoire)
L’intérêt est de me permettre de compter le nombre de particules présentes et les gérer plus simplement.
Enfin, ça doit pas être trop contre-performant étant donné les perfs que j'ai avec des points  (Je suis sur une Nvidia GT 440 & I5 Quad Core a 3.2Ghz ou  Nvidia GT 220 & AMD Athlon II Dual Core a 2.7Ghz en fonction des fois, mais ça passe aussi bien sur l'un que l'autre  )

On évite le plus possible l'allocation de mémoire dynamique dans un jeux vidéo car ça affecte énormément les performances, en règle générale, on alloue toute la mémoire nécessaire au fonctionnement lors de l'initialisation du jeu.
Pour un système de particule, le pooling (http://en.wikipedia.org/wiki/Object_pool) se prête bien à ce système. Je fais cette remarque suite à la remarque de Laurent :

- ton code est vraiment bizarre (des sf::Vertex alloués dynamiquement ?!), j'ai peur que tu ne fasses des choses très contre-productives

9

Audio / Re : Trop de threads tue le thread.

« le: Mai 06, 2013, 08:32:35 am »

Utilises tu des futures / promises dans ton code a un moment donnée ? (ajout de C++11)