Commentaires sur une source : LIMITER NOMBRE FPS [OPENGL & QUERYPERFORMANCE & DEVCPP]

cs_Kirua Messages postés 3006 Date d'inscription dimanche 14 avril 2002 Statut Membre Dernière intervention 31 décembre 2008
17 déc. 2005 à 14:02

Tiens donc, celui qui nous a tous convertis à GLFW est encore vivant :)

Funto66 Messages postés 1267 Date d'inscription mercredi 1 janvier 2003 Statut Membre Dernière intervention 28 février 2007 4
17 déc. 2005 à 11:42

Juste un bémol, chez moi en tous cas, GLFW n'a pas voulu reconnaître mon joystick, alors que SDL si...(NB : je parle sous Linux, la version Win32 fonctionnait).

Mais sinon c'est mon framework préféré :)

cs_Kirua Messages postés 3006 Date d'inscription dimanche 14 avril 2002 Statut Membre Dernière intervention 31 décembre 2008
11 déc. 2005 à 21:22

Je confirme, GLFW a été la réponse à la majorité de mes soucis en matière de fenêtre OpenGL. Elle est même équipée d'un support de thread portables, d'un loader de TGA et de toute la gestion clavier / souris / joystick. A découvrir absolument ;)

Utilisateur anonyme
11 déc. 2005 à 19:07

De rien ^^

Le seul défaut de cette librairie c'est de ne pas être très connue, mais elle le mériterait...

BeLZeL Messages postés 110 Date d'inscription mardi 10 octobre 2000 Statut Membre Dernière intervention 20 décembre 2005
11 déc. 2005 à 17:46

J'achète ;)

Comme quoi, on en apprend tous les jours.
Je ne connaissais pas, merci :)
J'espère que j'arriverai à faire marcher la souris sous Linux avec ce framework ...

Utilisateur anonyme
11 déc. 2005 à 16:10

Bin tu peux utiliser GLFW, qui remplace Glut et qui a une fonction glfwGetTime() qui donne un timestamp en secondes (donc de type "double") avec une précision qui dépends de la plateforme. Mais bon sur un pc pas trop vieux on (en général) une précision de l'ordre de la nanoseconde.

BeLZeL Messages postés 110 Date d'inscription mardi 10 octobre 2000 Statut Membre Dernière intervention 20 décembre 2005
30 sept. 2005 à 22:03

Je cherche un équivalent des fonctions QueryPerformanceCounter QueryPerformanceFrequency, sous Linux ...

BeLZeL Messages postés 110 Date d'inscription mardi 10 octobre 2000 Statut Membre Dernière intervention 20 décembre 2005
16 sept. 2004 à 21:51

Voilà, j'ai fait une update du prog et il fonctionne à merveille. Merci pour vos conseils.

BeLZeL

BeLZeL Messages postés 110 Date d'inscription mardi 10 octobre 2000 Statut Membre Dernière intervention 20 décembre 2005
11 sept. 2004 à 15:51

Oki doki.

Je vais voir comment implémenter ces fonctions.

BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019
11 sept. 2004 à 15:12

QueryPerformanceCounter()
QueryPerformanceFrequency()
sont effectivement les mesures les plus fiables sur Windows. Elles consomment egalement moins de cycles que les fonctions classiques de la CRT qui sous Windows finissent dans tous les cas par les appeler.

CRAzy-flaSH Messages postés 14 Date d'inscription lundi 20 octobre 2003 Statut Membre Dernière intervention 11 septembre 2004
11 sept. 2004 à 14:43

Je crois que les fonctions qui permettent d'être plus précises au niveau du temps sont les suivantes :

QueryPerformanceCounter()
QueryPerformanceFrequency()

Je ne sais pas du tout ce qu'il en est de leur portabilité mais je crois savoir qu'elles sont plus gourmantes que des fonctions de temps plus traditionnelles.

Le mieux est sûrement de limiter le nombre maximum de fps pour ne pas arriver dans des temps trop petits et donc trop imprécis puis d'utiliser des fonctions traditionnelles...

Mais si quelqu'un s'y connait mieux sur ce qu'il est conseillé de faire, ça m'intéresse également ;)

cs_djl Messages postés 3011 Date d'inscription jeudi 26 septembre 2002 Statut Membre Dernière intervention 27 novembre 2004 7
9 sept. 2004 à 19:02

