Quelle est la manière habituelle de contrôler le taux de trame?

Je suis nouveau graphisme, donc je ne sais pas comment les gens généralement de contrôler le taux de trame pour le rendu des choses.
Je veux dire, comment pouvez-vous définir vous demande de rendre à, disons, 30 fps?
Il y a probablement beaucoup d'Api, qui offre une telle chose, mais j'ai besoin de code à partir de zéro.

source d'informationauteur hstefan | 2011-04-01

c++graphics

20

Il y a deux "habituel" des moyens de "contrôle" framerate, et il n'est ni tout à fait aussi simple que cela.

Le premier et le plus grand contrôle des deux, et quelque chose qui est généralement facultative, est VSync. Cette forces de la carte vidéo pour pousser une nouvelle image lorsque le moniteur est en fait rafraîchissant. De nombreux moniteurs de rafraîchissement à 60 Hz, de sorte que vous avez tendance à 60 FPS.

Cela fonctionne assez bien pour cap framerate à taux de rafraîchissement du moniteur, mais quand le framerate descend en dessous de rafraîchissement, il est forcé de le multiple le plus proche. Ainsi, comme le framerate commence à tomber un peu, vous perdez un peu de potentiel, le temps de rendu, parce qu'il est forcé à 60, puis 30, puis 20, etc.

(un peu d'info sur le vsync dans DirectX et OpenGL)

La deuxième méthode, couramment utilisée (avec le vsync éventuellement ajoutée) est de ne pas limiter le framerate. Au lieu de cela, ajustez votre code pour gérer les différences. C'est beaucoup plus souple dans le long terme, et généralement mieux de codage, de l'OMI, et beaucoup plus simple que d'essayer de forcer un particulier FPS comte.

En supposant que vous avez un rendu simple boucle, il se lance à la recherche de quelque chose comme:
```
while ( gameloop )
{
    float framedelta = ( timeNow - timeLast )
    timeLast = timeNow;

    for each ( GameObject object in World )
    {
        object->Animate(framedelta);
        object->Move(speed * framedelta)
    }

    render();
}
```
Vous voulez regarder la différence de temps/temps passé/delta, et de travailler à partir de là. Permettre le framerate à l'échelle basée sur le matériel et les réglages (il y a trop de variations pour vous de prévoir ou de gérer de la moitié), et faire de votre jeu de travail avec qu'au lieu de la contrôler. Beaucoup plus facile pour vous et plus souple et stable dans la pratique.
6

Typique de la façon de donner un prévisible (si pas constant) taux de trame (avec vidéo ou 3D) est décrit dans la suite de pseudo-code.

Algorithme
1. Préparer l'image suivante (le rendu en arrière-tampon);
2. Dormir pour le reste de la tranche de temps;
3. Demander à l'image à afficher (swap avant et à l'arrière tampons).
Noter la position de la veille de l'opération. Il est pris en sandwich entre la préparation et l'affichage de la même image. C'est la clé principale pour une constante de taux de trame! Vous voulez la préparation du cadre de compter dans le total de la tranche de temps pour l'affichage de l'image.

Il y a un certain nombre de variantes sur la façon de mettre en œuvre chacune de ces étapes (choix de la veille de l'opération sur la base de sa résolution, la fiabilité, etc.), mais l'essentiel est là.

Conseils pour une plus grande fiabilité
- Ne pas appeler votre fonction de veille une fois pour l'ensemble de l'intervalle. Définir une constante avec l'erreur maximale que vous êtes prêt à accepter et à plusieurs reprises le sommeil pendant des périodes de cet intervalle jusqu'à ce que le temps restant est inférieur ou égal à ce montant.
- Ne pas avoir peur de temps en temps de déposer d'une image lorsque vous savez que vous ne serez pas en mesure de préparer la prochaine image dans le temps. C'est visuellement plus attrayant pour passer d'un cadre que de produire une fréquence d'image variable.
- Si vous pouvez éviter les threads d'arrière-plan sur un système monoprocesseur, de les éviter. À l'aide de threads de travail sera vraiment gâcher la fiabilité de votre fonction de veille. La meilleure approche consiste à diviser votre travail de fond en petits morceaux et ce travail est exécuté à la place de couchage.
Le 1er est facile à mettre en œuvre et peut être caché dans une fonction d'assistance. Le 2ème est un peu plus délicat car il vous oblige à tenir des statistiques de la moyenne de la vitesse de rendu, entre autres choses. Le 3e est difficile à mettre en œuvre comme il est souvent difficile de prédire combien de temps à des tâches différentes à prendre. C'est seulement généralement mis en œuvre dans les systèmes temps réel à contraintes fortes.

Vous devez vous connecter pour publier un commentaire.