Quelques questions concernant la boucle de jeu, le tick et la programmation en temps réel

Question

Je veux d'abord m'excuser pour mon anglais approximatif, car je suis français. Je suis en train de faire un jeu en temps réel en Java, en utilisant LWJGL. J'ai quelques questions concernant les boucles de jeu:

• Je suis en train d'exécuter la routine de rendu dans un thread. Est-ce que c'est une bonne idée? Habituellement, la routine de rendu est assez lente et ne devrait pas ralentir la routine de mise à jour du monde (tick), ce qui est beaucoup plus important. Donc, je suppose que l'utilisation d'un fil ici semble être une bonne idée (moins les complications de l'utilisation d'un fil).
• Dans la routine de mise à jour mondiale, je suis en train de mettre à jour une liste d'entités avec l'heure actuelle. Chaque entité peut alors calculer son propre deltaTime, correspondant à la dernière fois qu'elles ont été mises à jour. Cela diffère de la boucle de mise à jour habituelle, qui met à jour chaque entité de la liste avec le même deltaTime. Cela semblait approprié en raison du rendu par thread. Est-ce que c'est une bonne idée? Dois-je utiliser la seconde méthode à la place? Si oui, le rendu par thread est-il toujours nécessaire? Si oui, dois-je ajouter un deltaTime maximum?
• En général, est-ce une bonne idée d'avoir un deltaTime maximum?

Merci pour votre temps!

Answer 1

1. Est-ce une bonne idée? Les threads séparés sont des trucs assez avancés, je ne vois aucune raison de faire du multithreading pour commencer. Tous les jeux mobiles sur lesquels j'ai travaillé jusqu'à présent n'ont pas besoin de plusieurs threads, même s'ils sont en «temps réel». Hardcore Jeux PC et console sont où le multithreading commence vraiment à jouer. Voici un lien vers une conférence récente sur le sujet si vous êtes intéressé: http://archive.assembly.org/2011/seminars/adventures-in-multithreaded-gameplay-coding. Un tel bruit pourrait causer des choses étranges si la physique n'est pas traitée en une seule fois. Pas sûr à ce sujet. Collecter un objet qui a déjà été mis à jour à une autre position avec un objet qui vient une autre fois, par exemple, corriger ce genre de situation peut devenir problématique? Les collisions à déplacement rapide peuvent devoir être subdivisées, ce qui explique peut-être pourquoi vous avez le thread de mise à jour séparé, mais pourquoi ne pas les avoir tous calculés comme se produisant en même temps? 'Timestetep variable' et 'Fixed timetep' sont les options disponibles pour le rendu. La plupart des jeux pour le moment semblent choisir un timestep fixe de 30 fps. Le rendu doit être maintenu dans les limites afin qu'aucun rattrapage ne soit nécessaire. Un problème avec le pas de temps variable est que vous êtes obligé de passer deltaTime à toutes les zones dépendant du temps. Le timestep fixe est pratique car vous pouvez supposer que vous êtes en train de tourner à 30 fps, et utilisez cette valeur partout. C'est une méthode préférée en ce moment, pour autant que je sache.

Answer 2

Bien que cette question est de quelques années ...

AFAIK,

Le rendu est généralement fait dans le processeur séparé - GPU, ils sont donc déjà un fil séparé. Mais, la commande de dessin doit être traitée par le pilote graphique (qui s'exécute dans la CPU) avant d'être envoyée au GPU, et ce traitement peut être sauvegardé en étant multi-thread. Dans tous les cas, vous êtes responsable de la gestion de la synchronisation entre les logiques et le thread de rendu. En règle générale, les jeux sont tous sur les interactions entre les objets, et il est très difficile de diviser l'état-graphe en divisions entièrement séparées. Par conséquent, l'ensemble de l'état du jeu devient généralement un graphique unique, et ce graphique ne peut pas être mis à jour lorsqu'il est rendu. Dans ce cas, vous n'avez aucun avantage à être multi-thread.

Si vous pouvez conserver des données immuables séparées pour le rendu, vous pouvez bénéficier d'un rendu dans un thread séparé. Mais sinon, je ne le recommande pas.

En outre, vous devriez considérer GC si vous voulez vraiment un jeu en temps réel. Les problèmes de performance liés au GC sont généralement les plus gros obstacles à la création de documents en temps réel.