Discussion :

[Franck.H]

Bonjour !


Voià, dans mon projet de jeu et en cours de développement d'une petite API et un petit moteur, je me pose soudain quelques questions !

J'avais pour idée de faire un sorte de Scheduler de rendu régi bien sûr pas une liste chaînée comme il se doit. Ce module permettrais de gérer de façon totalement autonome le rendu des objets qu'on lui injectes dans sa liste tout en prennant en compte le délais de rafraîchissement de chacun d'eux et le supprimerais en cas de besoin (ex: la mort d'un ennemi).

Jusqu'ici l'idée paraît pas si mal et j'en suis pas peu fier Je me pose tout de même quelques questions :

1. Un Thread est-il mieux pour ce genre de chose ?
2. Ormis le fait de ne pas oublier les verrous au bons endroits, quelles serait grosso modo la différence d'utilisation en ressource et de perfomance entre la méthode Thread et sans Thread ?

Merci bien

[fearyourself]

Jusqu'ici l'idée paraît pas si mal et j'en suis pas peu fier

Je suis d'accord sur la solution ca me semble pas mal !

1. Un Thread est-il mieux pour ce genre de chose ?
2. Ormis le fait de ne pas oublier les verrous au bons endroits, quelles serait grosso modo la différence d'utilisation en ressource et de perfomance entre la méthode Thread et sans Thread ?

Ca dépend de comment tu le gères. La question thread-pas de thread est difficile à répondre. Généralement, si on peut, il vaut mieux faire deux versions et comparer.

L'expérience montre que certains threads vont facilités l'implémentation mais si le programme passe son temps à gérer des verrous, cela ne sera pas optimal.

Jc

[Franck.H]

L'expérience montre que certains threads vont facilités l'implémentation mais si le programme passe son temps à gérer des verrous, cela ne sera pas optimal.

Bin toutes les coordonnées joueur et des ennemis qui sont tout le temps mis à jour, je pense que déjà là il va passer sont temps à prendre et libérer le verrou

[fearyourself]

Bin toutes les coordonnées joueur et des ennemis qui sont tout le temps mis à jour, je pense que déjà là il va passer sont temps à prendre et libérer le verrou

Effectivement.

De toute facon pour ce genre de jeu, je ne pense pas que des threads séparés rendu/gestion des objets soient vraiment nécessaire. Mais avec une bonne gestion des verrous, cela pourrait donner quelque chose de sympa.

Jc

[Franck.H]

Effectivement.

De toute facon pour ce genre de jeu, je ne pense pas que des threads séparés rendu/gestion des objets soient vraiment nécessaire. Mais avec une bonne gestion des verrous, cela pourrait donner quelque chose de sympa.

Jc

En fait ce n'est pas directement le jeu mais un petit moteur plus ou moins generique en 2D avec une petite API, autant faire les choses correctement J'envisage de l'utiliser pour d'autres futurs projets

[fearyourself]

En fait ce n'est pas directement le jeu mais un petit moteur plus ou moins generique en 2D avec une petite API, autant faire les choses correctement J'envisage de l'utiliser pour d'autres futurs projets

Ah alors pour un cas plus général, je pense qu'il faudrait viser le multi-thread si on vise haut. Par contre, cela va forcément compliquer la donne.

Le plus simple serait alors sûrement de faire un lock/unlock pour chaque modification de l'objet. Mais cela va effectivement coûter beaucoup plus en terme de ressources.

Il faudrait trouver une solution plus light pour ne pas devoir faire un lock/unlock pour chaque objet.

Enfin, comme toujours, je partirais sur une solution de lock/unlock pour chaque objet et si les performances sont vraiment lamentable, j'aviserais. Si cela se trouve, ce ne sera pas très grave.

Jc

[Franck.H]

Ah alors pour un cas plus général, je pense qu'il faudrait viser le multi-thread si on vise haut. Par contre, cela va forcément compliquer la donne.

Le plus simple serait alors sûrement de faire un lock/unlock pour chaque modification de l'objet. Mais cela va effectivement coûter beaucoup plus en terme de ressources.

Il faudrait trouver une solution plus light pour ne pas devoir faire un lock/unlock pour chaque objet.

Enfin, comme toujours, je partirais sur une solution de lock/unlock pour chaque objet et si les performances sont vraiment lamentable, j'aviserais. Si cela se trouve, ce ne sera pas très grave.

Jc

C'est exactement ca que je pensais, de toutes manière pas trop le choix avec les thread Va falloir que je fasse un programme de test pour tester tout ca avant l'implémentation dans le jeu quand on le démarera

[fearyourself]

C'est exactement ca que je pensais, de toutes manière pas trop le choix avec les thread Va falloir que je fasse un programme de test pour tester tout ca avant l'implémentation dans le jeu quand on le démarera

Non je ne pense pas vraiment. Si tu codes proprement, tu devrais pouvoir avoir une gestion avec thread et une version monothread sans que cela change grand chose à l'extérieur.

La seule vraie différence serait la zone de code qui modifie les objets (des mutex dans un cas, aucun dans l'autre) et un appel au code qui gére le rendu dans un cas et une création de thread dans l'autre.

Soit avec des #if #endif tu peux facilement faire les deux versions en même temps et comparer avec le produit complet.

Jc

[Franck.H]

Non je ne pense pas vraiment. Si tu codes proprement, tu devrais pouvoir avoir une gestion avec thread et une version monothread sans que cela change grand chose à l'extérieur.

La seule vraie différence serait la zone de code qui modifie les objets (des mutex dans un cas, aucun dans l'autre) et un appel au code qui gére le rendu dans un cas et une création de thread dans l'autre.

Soit avec des #if #endif tu peux facilement faire les deux versions en même temps et comparer avec le produit complet.

Jc

Oui pas bête effectivement, à ca j'avais pas pensé Merci