Chute violente de FPS incompréhensible

[GalliezB]

Bonjour,

J'suis étudiant en informatique. Je viens de terminer ma 1ere année ou j'ai réalisé un jeu avec Openframework. Certains projet en SFML m'ont donné l'envie de tester cette librairie pendant les vacances.

Mais voila, j'en suis à découvrir le librairie, faire un max de test, et rien ne va côté FPS. Ce qui saccade le déplacement d'une simple sprite. En afficher 1 ou 10 revient au même. Tout déplacement crée cette chute de FPS inexpliqué.

Voici le code que j'utilise pour expérimenter SFML :

#pragma once
#include <iostream>
#include <SFML/Graphics.hpp>

#define PATHIMG "../expansion/img/"

#pragma region globalVariable
int globScreenWidth = sf::VideoMode::getDesktopMode().width;
int globScreenHeight = sf::VideoMode::getDesktopMode().height;
bool globToggleFullScreen = false;
bool globToggleVisible = false;
sf::Texture textureVaisseau;
sf::Sprite spVaisseau[12];
sf::Clock horloge;
#pragma endregion globalVariable


int main(){

        bool boucleMenu = true;

        // chargement fichier image
        if (!textureVaisseau.loadFromFile(PATHIMG"vaisseau.png", sf::IntRect(0, 0, 2000, 2000))){
                std::cout << "ERREUR : vaisseau.png not load properly\n";
        } else {
                for ( int i=0; i<12; i++){
                        spVaisseau[i].setTexture(textureVaisseau);
                        spVaisseau[i].setTextureRect(sf::IntRect(0,500,89,52));
                        spVaisseau[i].setPosition(1720,0+i*75);
                }
        }

        // gère la fenêtre SFML
        sf::RenderWindow window;
        window.create(sf::VideoMode(1920, 1080), "Test sprite SFML", sf::Style::Fullscreen);
        window.setVerticalSyncEnabled(true);
        window.setFramerateLimit(60);

        while(boucleMenu){

                // temps écoulé
                sf::Time frameTime = horloge.restart();
                std::cout << 1/frameTime.asSeconds() << "\n";


                sf::Event event;
                // boucle d'évènements
                while(window.pollEvent(event)){

                        // FERMETURE de la fenetre
                        if (event.type == sf::Event::Closed || event.key.code == sf::Keyboard::Escape){

                                // ferme la fenêtre de jeu
                                window.close();
                                // stop le jeu
                                boucleMenu=false;

                        }

                }

                for ( int i=0; i<12; i++){
                        spVaisseau[i].move(sf::Vector2f(-60*frameTime.asSeconds(),0));
                }


                // Affichage
                window.clear();
                for ( int i=0; i<12; i++){
                        window.draw(spVaisseau[i]);
                }
                window.display();
        }

        return 0;

}
 

Et voici la sorti de la console sur le FPS ( Numéroté ) :

1° : 2.89898
2° : 5.93845
3° : 59.1821
4° : 58.1564
5° : 59.805
[...]
92° : 3.5003
[...]
224° : 1.62336
225° : 58.9102
226° : 60.6171
227° : 59.3085
228° : 59.2593
229° : 2.40299
230° : 59.5593
231° : 59.9305
232° : 59.9772
233° : 59.4036
234° : 60.9384
235° : 55.8254
236° : 61.5839
237° : 0.287148
238° : 59.2628
[...]
803° : 60.3136
804° : 0.130179
805° : 59.5203

Ce qui donne le graphique suivant :




Ces chutes de FPS se ressente forcement sur les objets en mouvements. Et ici j'en ai pas des tonnes.
J'ai essayé avec les vertex, et j'ai le même soucis.

Une idée d'ou cette chute peut provenir ?

[kimci86]

Bonjour et bienvenue sur le forum.

Le problème ici est que tu utilises à la fois setVerticalSyncEnabled et setFramerateLimit. Il ne faut pas le faire. Cela est expliqué dans le tutoriel Ouvrir et gérer une fenêtre SFML.

[GalliezB]

Bonjour,

Oui j'avais lu ceci aussi, et c'est pour cela que les deux lignes étaient présentes. Ce sont des vestiges des tests que j'ai fait en utilisant les commentaires pour tester le retour de l'un et de l'autre.

