Messages

16

Système / Re : Bug avec les threads. (Les mutex ne marchent pas dans un certain cas précis.)

« le: Août 09, 2013, 11:29:55 pm »

Oh bah alors si ça frise sans beuguer... tout va bien !

Ce que j'aime c'est ton humilité... m'enfin peut-être as-tu une très solide expérience du développement "de haut niveau" qui te permet ces certitudes, moi tout ce que je sais c'est que si tu pars bille en tête qu'un comportement que tu observes mais ne comprends pas ne peut pas venir de ton code "tellement qu'il est bien pensé dès le départ", tu ne vas pas beaucoup progresser dans ton approche, et ton soft non plus ne risque pas d'évoluer.

Le design, les rapports, toussa c'est super, m'enfin avoir un minimum le nez dans la technique (le "bas niveau") c'est pas mal aussi, ça permet de comprendre certaines choses (pourquoi ça freeze alors qu'il y a sûrement moyen d'éviter ça par exemple), surtout quand on développe un jeu. Ca évite aussi de faire des gros bricolages tous moches pour contourner un problème parcequ'on ne le comprend pas.

Bref je m'éloigne fortement du sujet, je ne peux que te souhaiter de réussir à pondre un soft stable, maintenable et upgradable, les utilisateurs jugeront.

Une dernière anecdote pour la route des fois qu'un éclair de lucidité te traverserait l'esprit : l'autre jour, lors d'une recompilation du soft sur lequel je bosse, le compilo me sort une erreur chelou sur une formule de maths un peu compliquée... alors que syntaxiquement le code était bon. En fait c'était moi qui m'était planté sur une manip' lors de la build, et j'ai mis pas mal de temps à trouver l'erreur. A ma place t'aurais sûrement reporté un bug sur le bugtracker de GCC non ? Genre "Les priorités d'opérateurs ne fonctionnent pas dans certains cas"... ?

En tous cas bonne chance...

17