ca se fais a base d'appels systeme, et oui peux savoir le cout en cycle de cetraine instructions

je crois meme que c'est frequent de mesurer la vitesse des instructions avec cette technique, doit y avoir un source de brunews la dessus

Funto66 Messages postés 1267 Date d'inscription mercredi 1 janvier 2003 Statut Membre Dernière intervention 28 février 2007 4
9 sept. 2004 à 18:58

Hmm j'en doute quand même, imagine déjà pour récupérer le nombre de cycles du fias comment?
Et puis aussi avec le multitasking, plusieurs applications à la fois, qui bouffent chacunes des cycles CPU, tu peux pas calculer uniquement par rapport à ton prog...

Enfin qui sait si c'est possible...mais si ça l'est ça m'étonnerait que ça soit portable dans tous les cas ^^

cs_djl Messages postés 3011 Date d'inscription jeudi 26 septembre 2002 Statut Membre Dernière intervention 27 novembre 2004 7
9 sept. 2004 à 18:52

mais peut etre aussi que dans les jeu on syncrhonise a partir de la frequence / nombre de cycle pour garder un precision absolue

Funto66 Messages postés 1267 Date d'inscription mercredi 1 janvier 2003 Statut Membre Dernière intervention 28 février 2007 4
9 sept. 2004 à 18:44

"Le problème, c'est que sur ma machine, le temps écoulé (pour afficher un cube simple) est parfois inférieur à 1 ms (j'ai plus de 1500 FPS avec ce programme). Je n'ai donc pas assez de précision pour utiliser le temps écoulé entre deux frames."
!!!
Ouah ! Ben là alors on doit faire comment? parce que c'est pénalisant ça, si on veut trouver un système "universel"...
Je pensais pas que le système qui consistait à faire les calculs en fonciton du temps écoulé avait ce défaut-là :(

En fait peut-être que le mieux serait de limiter les FPS ET de faire les calculs selon le temps écoulé? Comme ça, avec la limite des FPS à un nombre assez élevé, tu peux profiter de la puissance de ta machine tout en n'ayant pas de pb avec le timer non?

cs_djl Messages postés 3011 Date d'inscription jeudi 26 septembre 2002 Statut Membre Dernière intervention 27 novembre 2004 7
9 sept. 2004 à 13:03

dans le fichier BASEQ3/q3config.cfg, la ligne
seta com_maxfps

permet de fixer le framerate max

BeLZeL Messages postés 110 Date d'inscription mardi 10 octobre 2000 Statut Membre Dernière intervention 20 décembre 2005
9 sept. 2004 à 12:33

Concernant Q3A, en fait la physique changeait selon le nombre de FPS. Si tu avais un FrameRate bloqué à 125 FPS, tu pouvais sauter à 66 unités de haut, alors que sinon, tu ne pouvais pas sauter plus de 63 unités voir moins.

Ca autorisait quelques tricks sympatiques, notamment pour choper la mégavie d'en bas dans la Q3DM13.

Sinon des jeux récent comme NFSU bloque le FrameRate selon des paliers. Impossible de dépasser les 60 FPS, et si ca rame trop, on passe à 30. Probablement parce que le jeu à été développé avant sur console.

cs_djl Messages postés 3011 Date d'inscription jeudi 26 septembre 2002 Statut Membre Dernière intervention 27 novembre 2004 7
9 sept. 2004 à 11:42

ca depends comment la synchro est gerer, mais dans certains jeux (notament q3 ou les fps pouvais alller tres tres haut) le comportement du physique a tendance a changer, typiquement dans q3 a partir de 120 - 130 fps la jouablité change et c'etait penalisant pour ceux qui etait dans les 60 -80, je sais pas a quoi c'etait du (synchro pas parfaite ?) mais n'empeche que dans doom3 carmach a decider de limiter les fps en multi joueur

c'est le seul exemple que je connaisse mais il doit y en avoir d'autres

NoRabbit Messages postés 224 Date d'inscription samedi 26 juillet 2003 Statut Membre Dernière intervention 30 mars 2009
9 sept. 2004 à 11:35

djl : peux tu donner un exemple ? j'aimerais mieux comprendre.

tkx

cs_djl Messages postés 3011 Date d'inscription jeudi 26 septembre 2002 Statut Membre Dernière intervention 27 novembre 2004 7
9 sept. 2004 à 11:01

NoRabbit > limiter les fps, je peux au moins t'assurer que ce n'est surement pas pour assurer la meme vitesse quelque soit la machine (en principe on synchronise avec le temps)

la limitationde framerate est par exemple utilisé dans doom3 pour reduire les inegalité en mode multijoueurs

BeLZeL Messages postés 110 Date d'inscription mardi 10 octobre 2000 Statut Membre Dernière intervention 20 décembre 2005
8 sept. 2004 à 22:55

Concernant le temps écoulé entre deux frames. C'est effectivement une très bonne méthode. Le problème, c'est que sur ma machine, le temps écoulé (pour afficher un cube simple) est parfois inférieur à 1 ms (j'ai plus de 1500 FPS avec ce programme). Je n'ai donc pas assez de précision pour utiliser le temps écoulé entre deux frames.

Funto66 Messages postés 1267 Date d'inscription mercredi 1 janvier 2003 Statut Membre Dernière intervention 28 février 2007 4
8 sept. 2004 à 19:13

Perso j'utilise la même méthode que NoRabbit, en général avec SDL_GetTicks().
T'as un exemple ici : http://perso.wanadoo.fr/funto/BaseCode2.rar
et un autre là : http://perso.wanadoo.fr/funto/BaseCode.zip

cs_Kirua Messages postés 3006 Date d'inscription dimanche 14 avril 2002 Statut Membre Dernière intervention 31 décembre 2008
8 sept. 2004 à 18:50

pas pour un RPG en 2D non temps-réel: j'évite de devoir faire des calculs en fonction du temps (et par la même de devoir passer le temps en paramètre de toutes les fonctions!), tout en gardant une vitesse constante sur tous les ordinateurs et en répartissant les frames de façon équilibrée (c'est pas 33 et puis plus rien jusqu'à la fin de la seconde, c'est 33 tout au long de la seconde).

En fait, cette méthode est mauvaise EN GENERAL, mais dans ce cas précis, elle est la plus adéquate (je pense).

NoRabbit Messages postés 224 Date d'inscription samedi 26 juillet 2003 Statut Membre Dernière intervention 30 mars 2009
8 sept. 2004 à 18:32

...je ne comprends pas, faut que tu m'expliques pourquoi tu cherches à limiter le nombre de fps...
c'est vraiment la dernière chose à faire...

NoRabbit Messages postés 224 Date d'inscription samedi 26 juillet 2003 Statut Membre Dernière intervention 30 mars 2009
8 sept. 2004 à 18:29

... ;) sorry, j'ai pas tout lu...

