Messages

1

Système / Re : Sur quoi se base la classe clock pour mesurer le temps ?

« le: Juin 09, 2013, 12:22:37 am »

Loli, à chaque foi que tu postes un truc c'est toujours la même chose, t'as de gros soucis avec ton code (c'est pas anormal on en a tous plus ou moins assez souvent ) mais direct tu viens dire "hey attends ça c'est un bug dans la sfml c'est pas possible".
Et bien non, franchement ya juste a peu près 0.005% de chance que t'en découvres vu ce que tu devs (pas de choses exotiques) alors ya un moment si ça ne passe pas il faut que tu fasses un gros ctrl+molette sur ton code, quitte à tout recoder (et savoir tout recommencer c'est ce qui différencie en partit un bon d'un mauvais dev).

2

Système / Re : Classe Clock et les threads.

« le: Juin 05, 2013, 04:27:56 pm »

Ok, ça a donc dût être mis à jour depuis, c'est cool faudra que je recode quelques trucs avec. :3

Par contre loli, bon j'ai l'impression de me répéter à chaque foi mais... Ton problème vient pas de ce que tu utilises... Quelque soit la lib c'est assez optimisé pour que tu ne vois aucune différence entre l'une ou l'autre... C'est pas en passant de sfml à std pour les threads que tu verras la différence.
C'est comme un joueur de tennis pro qui te dira que ya une énorme différence entre une balle de grande surface et la marque officielle qu'il utilise...

donc :

j'espère que mon projet va moins laguer avec ça

Non !

3

Système / Re : Classe Clock et les threads.

« le: Juin 05, 2013, 12:35:07 pm »

je l'ai pas précisé mais je parle de gcc et donc 381 = 4.8.1 ^^
Je suis tellement habitué à utilisé uniquement celui-là que j'ai oublié que yen avait d'autres. :p

En regardant les changes je ne vois rien à ce qui concerne les threads même pour la version 4.9 à venir. :/

Voilà ce que je me tape avec gcc 4.7.2 en tout cas :

error: 'std::this_thread' has not been declared
error: 'thread' is not a member of 'std'

(avec cet exemple : http://en.cppreference.com/w/cpp/thread/thread/thread)

4

Système / Re : Classe Clock et les threads.

« le: Juin 05, 2013, 09:09:51 am »

Rien jmélange les versions de différents trucs, spas grave. 

5

Système / Re : Classe Clock et les threads.

« le: Juin 04, 2013, 11:33:47 pm »

En fait jviens de voir que chuis plus à la bourre que je pensais, j'ai la 472 (donc de fin septembre) ça a dût être intégré depuis va falloir que je regarde les logs pour passer std::thread si c'est possible maintenant...

Mais ce qui m'avait surpris c'est que j'utilise en gros tout ce que propose c++11 et c'était le seul truc qui était annoncé comme incomplet totalement inutilisable. Mais vu qu'on est maintenant à la 381 ça doit être bon. ^^
(et j'espère qu'ils en ont profité pour réparer leurs conneries avec les maps)

edit: d'après les status ça a l'air supporté, par contre c'est toujours très incomplet et ya toujours pas les futures malheureusement. :/

6

Système / Re : Classe Clock et les threads.

« le: Juin 04, 2013, 09:10:06 pm »

Sauf qu'elle est pas encore utilisable...
La dernière foi que j'ai essayé je me suis aperçut que serte les .h étaient complets mais que rien était implémenté... Alors oui tu peux instancier un thread... mais voilà.

7

Réseau / Re : Impossible d'écouter le port ....

« le: Juin 03, 2013, 08:52:21 am »

La priorité des sockets de ce que je comprend... En gros ça va changer non pas la priorité de la requête car en tcp ça n'existe pas (on ne peut pas garantir l'ordre d'arrivée des données) mais la priorité du processus sur la machine de destination qui va "dans l'idée" interpréter les commandes plus vite et donc acquérir ce message urgent en priorité par rapport aux autres applis qui pourraient utiliser les réseau.
Je dirais un exemple d'utilisation... 2 serveurs, un qui mange de la donnée et un qui sert de superviseur. On passera des données au superviseur via des messages urgents ce qui aura pour effet de légèrement casser le flux de données mais affichera immédiatement les informations pour l'utilisateur.

8

Graphique / Re : Polymorphisme Drawable&Transformable

« le: Juin 02, 2013, 12:46:05 am »

C'est pas ça que tu cherches ?
type erasure
(fait de tête, j'ai peut-être fait une erreur mais en gros c'est ça)

/* objet générique */
class AbstractNode
{
public:
    AbstractNode();
    virtual ~AbstractNode();

    virtual void mySexyMethod() = 0;
     ...
     // (et toutes celles qu'on veut public)
};

/* objet conteneur */
template<class Object>
class Node : public AbstractNode
{
public:
    Node(Object& o);
    virtual ~Node();

    virtual void mySexyMethod() override;
     ...

private:
    Object& m_object;
};

template<class Object>
Node<Object>::Node(Object& object) :
    m_object(object)
{}

template<class Object>
Node<Object>::mySexyMethod()
{
    m_object.mySexyMethod();
}

/* création */
AbstractNode prout = Node(*new Sprite);
prout.mySexyMethod();
 

9

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

« le: Juin 01, 2013, 02:17:05 pm »

Non mais déjà je te l'ai déjà dis mais si c'est lié au réseau fout ton code à la poubelle.
Le réseau n'a absolument aucune influence sur le rendu, si c'est le cas voir phrase au dessus.

10

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

« le: Mai 31, 2013, 02:08:11 pm »

Ce qui se passe là n'est absolument pas normal et complètement indépendant des perfs de la sfml. 

11

Général / Re : Simuler Pixel Shader avec SwiftShader

« le: Mai 23, 2013, 09:14:20 pm »

Justement, il a un problème et pense avoir trouver une solution dans SwiftShader. Le soucis c'est que à moins que quelqu'un ai déjà utilisé ça, personne ne pourra l'aider ici car ce n'est pas en relation avec la sfml.

Donc, les membres de ce forum ne pourront faire que deux choses :
- proposer une alternative technique,
- lui conseiller d'aller demander sur un forum plus spécialisé

Par contre s'il trouve la solution ça peut éventuellement m'intéresser. :-°

12

Général / Re : Simuler Pixel Shader avec SwiftShader

« le: Mai 23, 2013, 08:15:09 pm »

Mais quiconque a vraiment fait des shaders c'est très vite aperçu des décalages qu'il y a d'une carte à l'autre. Il est obligatoire d'avoir un maximum de contacts (avec des configs différentes) pour tester leurs fonctionnements, à partir de là peut-être vaudrait-il mieux qu'il les dev avec un logiciel de test de shaders spécifique (ya même des sites web qui proposent ça) et ensuite le fasse tester à ses contacts en les intégrant à son appli.
Après tout, un shader ça fait toujours la même chose donc une foi qu'il fonctionne correctement...
Même s'il arrive à les faire tourner avec certaines libs il y a de fortes chances que par exemple se soit trop permissif par rapport à certaines cartes ce qui l'obligera à déboguer complètement ses shaders.

[troll=parce que c'est mon lot quotidien ]
Le problème des chips c'est pas qu'ils ne les supportent pas, c'est plutôt qu'ils essaient de les supporter... Je sais même pas pourquoi d'ailleurs étant donné qu'ils n'arrivent même pas à gérer le moindre changement de couleur sur un pixel, ils se contentent juste de foutre en l'air la texture. Et ça oui, ça mérite bien son troll étant donné le coût des cartes graphiques lite qu'ils pourraient intégrer sans augmenter le prix du pc... Tout ça c'est marketing, faisons de la merde pour mettre en valeur nos portables hors de prix équipés de cartes inadaptées qui vous bruleront les genoux.
[/troll]

13

Général / Re : Simuler Pixel Shader avec SwiftShader

« le: Mai 23, 2013, 08:20:14 am »

Vouloir faire des shaders avec une carte intel (la moisissure infernale) c'est comme vouloir faire du réseau sans connexion...

14

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

« le: Mai 19, 2013, 11:30:30 pm »

Ouais j'avoue que ça doit pas forcément être simple à trouver..

Dans tous les cas il faut réduire un maximum les calcules que le serveur doit réaliser sans pour autant que ça impact la "sécurité" (triche...). Mais bon, on peut pas dire que se soit le plus simple à faire le prédictions, à ce que j'ai entendu c'est même le plus compliqué.

15

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

« le: Mai 18, 2013, 08:56:43 pm »

Le sf::Clock a rien de particulier et a rien à voir avec tes soucis.

Commence par t'en foutre du temps réel, déjà affiche des déplacements visible entre les deux clients mais avec la latences, une foi que t'auras ça tu pourras travailler sur les prédictions de déplacements, n'essaies pas de tout faire d'un coup. 

Mais quand tu parles de "même algorithme côté client et serveur" je me dis que tu devrais aller lire des articles sur la conception de serveur de jeu.