le problème c'est qu'un :

window.setVerticalSyncEnabled(true);

Crée un mouvement fluide mais des chutes aléatoire de fps, tout comme des pics pouvant atteindre les 2000 fps.

Alors qu'un :

window.setFramerateLimit(60);

Crée un déplacement fluide, un fps + ou - constant ( aucune chute mais des pics élevé non gênant ) mais ou plusieurs éléments en ligne se déplacent sans être synchronisés. Ce qui créée l'équivalent d'une vague faites par les supporters lors d'un match.


J'ai changé ceci :

window.create(sf::VideoMode(1920, 1080), "Test sprite SFML", sf::Style::Default);

Et le soucis de chute de fps a disparu, que ce soit en utilisant setVerticalSyncEnabled ou setFramerateLimit

j'suis un peu paumé la

[victorlevasseur]

Salut,

Ton test de sf::Event n'est pas bon, il faut tester d'abord si c'est un sf::Event de type "KeyPressed" ou "KeyReleased" avant de tester la valeur de event.key.code (sinon, elle peut contenir n'importe quoi).

Je ne sais pas si ça résoudra ton problème mais ça pourra t'éviter de futurs problèmes.

[GalliezB]

Je comprend pas la. Même si ce n'est pas une touche pressé et qu'il contient n'importe quoi, il ne sera jamais égale a sf::Keyboard::Escape. Alors pourquoi tester avant si c'est une touche pressé ?

tu fais comme ça toi ?

event.type == sf::Event::Closed || (event.type == sf::Event::KeyReleased && event.key.code == sf::Keyboard::Escape)

Je repensais à quelque chose que j'avais lu dans http://www.sfml-dev.org/tutorials/2.0/window-window-fr.php

Sous Windows, une fenêtre plus grande que le bureau ne réagira pas correctement

Pour une raison inconnue, Windows n'aime pas les fenêtres qui sont plus grandes que le bureau. Cela inclue les fenêtres créées avec VideoMode::getDesktopMode() : avec les décorations (bordures et barre de titre) en plus, vous finissez avec une fenêtre qui est très légèrement plus grande que le bureau.

Comment existe la fenêtre en fullscreen ? Avec ses bordures et son entête ?


Car si je passe la fenêtre en 800* 600 et que je la colle en fullscreen, j'ai plus aucune chute de fps. Mais toujours ces foutus saccades dans le déplacement d'une sprite.

Je trouve ça aberrant d'avoir des saccades sur un simple test. J'ai retesté sous open framework, et j'ai pas lag, pas une saccade. J'ai donc dû merder quelque part avec SFML... Mais pas moyen de trouver.

[victorlevasseur]

Je comprend pas la. Même si ce n'est pas une touche pressé et qu'il contient n'importe quoi, il ne sera jamais égale a sf::Keyboard::Escape. Alors pourquoi tester avant si c'est une touche pressé ?

Si t'as pas de chance, le "n'importe quoi" vaudra sf::Keyboard::Escape (qui n'est qu'un entier du point de vue du PC) et ton jeu se fermera.

tu fais comme ça toi ?

Oui

Comment existe la fenêtre en fullscreen ? Avec ses bordures et son entête ?

Le style Fullscreen enlève les bordures et l'en-tête. Le paragraphe que tu as lu dans le tutoriel est pour les fenêtres "normales".

[Cpl.Bator]

je vais peut être dire une bêtisse, mais je me lance quand même , pourquoi utilise tu
std::cout pour l'affichage du framerate ? ca implique une deuxième fenêtre ( la console win32 ) , std::cout doit certainement repasser la main à l'os pour mettre a jour celle ci , d'ou les saccades ? de plus, j'ai observé avec msys & mingw un soucis que j'ai pas réussi à reproduire lorsque j'utilisait "\n" a la place de std::endl ( la console ne se mettait pas à jour ) , et pas besoin d'afficher le framerate à tout les tours de boucles , tu floods la console.
met a jour ta console toute les secondes.

[victorlevasseur]

Pas faux. Il me semble avoir déjà remarqué que la console ralentissait les traitements sur Windows (beaucoup moins le cas sur Linux).

[GalliezB]

Bonjour,

