Comment gérer le rendu sur plusieurs moniteurs avec des taux de rafraîchissement différents?


8

Quelle est la meilleure façon de faire face à une situation qui peut survenir, où un utilisateur dispose de deux ou plusieurs moniteurs avec différentes résolutions et intervalles de synchronisation verticale?

Cela s'appliquerait lorsqu'un jeu a un pas de temps fixe et s'exécute en mode fenêtré: si un moniteur a une fréquence d'images de 60,056 et l'autre a une fréquence d'images de 59,94, la synchronisation verticale échouera finalement à faire son travail, si le la fenêtre de jeu est déplacée de l'écran principal à un autre.

Un crénelage temporel se produira également, car le pas de temps n'est pas correctement réglé sur l'autre taux de synchronisation. Comment les jeux gèrent-ils ce problème, le cas échéant?


Qu'est-ce que vous essayez exactement de faire?
Panda Pyjama

@PandaPajama J'essaie de permettre au joueur de déplacer la fenêtre de jeu entre les écrans en douceur pour que A) aucune déchirure ne se produise à aucun moment et B) aucune image ne se répète à aucun moment. Je suppose que la logique est indépendante de cela, donc je vais réduire la portée de ma question au simple rendu.
NmdMystery

Vous n'obtiendrez des images répétées que si votre logique de jeu est plus lente que votre code de rendu. À 60 fps logiques, sur 60.056 fps graphiques, vous obtiendrez en moyenne une image répétée toutes les 18 secondes. Cela prend 0,017 seconde et sera très probablement imperceptible. Si vous NE DEVEZ DÉFINITIVEMENT avoir aucune image répétée, vous pouvez avoir votre logique de jeu à un débit d'images beaucoup plus rapide. Dites 200 images par seconde. Vous gaspillerez beaucoup de traitement et obtiendrez beaucoup d'images perdues, mais vous n'obtiendrez pas d'images répétées, ce qui semble être votre objectif.
Panda Pyjama

Ceci est bien sûr valable pour un monde avec des pas de temps discrets, qui englobe la grande majorité du code de jeu. Si vous pouvez calculer de manière cohérente l'état de votre monde de jeu pendant un temps arbitraire nen moins de O(n)complexité (de manière optimale O(1)), alors rien de ce que j'ai dit ne s'applique. Les simulations interactives n'ont cependant pas tendance à fonctionner comme ça.
Panda Pyjama

Réponses:


5

Étapes logiques de jeu ne doivent être synchronisées avec la logique d'affichage, même si vous utilisez un timestep fixe.

Considérez un gameloop comme:

var time_per_step = 1 / 60 -- for 60 -logic- steps per second
var prev_time = get_time() -- in seconds

while true do
    var curr_time = get_time()
    while prev_time < curr_time do
        do_step()
        prev_time = prev_time + time_per_step
        // optional: curr_time = get_time()
    end
    draw()
end

Peu importe le temps que draw()prennent vos appels. Tant que votre do_step()prise est inférieure à time_per_step, votre logique de jeu ne prendra pas de retard.


Que diriez-vous de déchirer? La solution aux différents taux de rafraîchissement dépend-elle du fournisseur, ou existe-t-il un moyen efficace de restituer au bon moment sur les deux écrans sans subir de crénelage temporel sur l'un d'entre eux?
NmdMystery

Cette solution est compatible avec vSync. J'ai utilisé 60 pas de cadre logique par seconde, mais vous pouvez augmenter ou diminuer autant que vous le souhaitez.
Panda Pyjama

Mon point est qu'avec cette gameloop, votre logique de jeu sera toujours à jour avec l'horloge en temps réel. En tant que tel, si votre logique de dessin n'est pas exactement synchronisée avec la logique du jeu, cet algorithme répétera ou supprimera les images selon les besoins afin de suivre l'horloge en temps réel. Que ce soit acceptable ou non, c'est à vous de décider
Panda Pyjama

Je dois donc choisir entre des images répétées et des déchirures, essentiellement? Pas d'autres alternatives?
NmdMystery

Eh bien, mais c'est par définition. Si vous voulez Xdes images logiques par seconde sur Ydes images graphiques par seconde, X != Yvous devrez soit faire en sorte que la logique reste fidèle aux graphiques (images répétées et supprimées), soit que les graphiques restent logiques (déchirure). L'autre alternative est de forcer la logique à s'exécuter à la vitesse des graphiques, ce qui entraînera un alias temporel. Pas de fusée ici.
Panda Pyjama
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.