Système / Re : Re : Bug avec les threads. (Les mutex ne marchent pas dans un certain cas p

« le: Août 08, 2013, 11:20:20 pm »

ce problème de freeze vient soit de la SFML ou de l'os.

Tu leur diras ça à tes futurs utilisateurs s'il te rapportent un comportement inattendu... ?

Surtout qu'à chaque fois tu finis par découvrir que les bugs viennent de ton code et/ou n'impliquent pas les éléments que tu incriminais au départ.

Alors si tu es aussi sûr du reste de ton code que tu es sûr de ce que tu nous montres... avant d'y trouver des bugs, pas étonnants que tu ais des problèmes, qui à 99% ne viennent ni de SFML et encore moins de l'OS (à moins que tu n'utilisent des algos tellement poussés que tu lèverais à toi seul des bugs qui n'auraient pas été découvert par les millions d'utilisateurs qui utilisent cet OS quotidiennement).

18

Système / Re : Bug avec les threads. (Les mutex ne marchent pas dans un certain cas précis.)

« le: Août 07, 2013, 08:15:39 pm »

Bah je trouve pas, j'ai initialisé toutes mes CellMap avec le pointeur NULL dans mon std::vector, donc, il ne devrait pas y avoir de CellMap qui ne soit pas initialisée. :/

 

J'ai bien lu ? Tu as donc des CellMap* stockées dans un std::vector, qui valent NULL, et tu tentes d'appeller des méthodes dessus ?

19

Système / Re : Bug avec les threads. (Les mutex ne marchent pas dans un certain cas précis.)

« le: Août 07, 2013, 07:04:03 pm »

De toute façon selon le message d'erreur que tu nous avais indiqué, tu as un bout de code qui tente d'accéder à la méthode getCenter d'une CellMap qui n'est pas initialisée au moment où l'appel est effectué... ça ne doit pas être bien difficile à retrouver dans le code...

20

Système / Re : re

« le: Août 06, 2013, 11:01:52 pm »

Et ça ne plante que quand je lance le débugueur, quand je le lance normalement ça ne plante pas.

[...]

Pour une raison que j'ignore, mes CellMap ne sont pas bien initialisée dans mon thread. (Lorsque j'initialise le thread, dans le constructeur de mon autre thread, si j'initialise ailleurs ça marche.)

Je n'ai pas suffisamment d'éléments pour être catégorique, mais ce genre de crash non systématique ressemble fortement à un problème dû à une mauvaise synchronisation de threads... Attention au fait qu'il n'y a aucune garantie quant à l'ordre d'exécution des threads.

Il ne faut donc pas s'attendre à ce que le code s'exécute tel qu'il est écrit. Ca n'est pas parce qu'un thread T1 est lancé avant un thread T2 dans le code qu'il y a la garantie du système que T1 commencera bien à s'exécuter avant T2. C'est "possible", mais pas "certain". Avec de probables conséquences sur les ressources créées par un thread et accédées par un autre...

21

Système / Re : Re : Bug avec les threads. (Les mutex ne marchent pas dans un certain cas précis.)

« le: Août 05, 2013, 05:20:31 pm »

Bref je pense que je vais utiliser une variable booléenne plutôt qu'un mutex, ça ira surement mieux.

 

Un booléen, de base, n'est ni atomique, ni thread-safe... donc je ne vois pas trop comment il peut remplacer un mutex...

22

Système / Re : Bug avec les threads. (Les mutex ne marchent pas dans un certain cas précis.)

« le: Août 04, 2013, 11:34:25 am »

+1000 avec lefreut...

Le "bug" vient à 99,99% de ton code, et encore, en étant gentil ! En plus des conseils de lefreut, j'ajouterai que les accès concurrents mal gérés peuvent causer des crashs dont l'origine est parfois TRES difficile à identifier, pour lesquels même les debuggers se plantent lamentablement. Je parle en connaissance de cause. Moralité : éviter autant que possible les threads, sinon essayer de limiter au maximum les effets de bord en limitant les interactions entre threads, et en rendant le moindre booléen partagé atomique, et les mutex seulement quand c'est absolument nécessaire et en y réfléchissant bien afin d'éviter les interblocages et autres joyeusetés...

Sinon c'est l'usine à gaz assurée, avec un fonctionnement disons... aléatoire.

Enfin dernière chose : si ton code est sensé être portable, teste le bien sur toutes les plateformes cibles au fur et à mesure du développement, parce que rien que concernant la partie concurrente de ton programme, ça va marcher sur le système X, et sur Y pouf... plantage. Idem concernant les "stress tests"... ne pas les oublier parce que tes threads peuvent tourner nickel pendant 2h et tout planter à 2h01, ou bien fonctionner 8h sans souci un jour, et le lendemain planter toutes les 3 minutes.

23

Système / Re : [2.0] TextEntered jamais déclenché...

« le: Juillet 18, 2013, 12:01:31 am »

L'idée n'est pas mauvaise, mais l'un des objectifs à terme est de ne plus être dépendant de Qt. Je le conserve pour des questions pratiques comme par exemple la possibilité de créer rapidement de petites GUI me facilitant le pilotage du code à des fins de test, et d'ailleurs le problème rencontré avec TextEntered va surtout me conduire à passer directement par une fenêtre SFML pour le rendu OpenGL...

Merci encore pour ta réactivité.

24

Système / Re : [2.0] TextEntered jamais déclenché...

« le: Juillet 17, 2013, 10:00:50 pm »

Ok merci pour ta réponse.

J'avais du coup commencé à faire via KeyPressed, je vais continuer dans cette voie. Le surcoît de travail n'est de toute façon pas énorme, sachant que je n'ai pas besoin de tous les caractères ni de gérer toutes les touches.

Merci encore.

25

Système / Re : [2.0] TextEntered jamais déclenché...

« le: Juillet 17, 2013, 07:00:40 pm »

Merci pour ta réponse
Je suis sous Windows XP SP2.

Bon j'ai repris le code pour le tester, avec les résultats suivants :

- je créé une fenêtre avec SFML, je teste TextEntered, nickel, l'événement est bien émis.
- je créé une fenêtre avec Qt, et j'y place mon widget QSFMLCanvas (dont le code est presque identique à celui du tutorial trouvé là : http://sfml-dev.org/tutorials/1.6/graphics-qt-fr.php). Et là, avec une boucle d'événement identique au cas précédent, je ne récupère plus les TextEntered... par contre KeyPressed, KeyReleased, etc, fonctionnement très bien.

26

Système / [2.0] TextEntered jamais déclenché...

« le: Juillet 17, 2013, 02:12:40 am »

Bonsoir

Je travaille actuellement sur un projet top secret de la plus haute importance et j'ai choisi SFML 2.0 pour m'accompagner tout au long de son développement. Soit dit en passant, un grand bravo à ses développeurs pour le travail accompli dans tous les domaines, tant le résultat est bien chiadé !

Voici mon problème. Je dispose d'une fenêtre créée via Qt 4, intégrant un widget OpenGL sur base SFML. Dans cette fenêtre, j'ai donc un rendu 3D (moteur maison), et je viens d'y intégrer une petite console style Quake. Je récupère tous les évènements possibles dans cette fenêtre, notamment concernant le clavier. Jusque là, l'évènement KeyPressed me suffisait. Mais avec l'implantation de la console, j'ai besoin de récupérer l'événement TextEntered. Or, je n'y parviens point ! En gros chaque touche pressée produit juste un KeyPressed... Voici le code impliqué :

            void GLout::__GLLoop::exec() {
                sf::Event e;

                while (_gl_out->pollEvent(e))
                    if (e.type == sf::Event::Closed)
                        this->stop();
                    else if (e.type == sf::Event::Resized)
                        _gl_out->resize(e.size.width, e.size.height);
                    else
                        __parseEvent(e);

                _gl_out->repaint();
                _curr_loop++;
            }

            void GLout::__GLLoop::__handleKeyboard(const sf::Event &e) {
                if (e.type == sf::Event::TextEntered) {
                    console() << "te\n";
                    if (_gl_out->getGLConsole()->IsOpen()) {
                        _gl_out->getGLConsole()->KeyboardFunc(e.text.unicode);
                    }
                }

                if (e.type == sf::Event::KeyPressed) {
                    console() << "kp\n";
                    if (e.key.code == sf::Keyboard::Quote)
                        _gl_out->getGLConsole()->ToggleConsole();
                       
                    if (!_gl_out->getGLConsole()->IsOpen())
                        _busclient.broadcast<sf::Event::KeyEvent>(CHANNEL_0, TYPE_EVENT_KEYPRESSED, e.key, PRIORITY_HIGH);
                }

                if (e.type == sf::Event::KeyReleased)
                    _busclient.broadcast<sf::Event::KeyEvent>(CHANNEL_0, TYPE_EVENT_KEYRELEASED, e.key, PRIORITY_HIGH);
            }

            void GLout::__GLLoop::__parseEvent(const sf::Event &e) {
                __handleKeyboard(e);
                __handleMouse(e);
                __handleJoystick(e);
            }

Si quelqu'un a une idée je suis preneur...
Merci