Discussion :

[agrosjea]

hello everybody.
Voila je bosse en ce moment sur un petit jeu de plateforme en opengl.
J'aimerais bien que mon moteur physique soit indépendant de mon affichage.
Je m'explique: lorsque je met à jour mon affichage,cela prend un certain temps, temps pendant lequel mon moteur physique ne peut tester les collisions. ce qui fait que si je fait tourner mon jeu sur une bécane pourrie qui rame à fond à 2fps les collisions ne sont détectée que 2fois par secondes, autant dire que mon moteur physique ne fait plus du tout son taf. J'avais pensé gérer l'affichage et les physiques sur deux processus qui tourneraient parallellement mais je ne sais po du tout comment m'y prendre... help!

[MatRem]

Tu peux utiliser plusieurs thread plutôt que plusieurs processus, mais de toutes façon si l'affichage rame vraiment, je vois pas bien l'intérêt...

[agrosjea]

bah l'intéret est simple : pouvoir faire tourner mon jeu sur nimporte quelle bécane sans avoir un bug de collision qui pourrirait le gameplay
packe ken je di ke ca rame jabuz c doit tourner a 15 20 fps donc c pas génant pour jouer mais la detection de collision s'effectue mal.

[IrmatDen]

La réponse qu'il t'a donné est la bonne. Il faut que tu regardes du côté des threads, pas des processus. Pour avoir un aperçu de l'organisation possible, tu peux regarder lire cet article de Gamasutra.

Edit: j'ai compris qu'un mot sur 4 à ton dernier message. Peux-tu faire un effort sur l'orthographe stp?

[mchk0123]

Je suis pas expert en développant de jeux, mais déjà si tu as un moteur physique qui rame plus que le rendering 3D t'est à mon avis mal barré. Tu dervrais déjà améliorer la performance de ton moteur avant bidouiller avec des threads.

De mémoire il me semblait que la gestion des collisitions était moins gourmand en traitement que le rendering (mis à part les accélérations liés à la CG) ?

[agrosjea]

merci pour ces réponses, désolé pour l'orthographe d'habitude je fais attention mais là je devais être préssé.

mais déjà si tu as un moteur physique qui rame plus que le rendering 3D t'est à mon avis mal barré.

en fait c'est pas le problème, bon en effet il se peut qu'il y ai un travail d'optimisation a faire, mais c'est plutôt l'affichage qui rame et qui, donc empêche le moteur physique de faire son travail.

par exemple:

• à t=0 un objet est tres proche d'un mur et il est relativement rapide
• ton pc affiche l'image il met mettons 20 ms pour l'afficher
• on se retrouve à t=20ms et il est trop tard pour que ton moteur physique détecte la collision, du coup l'objet a deja traversé le mur et le bug s'affiche

[Laurent Gomila]

Pour ça tu peux aussi utiliser des méthodes de détection de collision continues. Mais bon étant donné qu'utiliser un intervalle de mise à jour régulier permet de garantir une certaine stabilité, effectivement avoir un thread séparé qui tourne à son rythme n'est pas forcément une mauvaise idée. Il y a même des moteurs physiques qui débloquent complétement avec des timesteps non réguliers.

La physique, c'est du code perso ou tu utilises un moteur connu ?

[agrosjea]

c'est un code perso (en fait c'est un pote à moi qui l'a fait )

[Albenejean]

* à t=0 un objet est tres proche d'un mur et il est relativement rapide
* ton pc affiche l'image il met mettons 20 ms pour l'afficher
* on se retrouve à t=20ms et il est trop tard pour que ton moteur physique détecte la collision, du coup l'objet a deja traversé le mur et le bug s'affiche

Pour ça tu peux aussi utiliser des méthodes de détection de collision continues.

Oui. Dans le cas ou ton objet eraffle le mur, il risque d'être parfois détecté, parfois non si tu ne testes qu'à des intervalles fixes.

[N_I_C_S]

Je crois que les seules méthodes infaillibles sont celles qui testent les collisions entre t-1 et t. Par exemple, on stocke le segment [position_derniere_frame, position_nouvelle_frame] de l'objet et à chaque frame on teste si le segment traverse un mur. Ca marche à 2 ou à 200 fps, frame-rate régulier ou pas, et pas besoin de thread...