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
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.
Pages: « Précédente 1 [2] 3 4 ... 7 Suivante »
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?
ou je suis a coté de la plaque?
18
Discussions générales / Re : Un livre sur SFML -- recherche d'auteur(s) !
« le: Octobre 25, 2012, 06:56:39 pm »
Salut
je lis le topic anglais et je vois:
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 peopleDonc 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 »
c'est ptet ça http://fr.sfml-dev.org/forums/index.php?topic=9104.0 ?
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...
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?
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...
"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
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?
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....
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;
};
//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!
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 »