J'ai recrée un projet, n'étant pas sûr de l'installation, et la chute de fps a disparu avec la réinstallation. Pour le moment, je suis en dynamique, je dois encore faire des tests en statique. Est-ce que j'avais merdé quelque chose de ce côté la ?

En changeant le code par :

if ( horloge2.getElapsedTime().asSeconds() > 1 ){
        std::cout << 1/frameTime.asSeconds() << std::endl;
        horloge2.restart();
}
 

Les mouvements sont plus fluides mais de légère saccades restent malheureusement présentes. Comme les déplacements sont fixé sur le temps, on sent bien qu'il rattrape le temps perdu. C'est devenu minime, mais c'est agaçant et surtout inquiétant. Car si avec 12 sprites, j'ai des saccades, qu'en sera-t-il lorsque j'ajouterai d'autres choses ?

En écrivant ce post, je me rends compte que je dois vérifier le retour de

frameTime.asSeconds()

qui gère justement les distances de déplacement selon le temps. Et que j'appelle trop souvent. De ce fait, je mets le résultat dans un float que j'utilise à la place, et la plus aucune saccade ! J'suis un peu paumé sur ça, et je sais pas pourquoi.

mais toujours uniquement avec

window.setVerticalSyncEnabled(true);

si je le remplace par un :

window.setFramerateLimit(60);

j'ai vraiment un résultat dégueulasse ou on voit cette ondulation qui part du haut vers la bas.

[Cpl.Bator]

pense aussi a mettre tes drivers a jour de ta carte graphique , on ne sait jamais.
d'autre part, quand j'utilise la sfml, j'utilise toujours la résolution du bureau en fullscreen & je downscale avec les vue ou un "RenderTexture".  et pas de soucis de saccade. et je n'utilise pas setVerticalSyncEnabled ou setFramerateLimit avec un déplacement dans le temps comme tu le fait. ca n'a pas de sens pour moi. je laisse tourné le programme au maximum puis je déplace mes objets comme tu le fait , avec le deltatime & pas de lag , c'est fluide.

[GalliezB]

Niveau Driver ça roule, c'est à jour.

J'suis pas sûr de te suivre. Je débute hein ^^
Ici je suis en 1980*1080. Tu crée donc la fenêtre à cette taille, et tu utilise sf::view pour descendre en résolution genre 1280*1024 ?
Je suppose que moins de pixel = moins de calcul pour l'affichage ?


Si je veux limiter le fps, c'est surtout car j'ai vu des pointes allant jusqu’à ~4000. Et je vois pas l'intérêt de faire autant de calcul et d'envoyer autant d'affichages puisque mon écran est en 60Hz.

[Cpl.Bator]

Si je veux limiter le fps, c'est surtout car j'ai vu des pointes allant jusqu’à ~4000. Et je vois pas l'intérêt de faire autant de calcul et d'envoyer autant d'affichages puisque mon écran est en 60Hz.

Ton écran n'ira pas jusqu'a 4000hz , il sera capé à 60hz. le reste, c'est du potentiel de calcul pour ton application.
ne la bride pas.

Ici je suis en 1980*1080. Tu crée donc la fenêtre à cette taille, et tu utilise sf::view pour descendre en résolution genre 1280*1024 ?
Je suppose que moins de pixel = moins de calcul pour l'affichage ?

c'est surtout pour gérer les résolutions différentes, mon système est plus complexe, mais le principe est là.
je créer une fenetre à la taille du bureau , je calcul le ratio w/h , je sous dimensionne ou sur dimensionne en appliquant le ratio a la taille de ma vue

res = 1680x1050
ratio = 1.6
taille vue = h = 720px , l = 720 * ratio

ca me permet de gardé les même proportions.

[GalliezB]

c'est surtout pour gérer les résolutions différentes, mon système est plus complexe, mais le principe est là.
je créer une fenetre à la taille du bureau , je calcul le ratio w/h , je sous dimensionne ou sur dimensionne en appliquant le ratio a la taille de ma vue

res = 1680x1050
ratio = 1.6
taille vue = h = 720px , l = 720 * ratio

ca me permet de gardé les même proportions.

Si tu ouvre une fenêtre en 800*600 et que tu la mets en fullscreen, c'est exactement ce que fait le sf::view non ?
En passant par tes propres calculs, tu t'évite les déformations pour le passage d'un 16/9 à un 4/3 par exemple ?