Comment utiliser SDl_Threads correctement?

Question

Je suis nouveau sur les threads, SDL et comment le travail graphique en général. J'ai regardé tous les tutoriels SDL de LazyFoo, et m'a beaucoup aidé. Mais dans ses tutoriels sur le multi-threading, il a commenté que vous ne devriez jamais utiliser les fonctions vidéo dans des threads séparés, ou pourrait causer des problèmes. Je suis curieux de savoir comment cela doit être fait, car j'ai encore une vague compréhension des graphiques et des fils. Comme un de mes projets est un shoot'em up, je me demandais si je devais créer un thread qui affiche tous les graphiques, un thread reçoit toutes les entrées du joueur pour son vaisseau, et un autre thread pour l'IA ennemie.

Si ce n'est PAS ce qui devrait être fait, (je pense que c'est faux) quelqu'un a-t-il des conseils sur la façon dont les graphiques devraient être implémentés avec l'entrée utilisateur et l'IA ennemie avec les threads?

Pour les tutoriels de Lazyfoo, c'est le lien: http://lazyfoo.net/SDL_tutorials/

Answer 1

En général, je pense qu'il est une bonne idée de séparer le fil de rendu des discussions UI/AI. Cela aide à garder votre code plus compréhensible. Comme il y a beaucoup de jeux disponibles dans le code source, pourquoi ne pas vérifier comment ils l'ont fait?

Answer 2

Il peut être beaucoup plus facile de séparer les threads sur la base des responsabilités lorsque vous débutez. La façon la plus «correcte» d'aborder cela, qui conduit à une plus grande extensibilité, est d'utiliser des pools de threads. Il existe des solutions de pool de threads prédéfinies, dont une pour SDL. Si vous utilisez OpenGL ou DirectX pour faire du rendu, je doute que les appels à ces API génèrent beaucoup de frais généraux, donc vous pouvez au moins faire les parties (nécessairement) séquentielles de votre boucle de jeu dans le thread principal: obtenir des entrées, mettre à jour le modèle mondial (y compris en utilisant les résultats de ai calcs), rendre. Ensuite, vous pouvez avoir AI, threads réseau en parallèle. Vous n'avez donc pas besoin de vous soucier d'un thread de rendu séparé. Il y a une exception à cela: si vous faites du calcul lourd (et je veux dire comme dans raycasting/raytracing heavy) dans le logiciel, alors vous feriez mieux d'effectuer en quelque sorte "logique" de rendu sur un fil parallèle, écrire dans un framebuffer, et ensuite dans votre thread principal en faisant la séquence donnée ci-dessus, et juste en train de mixer votre framebuffer préparé en utilisant par exemple. GDI.

En ce qui concerne le rendu, oui AFAIK rendu à partir d'un seul thread (le thread principal) est (ou était) généralement une bonne idée pour s'assurer que, par exemple. avec OpenGL vous n'avez aucun problème. Encore une fois, AFAIK ce n'est plus un problème sur les grandes plateformes. En outre, je ne sais pas si GDI ou DirectX ont les mêmes problèmes séparément.