Discussion :

[Obligen]

Bonjour,

J'ai besoin d'un avis de gens plus compétents que moi dans ce domaine.
Je teste actuellement la programmation de physique simple, comme les collisions avec rétroaction, les lancers et tout ça.

Seulement, je me posais une question sur la traditionnelle "gaming loop", qui voudrait que l'on respecte le schéma basique suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
- A l'infini, faire
--- calculer les nouvelles positions des objets
--- dessiner les objets
--- attendre un peu si on est en avance

Certes, cela marche bien, mais du coup, soit on calcule les positions des objets en fonction du temps écoulé, et c'est relativement lourd, soit on calcule les positions en fonctions de nombre d'images affichées, et tout est très simple à coder, mais si ça rame, l'animation est ralentie au sens propre, et donc ce n'est pas bon.

Je sais que traditionnellement (sauf en Flash généralement), on calcule les positions des objets en fonction du temps écoulé, mais est-ce conventionnel d'utiliser plutôt 2 threads, de la façon suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
--------------------------------
Thread de calcul
--------------------------------
- A l'infini, faire
--- Calculer les nouvelles positions
--- Attendre un peu
 
--------------------------------
Thread de rendu
--------------------------------
- A l'infini, faire
--- Dessiner les objets
--- Attendre un peu

Forcément, on est pas forcé d'attendre le même temps, et on se retrouve donc avec un taux d'images par seconde (FPS), et un taux de calculs par seconde (CPS ?).

J'ai commencé à faire comme ça (n'y connaissant pas grand chose) en java, cela marche bien mais je ne pense vraiment pas que ce soit conventionnel, d'autant qu'en écrivant ces lignes je me dis que si le thread de calcul se met à ramer, l'animation sera ralentie quand même, ce qui n'est pas le cas dans un simple thread avec calcul des positions indexé sur le temps écoulé depuis le dernier calcul...

Bon, finalement j'ai peut être compris par moi même en écrivant ce message qu'elle était la seule solution envisageable, même si plus lourde à mettre en œuvre (plus facile de faire un "balle.x ++" qu'un "balle.x = tempsEcoule*vitesse")... autant laisser ça au cas où ça intéresse quelqu'un.


EDIT : A oui, une chose à laquelle j'ai pensé aussi. En utilisant 2 threads, on prend le risque de calculer une nouvelle position d'objet au même moment où on l'affiche, donc accès concurents. Ca n'a pas de conséquences dans les jeux simples avec peu d'objets à l'ecran, mais je pense que la scène serait mal rendue avec beaucoup d'objets. Du coup, on peut envisager d'insérer quelques accès atomiques aux données ou mettre en place quelques sémaphores, mais du coup, on en revient presque à la boucle simple classique, puisque soit on calcule, soit on affiche...

EDIT2 : Je pensais que dans le framework XNA de Microsoft (DirectX managé et intégré), on avait réellement deux threads différents, car il y a une méthode "Draw" et une méthode "Update". Mais ayant essayé d'afficher les FPS et les CPS à l'ecran, ils s'averent être les mêmes, il n'y a donc qu'un seul thread...

[shenron666]

est-ce conventionnel d'utiliser plutôt 2 threads, de la façon suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
--------------------------------
Thread de calcul
--------------------------------
- A l'infini, faire
--- Calculer les nouvelles positions
--- Attendre un peu
 
--------------------------------
Thread de rendu
--------------------------------
- A l'infini, faire
--- Dessiner les objets
--- Attendre un peu

à vue de nez je dirai que :
- ton thread de calcul va attendre que ton thread de rendu ai terminé d'afficher pour commencer
- ton thread de rendu va attendre ton thread de calcul jusqu'à ce qu'il ait terminé son boulot pour commencer à son tour
au final : gain 0%

avec quelques petits ajustements tu peux réussir à faire en sorte que le thread de rendu commence à traiter les objets que le thread de calcul a terminé de traiter

si le thread de calcul se met à ramer, l'animation sera ralentie quand même, ce qui n'est pas le cas dans un simple thread avec calcul des positions indexé sur le temps écoulé depuis le dernier calcul...

c'est pourquoi il faut toujours caler son animation sur le temps écoulé

Bon, finalement j'ai peut être compris par moi même en écrivant ce message qu'elle était la seule solution envisageable, même si plus lourde à mettre en œuvre

plus lourd c'est un peu exagéré

EDIT : A oui, une chose à laquelle j'ai pensé aussi. En utilisant 2 threads, on prend le risque de calculer une nouvelle position d'objet au même moment où on l'affiche, donc accès concurents. Ca n'a pas de conséquences dans les jeux simples avec peu d'objets à l'ecran, mais je pense que la scène serait mal rendue avec beaucoup d'objets. Du coup, on peut envisager d'insérer quelques accès atomiques aux données ou mettre en place quelques sémaphores, mais du coup, on en revient presque à la boucle simple classique, puisque soit on calcule, soit on affiche...

approfondis le sujet, renseigne toi sur :
- les threads et le multithreading
- les mutex et semaphores
- les "lock free data structures"
- la programmation événementielle
tu verras qu'il y a des tas de solutions pour multithreader certaines parties
sachant que, à l'heure actuelle, la seule chose qu'on ne peux pas multithreader c'est le rendu, ni en D3D ni en OGL (quoiqu'en OGL on peut mais ça ne sert à rien)

[Obligen]

Merci de ces réponses, je vais continuer à creuser la question, c'est assez intéressant

[IrmatDen]

Salut,

Si ça peut te donner un début de piste, j'ai lu cet article sur Gamasutra qui présente rapidement quelques approches. Ca te donnera un premier aperçu, et des noms et mot-clé pour creuser plus avant tes recherches

[Obligen]

Merci pour le lien, c'est très instructif

[deadalnix]

perso, j'ai une représentation du monde statique. Celle-ci peut être utilisée pour l'affichage.

En parallèle la physique est calculée. Un fois une étape complète au niveau de la physique, c'est cette partie qui choppe un lock sur le monde statique, et qui commit le plus rapidement possible les nouvelles infos.

De plus, cette façon de faire se marie bien avec les algo de lag compensation (non encore implémenté pour ma part, mais au programme).