cs_Kirua Messages postés 3006 Date d'inscription dimanche 14 avril 2002 Statut Membre Dernière intervention 31 décembre 2008
8 sept. 2004 à 18:25

c'est exactement ce que j'ai dit juste avant.

"...une simulation physique (souvent le cas ds les jeux d'ailleurs) qui demandent de pvr dessiner avec des temps différents, et d'ailleurs de ne pas faire des déplacements égaux à chaque frame, mais des déplacements dépendant du temps depuis la dernière frame..."

NoRabbit Messages postés 224 Date d'inscription samedi 26 juillet 2003 Statut Membre Dernière intervention 30 mars 2009
8 sept. 2004 à 18:04

une autre méthode consiste à calculer les différents changements / opérations en fonction du temps écoulé entre chaque itération de la boucle.
Imaginons un cube qui se déplace de 5 à chaque itération. Le temps écoulé est de 12 ms.
Pour éviter que ce cube se déplace plus rapidement sur une machine plus puissante (FPS plus élevé), il suffit de calculer son déplacement en fonction des 12 ms (bien entendu ces 12 ms peuvent changer à chaque itération de la boucle)
Ce qui nous fait --> cube.x = cube.x + 5 * Var_TpsEcoule (= temps écoulé...)
Le cube se déplace à la même vitesse sur n'importe quelle machine et il n'est plus nécessaire de limiter la fréquence d'affichage qui peut parfois (souvent) créer des problèmes lors de la synchronisation des évènements comme pour dans un jeu en réseau par exemple...

Voilà, c'est la méthode que j'utilise pour le moment.
Elle est parfois plus problèmatique dans certaines situations, mais elle permet une utilisation plus souple, complète...

