Bienvenue, Invité. Merci de vous connecter ou de vous inscrire. Avez-vous oublié d'activer ?

Voir les contributions

Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.


Messages - lezebulon

Pages: « Précédente 1 [2] 3 4 ... 7 Suivante »
16
Graphique / Re : sprite.draw qui prend du temps
« le: Octobre 26, 2012, 12:37:15 pm »
je suis sur PC mais c'était bien un pb de render texture et de drivers intel, c'est pour ça

17
Graphique / Re : sprite.draw qui prend du temps
« le: Octobre 26, 2012, 11:19:22 am »
question : en fait ça vient de ça http://en.sfml-dev.org/forums/index.php?topic=9149.0 ?
ou je suis a coté de la plaque?

18
Salut
je lis le topic anglais et je vois:
Citer
Packt is planning to publish a book on SFML, titled SFML Game Development . This book will be showing people how to use this emerging API to make their game programming easier so that they can focus on gameplay, and creating projects they can use in a portfolio or just show to other people
Donc en gros ce qu'ils veulent ce sont des gros tuto sur comment faire un "mini" moteur qui soit déjà tout prêt pour tel ou tel type de jeux? Enfin c'est comme ça que j'imagine ce qu'ils veulent, plutôt que un bouquin qui soit comme une doc

19
Graphique / Re : Ecran blanc & loadFromMemory
« le: Octobre 18, 2012, 02:58:45 pm »
ouais mais le operator[] ne jette pas d'exception et il va te construire un objet par défaut quand il trouve pas la clé...

20
Graphique / Re : freeze & app.Draw()
« le: Septembre 28, 2012, 07:18:17 pm »

21
Audio / Re : Capture et analyse d'un son -> souffle SFML et c++
« le: Septembre 24, 2012, 06:39:22 pm »
lol
désolé mais ça me fait marrer ton truc, c'est clairement pas trivial du tout...
en gros ça correspond à ce que j'ai fait l'an dernier en M2 en traitement du signal (enfin en bcp

plus simple, mais pour te donner une idée)


bref :
- tu commences par définir une fenêtre de temps de genre ~15 ms, tu récupères un tableau de valeurs

qui correspondent à autant de samples que ce que tu peux récupérer en 15 ms (je ne sais pas à quelle

fréquence le son est samplé)

- tu fais une transformé de fourrier sur cet échantillon, ça te donne un tableau d'autant de points

qui te montre la répartition en fréquence. Je pense pas que tu ais besoin d'une lib pour faire ça, au

final le calcul est assez basique. (bon ton truc sera plus lent mais là je pense pas que le

traitement soit intensif)

- à partir de là tu affiches la transformé de fourier sur SFML tu va jamais t'en sortir

- tu t'enregistres en train de souffler et tu répères où sont les pics en fréquence. Avec du bol tu auras un truc qui sera relativement distinct des autres sons

- une fois que tu as défini à quoi ressemblait ton souffle "de référence" tu peux stocker sa transformé de fourrier dans ton programme et puis comparer chaque transformé captée via le micro avec ton truc de référence, si c'est suffisament proche -> c'est bon!

- là où ça devient encore plus complexe ton truc c'est qu'il faut détecter aussi le début / arrêt du souffle, donc une fois que tu as détecté le souffle sur une période d'échantillonage, tu dois dire à la prochaine on s'est arrété ou pas


bref y'a de quoi faire un bon sujet de stage...


22
Graphique / Re : sprite.draw qui prend du temps
« le: Septembre 20, 2012, 09:41:58 pm »
je remonte le sujet une dernière fois...
j'imagine qu'il n'y a rien à faire à part avoir un PC moins pourri?

23
Graphique / Re : sprite.draw qui prend du temps
« le: Septembre 17, 2012, 10:36:56 pm »
Oui je viens d'updater à l'instant, idem