cs_Kirua Messages postés 3006 Date d'inscription dimanche 14 avril 2002 Statut Membre Dernière intervention 31 décembre 2008
8 sept. 2004 à 07:46

en fait, ts les deux vous effectuez un nombre maximum de fois les fct de gestion clavier et du jeu (physique...) mais vous ne dessinez pas tjs les nouvelles infos. c'est mieux, j'imagine.

au fait, ac ta méthode belzel, tu devrais pê remettre le compteur initial (celui du début du jeu) à clock() (tps actuel) de tps à autre, genre toutes les 5s, pour éviter que le temps de chargement du début du jeu n'aient de répercussions sur la moyenne pdt tte la partie.

BeLZeL Messages postés 110 Date d'inscription mardi 10 octobre 2000 Statut Membre Dernière intervention 20 décembre 2005
7 sept. 2004 à 23:27

Si la machine est puissante, l'affichage sera limité par un nombre précis, comme tu l'as dit.

A chaque appel à la fonction Draw (qui dessine avec OpenGL), il y a le nombre d'images qui s'incrémente et le temps qui est mis à jour. Normal.

Je me suis basé sur une moyenne du nombre de FPS :
images (affichées depuis le lancement) / temps en seconde (écoulé depuis le lancement)

Si la moyenne est inférieur à MAX_FPS, on peut afficher de nouvelles images (et incrémenté le nombre d'images et on fait une MAJ du temps).

Si la moyenne est supérieur (ou égal) à MAX_FPS, on n'affiche rien (on fait juste une MAJ du temps). Si bien qu'à un moment donné (un moment très court), la moyenne redeviendra inférieure, obligatoirement.

On passe des miliers de fois (pour ne pas dire des dizaines de milliers de fois) dans la fonction Draw, mais on affiche qu'un nombre précis d'image. Le programme ne bloque pas, c'est à dire qu'on peut toujours faire quelque chose pendant qu'on affiche rien (il faudrait rajouter un else dans Draw()). Je ne crois pas que ca doit être pareil pour ta boucle while (qui devrait être bloquante), mais c'est vrai que ca semble plus simple :) Je me suis peut-être compliqué la vie, ce ne sera pas la première fois ;)

cs_djl Messages postés 3011 Date d'inscription jeudi 26 septembre 2002 Statut Membre Dernière intervention 27 novembre 2004 7
7 sept. 2004 à 23:26

dois y avoir plus simple, si tu es en double frame buffer tu swap seulement quand tu es dans les delais, c'est plus coherent (pas de pause)

cs_Kirua Messages postés 3006 Date d'inscription dimanche 14 avril 2002 Statut Membre Dernière intervention 31 décembre 2008
7 sept. 2004 à 22:46

Je n'ai pas lu le code, mais si j'ai bien compris l'explication, sur un ordinateur rapide, si tu limites à 30FPS et que l'ordi est capable d'en faire 60, il va faire 30 images pdt 0.5s, et puis plus rien pdt 0.5s? j'imagine que ce n'est pas ça. ça marche comment (en fait? :p).

sinon, moi je fais comme ça:

const int DELAI = 30; //délai min en ms entre deux frames
clock_t tpsfps = 0; //temps mesuré lors du dernier affichage, clock_t est une structure de <ctime>, cf une référence sur internet

dans la main loop:

while(clock() - clkfps < DELAI); //ne fait rien jusqu'à ce que minimum DELAI ms soient passées depuis la dernière frame;
clkfps = clock(); //temps de cette frame-ci
GestionClavier(); //gère... le clavier, oui, merci :p
DessinerEcran(); //appelle toutes les méthodes de dessin...

je dois reconnaître que c'est une sorte de timer plutôt rudimentaire... ça marche très bien pour un jeu style RPG (tiens tiens), mais pour une simulation physique (souvent le cas ds les jeux d'ailleurs) qui demandent de pvr dessiner avec des temps différents, et d'ailleurs de ne pas faire des déplacements égaux à chaque frame, mais des déplacements dépendant du temps depuis la dernière frame, ce système est pourri jusqu'à l'os ;)

LIMITER NOMBRE FPS [OPENGL & QUERYPERFORMANCE & DEVCPP]

Votre réponse

Discussions similaires