24
Graphique / Re : Re : sprite.draw qui prend du temps
« le: Septembre 17, 2012, 10:21:51 pm »
>Est-ce que tes pilotes graphiques sont à jour ? Quelle est ta carte graphique ?
"Mobile Intel 4 Series Express Chipset Family" d'après le panneau de config. C'est un chipset intégré à la carte mère je pense, je suis sur un portable (c'est ptet juste ça le pb)

>Est-ce que ça change quelque chose si tu crées la render-texture après la fenêtre ?
Non, pareil

>Si tu fais un draw avant d'entrer dans la boucle principale, tout va bien c'est ça (à part pour ce draw là) ?
Là ça me prend 80 ms au lieu de 300 ms, c'est mieux mais ça me parait quand même relativement long pour ce que je fais

>Et si tu fais un clear/display au lieu d'un draw/display dans ton test, ça lag aussi ?
non là c'est instantané


Bref je pense que c'est ma CG qui gère mal l'open gl...

25
Graphique / Re : sprite.draw qui prend du temps
« le: Septembre 17, 2012, 03:20:29 pm »
ok mais je ne pense pas que ça change le comportement de ce que j'ai posté non?
J'ai mis la boucle d'event sur le code que j'ai chez moi, je l'ai enlevé en postant pour alléger le tout

edit : j'ai édité le code avec la gestion des event

26
Graphique / Re : sprite.draw qui prend du temps
« le: Septembre 17, 2012, 02:42:26 pm »
hello...
personne pour executer le code plus haut et me dire si ils ont aussi un ralentissement?

27
Graphique / Re : sprite.draw qui prend du temps
« le: Septembre 16, 2012, 05:59:46 pm »
Petit exemple qui reproduit le pb :
quand le curseur touche le carré au milieu pour la 1ere fois, j'ai un lag de 250 ms....
int main() {
       
        //initial sprite we want to draw
        sf::Texture sheet_to_draw;
        sf::Sprite sprite_to_draw;
        sprite_to_draw.setTexture(sheet_to_draw);
        sprite_to_draw.setPosition(100,100);

        //intermediate sf::RenderTexture
        sf::RenderTexture intermediate;
        sf::Sprite intermediate_sprite;
        intermediate.create(100,100);
        intermediate.clear(sf::Color(100,130,100));
        intermediate_sprite.setTexture(intermediate.getTexture());
        intermediate_sprite.setPosition(100,100);

        //main rendering window
    sf::RenderWindow App(sf::VideoMode(800, 600, 32), "SFML Graphics");
    clock_t start = clock();
        clock_t  end = clock();


        sf::FloatRect MainView(0, 0, 10, 10);
        sf::RectangleShape rectangleCamera(sf::Vector2f(10,10));
        rectangleCamera.setSize(sf::Vector2f(10,10));
        rectangleCamera.setOutlineThickness(1);
        rectangleCamera.setOutlineColor(sf::Color::Red);
        rectangleCamera.setFillColor(sf::Color::Transparent);


        while (App.isOpen())
    {

        // on inspecte tous les évènements de la fenêtre qui ont été émis depuis la précédente itération
        sf::Event event;
        while (window.pollEvent(event))
        {
            // évènement "fermeture demandée" : on ferme la fenêtre
            if (event.type == sf::Event::Closed)
                window.close();
        }

        App.clear(sf::Color(0,0,0));
                rectangleCamera.setPosition(sf::Mouse::getPosition(App).x-5,sf::Mouse::getPosition(App).y-5);
                MainView.left = sf::Mouse::getPosition(App).x-5;
                MainView.top = sf::Mouse::getPosition(App).y-5;


                //will lag when this condition is true:
                if(MainView.intersects(sf::FloatRect(100,100,100,100))) {
                        intermediate.draw(sprite_to_draw);
                        intermediate.display();
                }

                App.draw(intermediate_sprite);
                App.draw(rectangleCamera);
                end = clock();
                if( end-start > 5)
                        std::cout << (end-start)<<" ms \n";
                start = end;

       
                App.display(); 
    }

    return EXIT_SUCCESS;

};

28
Discussions générales / Re : Blog de développement - sfml
« le: Septembre 14, 2012, 06:32:57 pm »
 SpriteComponent::key() | TransformableComponent::key();
Là tu vas toujours appeller la même méthod component::key() non? Enfin y'a pas de statique virtuelle en C++

29
Graphique / Re : sprite.draw qui prend du temps
« le: Septembre 14, 2012, 05:53:42 pm »
En fait ça se passe pas au loading mon pb
les sf::rendertexture de cache sont crées au chargement de l'appli (c'est instantanné)
C'est quand je fais le premier appel à Draw() avec un sprite sur ce sf::rendertexture que ça prend 300 ms, même pour un sprite de 2x2 pixels
après pour les autres draws sur le meme rendertexture ça me prend moins de 1 ms.
Tout le but de faire des rendertexture intermédiaires c'est de pouvoir dessiner tile par tile dessus au fur et à mesure que la caméra se déplace, donc si je charge tout au démarrage ça sert plus à rien!

30
Graphique / Re : sprite.draw qui prend du temps
« le: Septembre 12, 2012, 12:17:50 am »
Si elles sont créées à la création de la map, mais le "lag" de 300 ms apparait quand je dessine dessus la 1ere fois

Pages: « Précédente 1 [2] 3 4 ... 7 Suivante »
anything