Synchronisation d'un jeu et threads - Page 1

yop,


Je suis en train d'essayer de faire la synchor d'un jeu, mais bien que j'ai pas de souci à avoir un fps constant (un simple timer), je trouve que ce que je fais ne rime à rien.

D'abord, "synchroniser" c'est bien, mais avec quoi ? Sur TI, on synchronise avec le dessin de l'écran, pour profiter du temps le plus long possible entre deux dessins d'écran.
Sur PC, on synchronise avec quoi ? Question con je pense, mais qui me fout déjà dans le vent

De plus, il est facile de régler l'affichage par rapport à un timer, ok. Mais la elcture clavier ? C'est pas limitant en terme de gameplay de ne lire le clavier qu'à 30 fois/secondes ? Ca m'a l'air peu. On fait comment alors ? On lit 3 fois le clavier, on fait les traitements de données qui vont avec, puis un seul affichage par exemple ? Ca m'a l'air crade Ou alors on lit le clavier au maximum, et seul l'affichage est régulé à un fps constant ?

C'est là que je commence à penser à un truc que j'ai jamais utilisé (sauf pour en rigoler sur irc), les threads. Déjà, ça permet de séparer proprement ce qui est le traitement d'évènements, le dessin, et que sais-je encore, donc ça m'a l'air bien. Mais faire des threads pour faire des threads n'est pas un but en soi. J'ai demandé à google "pourquoi faire des threads", malheureusement les réponses n'ont pas pleuvu. Il y a 50 tutos sur "comment" les faire, mais pas "pourquoi". Et j'aimerais savoir quelle est la situation qui sera clarifiée par l'emploi bien à propos d'un thread, quelles sont les situations où ça ne serait que travail inutile et compliqué.


Donc voilà, pour résumer mes interrogations :
- sur quoi synchroniser un jeu, et que doit-on synchroniser ?
- faut-il employer des threads, et si oui, que doivent-ils contenir (rendu, lectures io, etc...)

Folco (./1) :
D'abord, "synchroniser" c'est bien, mais avec quoi ? Sur TI, on synchronise avec le dessin de l'écran, pour profiter du temps le plus long possible entre deux dessins d'écran.Sur PC, on synchronise avec quoi ?

La même chose. Cf. VSYNC.

C'est là que je commence à penser à un truc que j'ai jamais utilisé (sauf pour en rigoler sur irc), les threads. Déjà, ça permet de séparer proprement ce qui est le traitement d'évènements, le dessin, et que sais-je encore, donc ça m'a l'air bien. Mais faire des threads pour faire des threads n'est pas un but en soi. J'ai demandé à google "pourquoi faire des threads", malheureusement les réponses n'ont pas pleuvu. Il y a 50 tutos sur "comment" les faire, mais pas "pourquoi". Et j'aimerais savoir quelle est la situation qui sera clarifiée par l'emploi bien à propos d'un thread, quelles sont les situations où ça ne serait que travail inutile et compliqué.

Avantages:[ul][li]peuvent simplifier la programmation, parce qu'on laisse la machine décider quand faire quoi au lieu de devoir le décider dans le code de la boucle d'évènements[/li][li]permettent d'utiliser les cores d'un processeur moderne, multicore. (Il faut au minimum 1 thread par core.)[/li][/ul]
Désavantages:[ul][li]nécessitent souvent des synchronisations (ou des opérations atomiques, mais ce n'est pas toujours possible et suffisant) à quelques endroits, alors que le problème ne se pose pas si on a le contrôle sur quand on exécute quoi[/li][li]risque de deadlocks (si on synchronise de manière incorrecte)[/li][/ul]

Merci bien. C'est quoi cette histoire d'opérations atomiques ? Ca a un rapport avec les types atomiques ? (j'ai jamais cherché non plus ce qu'était un type atomique hein, je le ferai si besoin est )

Et euh, on l'obtient comment le VSync ? J'utilise SDL, et j'ai aucune envie de mettre les doigts dans le cambouis moi
J'ai cherché sans succès dans SDL, SDL_gfx et SDL_sge comment avoir accès à un quelque chose, par exemple un bit qui toggle à chaque fin de frame.

Folco (./4) :
C'est quoi cette histoire d'opérations atomiques ?

Alors déjà, ça n'a rien à voir avec le nucléaire.

Mais sérieusement: Une opération atomique est une opération qui ne peut être interrompue par rien, en particulier, pas par un autre thread. Par exemple, si tu as une incrémentation atomique, tu peux être sûr qu'un autre thread ne va pas accéder à ta variable pendant l'incrémentation, mais seulement soit avant, soit après, alors que si tu as le classique "lecture, incrémentation dans un registre, écriture" (et même si tu as une instruction d'incrémentation qui opère "directement" sur la mémoire, un processeur moderne fait les 3 étapes en interne) sans garantie d'atomicité, le thread peut changer la valeur entre ta lecture et ton écriture et tu écrases ce que l'autre thread a écrit, ce qui pour un compteur veut dire que tu as perdu une incrémentation (celle faite par l'autre thread).

En graphique, si les threads 1 et 2 font une incrémentation non-atomique, tu peux avoir:
sans perte de généralité, au départ: x=0
thread 1 lit x → x=0, x1=0
thread 1 incrémente x1 → x=0, x1=1
thread 1 interrompu! (Ou encore, les 2 threads s'exécutent en même temps sur 2 cores différents, ce qui fait que tu peux avoir l'équivalent d'une interruption même là où tu ne l'attends pas du tout, genre au milieu d'une instruction.)
thread 2 lit x → x=0, x1=1, x2=0
thread 2 incrémente x2 → x=0, x1=1, x2=1
thread 2 écrit x → x=1, x1=1, x2=1
retour au thread 1
thread 1 écrit x → x=1, x1=1, x2=1
… oups! On a voulu incrémenter x 2 fois, mais la valeur n'a augmenté que de 1.

Folco (./5) :
Et euh, on l'obtient comment le VSync ? J'utilise SDL, et j'ai aucune envie de mettre les doigts dans le cambouis moi J'ai cherché sans succès dans SDL, SDL_gfx et SDL_sge comment avoir accès à un quelque chose, par exemple un bit qui toggle à chaque fin de frame.

Une recherche dans un moteur de recherche me dit que la manière de laquelle SDL fonctionne est que tu es censé utiliser le double-buffering et SDL_Flip gère le VSync pour toi quand c'est possible, ce qui malheureusement n'est pas toujours le cas, par exemple en mode fenêtré sous certaines plateformes.

Synchroniser directement son code d'affichage avec VSync n'a pas l'air d'être prévu dans SDL.

Merci pour les opérations atomiques. T'aurais pu résumer : "Les opérations atomiques, c'est simple, c'est comme tas"

Pour ce qui est de SDL, oui j'ai bien trouvé ces infos, d'ailleurs elles sont dans la doc. Le truc, c'est que comme t'as toujours des fallbacks pour créer quand même ta fenêtre même si ya pas de vsync, si ya pas de mémoire video dédiée ou que sais-je encore, t'es jamais sûr que ton programme va tourner dans les conditions décrites ici, et ça c'est chiant. J'aurais juste voulu un moyen absolu, ce qui n'a pas l'air d'être le cas. Tant pis.

Folco (./8) :
Merci pour les opérations atomiques. T'aurais pu résumer : "Les opérations atomiques, c'est simple, c'est comme tas"

Effectivement, le test-and-set est l'opération atomique la plus courante, et j'avais oublié qu'il y a ça aussi sur le 68k alors que ça ne sert pas du tout sur le 68000 de base. Pour bien comprendre l'intérêt, il faut se placer sur au moins un 680x0 plus récent.

Et d'ailleurs, le x86 est plus flexible en ce qui concerne les opérations atomiques, tu peux mettre un lock; devant presque toutes les instructions pour les rendre atomiques.

Pour ce qui est de SDL, oui j'ai bien trouvé ces infos, d'ailleurs elles sont dans la doc. Le truc, c'est que comme t'as toujours des fallbacks pour créer quand même ta fenêtre même si ya pas de vsync, si ya pas de mémoire video dédiée ou que sais-je encore, t'es jamais sûr que ton programme va tourner dans les conditions décrites ici, et ça c'est chiant. J'aurais juste voulu un moyen absolu, ce qui n'a pas l'air d'être le cas. Tant pis.

Le problème est que le moyen absolu dépend de la plateforme et n'existe pas toujours. Par exemple, le mode fenêtré sous un certain système d'exploitation "fenêtré" lui aussi (et qui donne envie de se défenestrer si on est obligé de l'utiliser ) n'a pas l'air d'avoir accès à VSync.

Kevin Kofler (./7) :
Une recherche dans un moteur de recherche me dit que la manière de laquelle SDL fonctionne est que tu es censé utiliser le double-buffering et SDL_Flip gère le VSync pour toi

Ca, ok. Mais ce qui serait bien, ça serait de connaitre la vitesse de ce rafraichissement pour pouvoir caler la vitesse du jeu, non, sinon comment faire ?

Est-ce que ça, c'est une solution propre ?
- réguler la boucle d'évènements sur une fréquence fixée (ça je sais faire), mettont 50 Hz au pif
- quand une frame est dessinable, on appelle SDL_Flip, qui se chargera de dessiner ça au moment kivabien côté synchro toussa

Mais on risque de se retrouver avec du frame skipping si la fréquence de rafraichissement de l'écran est inférieure à la fréquence choisie pour la boucle d'évènement, non ?
Ca reste correct quand même, pour assurer une vitesse constante ?

Kevin Kofler (./9) :
Effectivement, le test-and-set est l'opération atomique la plus courante, et j'avais oublié qu'il y a ça aussi sur le 68k alors que ça ne sert pas du tout sur le 68000 de base.

Sérieux ?

(En fait, si, mais pas forcément dans pour son but initial)

(Ouppss... Je viens de voir que que ce sujet est en partie TI, désolé pour le dérangement)
(sinon TAS est utilisé sur le 68k des ST, au moins au niveau de l'AES)

Sujet très intéressant en tout cas

./10 > SI tu devais choisir une fréquence au pif, tu aurais plutôt intérêt à choisir 60Hz ou un multiple… Particulièrement depuis le passage aux écrans LCD, c'est très rare de trouver des écrans avec des fréquences autres que 60Hz (ou le 59,94Hz du HDMI…)
Sinon, si SDL n'est pas capable de gérer le VSync en mode fenêtré, le problème vient certainement directement de SDL et pas de Windows… (La synchro VSync en mode fenêtré est peut-être moins fiable (ne marche pas forcément sur *n'importe quelle* config logicielle/matérielle), mais c'est malgré tout une fonctionnalité supportée…)

Sinon, tu auras un autre problème avec les threads, c'est que le rendu graphique ne peut pas être partagé proprement entre plusieurs threads. (Un seul doit s'en occuper, sauf avec des API récents comme DX11)

Et pour le coup, j'insisterai spécifiquement sur cette partie du post de Kevin:

Kevin Kofler (./3) :
Désavantages:[ul][li]nécessitent souvent des synchronisations (ou des opérations atomiques, mais ce n'est pas toujours possible et suffisant) à quelques endroits, alors que le problème ne se pose pas si on a le contrôle sur quand on exécute quoi[/li][li]risque de deadlocks (si on synchronise de manière incorrecte)[/li][/ul]

Kevin Kofler (./9) :
Et d'ailleurs, le x86 est plus flexible en ce qui concerne les opérations atomiques, tu peux mettre un lock; devant presque toutes les instructions pour les rendre atomiques.

Note d'ailleurs qu'un certain nombre d'opérations mémoire sont atomiques par nature en x86 et que le préfixe lock n'est pas toujours nécessaire dans ce cas de figure précis. En revanche, lock a d'autres utilités…



Et donc le pourquoi du comment de utiliser des threads… (Question initiale, non ?)
Ben c'est compliqué parce qu'il y a plusieurs raisons possibles. Tu peux vouloir utiliser des threads pour traiter de manière parallèle des évènements parallèles (connexions réseau ^^); ou bien pour diviser le temps de calcul d'un gros calcul par jusqu'à ton nombre de CPU ; ou bien pour gérer séparément des ressources qui sont séparées et qui ont des contraintes d'accès différentes… (interface graphique vs traitement long en arrière plan)
Les possibilités sont bien sûr plus étendues quand tu possèdes plusieurs cœurs CPU, puisque tu as la possibilité de faire effectuer plein de travail vraiment parallèle à ton CPU ou bien d'économiser de l'énergie (en travaillant moins fort/plus vite, donc moins longtemps), sinon, en dehors de ça, les threads vont surtout te servir à simplifier ton développement en te permettant de découpler différents traitements entre eux. (typiquement le truc de l'interface graphique et du traitement en arrière plan)

GoldenCrystal (./14) :
SI tu devais choisir une fréquence au pif, tu aurais plutôt intérêt à choisir 60Hz ou un multiple…

Je suis d'accord, j'y ai bien pensé, mais comme par hasard ça marchera chez moi, même si ma méthode est complètement pourrie, et c'est pas le but du jeu


Sinon, merci pour ta réponse sur les threads. Ca faisait bien partie de ma question initiale.

Et donc, ce que je proposais en ./10, c'est pas complètement déconnant comme méthode ?

Folco : ça va dépendre aussi des caractéristiques de ton jeu.

Le temps de dessin d'une frame est-il :
- négligeable,
- non négligeable, mais suffisamment court pour que du 60 FPS soit faisable partout,
- susceptible d'être plus long que la durée d'une frame, mais relativement constant d'une frame à l'autre,
- susceptible d'être plus long que la durée d'une frame et de varier beaucoup d'une frame à l'autre ?

Tes animations/phénomènes physiques peuvent-ils être recalculés en temps réel pour s'adapter au framerate, ou pas ?

As-tu des contraintes de précision à court terme (telle animation doit prendre x millisecondes) et/ou à long terme (le niveau doit durer 5 minutes) ?

Y a-t-il d'autres sources de synchronisation qui entre en jeu ? (bande son, jeu en réseau...)

Veux-tu un jeu parfait en 60 Hz mais dégradé aux autres fréquences, ou privilégies-tu l'indépendance par rapport à la fréquence de refresh ?

Le tearing est-il considéré comme un problème ou pas ?

GoldenCrystal (./14) :
Sinon, si SDL n'est pas capable de gérer le VSync en mode fenêtré, le problème vient certainement directement de SDL et pas de Windows... (La synchro VSync en mode fenêtré est peut-être moins fiable (ne marche pas forcément sur *n'importe quelle* config logicielle/matérielle), mais c'est malgré tout une fonctionnalité supportée...)

Que se passe-t-il lorsque la fenêtre est à cheval sur deux écrans ?

Nalfus (./11) :

Kevin Kofler (./9) :
Effectivement, le test-and-set est l'opération atomique la plus courante, et j'avais oublié qu'il y a ça aussi sur le 68k alors que ça ne sert pas du tout sur le 68000 de base.

Sérieux ?

Je vois mal du multithread sérieux sur le 68000 de base, mais bon, c'est vrai qu'avec les auto-ints, on y arrive, et alors le tas peut servir. Mais le CPU est plutôt limite pour ça.

Pourtant, il y a eu des stations de travail à base de 68000 dans les années 80.

Dans les machines plus "grand public", il y a aussi eu l'Amiga qui avait un OS multitâche dès le départ.

Oui, il y a eu des environnements multitâches et même multi-utilisateurs sans MMU, totalement inimaginable de nos jours. La sécurité d'un tel système était une passoire, n'importe qui pouvait manipuler la mémoire des autres utilisateurs, et il y avait en général aussi moyen de passer en mode superviseur.

Il doit être possible de rajouter un MMU externe au 68000 (ou d'autres processeurs sans MMU), mais ça n'a pas été fait à l'époque (du moins dans certains cas).

Kevin Kofler (./18) :

Nalfus (./11) :

Kevin Kofler (./9) :
Effectivement, le test-and-set est l'opération atomique la plus courante, et j'avais oublié qu'il y a ça aussi sur le 68k alors que ça ne sert pas du tout sur le 68000 de base.

Sérieux ?

Je vois mal du multithread sérieux sur le 68000 de base, mais bon, c'est vrai qu'avec les auto-ints, on y arrive, et alors le tas peut servir. Mais le CPU est plutôt limite pour ça.

Ce n'est pas plutôt pour un environnement multi-processeur en 68000 ?

Mais qui utilise ça?

les vieux calculateurs de trains, d'avions, et bien d'autres.

Et en général un 68000 n'était pas seul, il y avait au moins d'autres processeurs/copro qui pouvait prendre la priorité au 68000, donc l'instruction TAS est justifié.

Zerosquare (./16) :
- négligeable

Oui, je pense. Un jeu de plateforme 2D de 50*30 tiles (32*32 chacun) ne doit pas avoir de mal à se rafraichir 60 fois par secondes amha, sinon c'est que j'ai raté quelque chose façon grandiose...

Zerosquare (./16) :
Tes animations/phénomènes physiques peuvent-ils être recalculés en temps réel pour s'adapter au framerate, ou pas ?

Non. Et tu soulèves un truc pas con (enfin, moi j'y avais pas pensé...) : si tu te cales sur le framerate, et non sur le temps absolu, faut que la vitesse de tout ce que tu fais soit à géométrie variable pour s'adapter à toutes les fréquences.

Zerosquare (./16) :
As-tu des contraintes de précision à court terme (telle animation doit prendre x millisecondes) et/ou à long terme (le niveau doit durer 5 minutes) ?

Aucunement.

Zerosquare (./16) :
Y a-t-il d'autres sources de synchronisation qui entre en jeu ? (bande son, jeu en réseau...)

Non.

Zerosquare (./16) :
Veux-tu un jeu parfait en 60 Hz mais dégradé aux autres fréquences, ou privilégies-tu l'indépendance par rapport à la fréquence de refresh ?

L'indépendance. J'imagine qu'en synchronisant la fréquence des entrées sur un temps absolu (ie "60 Hz quelque soit la plateforme"), il est facile d'adapter le framerate, non ?

Zerosquare (./16) :
Le tearing est-il considéré comme un problème ou pas ?

Tu parles des effets induits par la suppression de la synchro verticale ? Non.


J'ai commencé à coder comme ça :
-> un thread qui appelle tous les 1s/60 le gestionnaire d'évènements. Suite à quoi il y a le rendering, qui met un flag ready_to_draw à vrai.
-> un thread qui regarde le flag, et qui fait un SDL_Flip quand c'est prêt, puis remet le flag à false

Ca fait une seule variable partagée entre les deux threads, donc rien de compliqué question locks.

C'est correct comme méthode ? En tout cas, la vitesse du jeu est réglée sur un timer, vu que c'est la fréquence des évènements qui régule la vitesse de la physique et des animations.

Euh non, c'est con ce que je fais, aucun intérêt.
- faut que le thread qui gère les évènements dise quand il a fini la gestion.
- un autre thread attaque alors le rendering en s'appuyant sur une copie des données du jeu, puis appelle SDL_Flip quand il a fini

C'est mieux, non ?

Ouep …

Folco (./24) :

Zerosquare (./16) :
- négligeable

Oui, je pense. Un jeu de plateforme 2D de 50*30 tiles (32*32 chacun) ne doit pas avoir de mal à se rafraichir 60 fois par secondes amha, sinon c'est que j'ai raté quelque chose façon grandiose...

Ben, à vrai dire, ça dépend beaucoup de la façon dont tu t'y prends…

Zerosquare (./16) :
Tes animations/phénomènes physiques peuvent-ils être recalculés en temps réel pour s'adapter au framerate, ou pas ?

Non. Et tu soulèves un truc pas con (enfin, moi j'y avais pas pensé...) : si tu te cales sur le framerate, et non sur le temps absolu, faut que la vitesse de tout ce que tu fais soit à géométrie variable pour s'adapter à toutes les fréquences.

Ouais mais dans ce cas il faut que tu fasses des vraies équations en minimisant les approximations. (Pour un jeu de plateforme, j'en vois franchement pas l'intérêt )

Zerosquare (./16) :
Veux-tu un jeu parfait en 60 Hz mais dégradé aux autres fréquences, ou privilégies-tu l'indépendance par rapport à la fréquence de refresh ?

L'indépendance. J'imagine qu'en synchronisant la fréquence des entrées sur un temps absolu (ie "60 Hz quelque soit la plateforme"), il est facile d'adapter le framerate, non ?

Je suggère 120Hz (comme toujours ) juste pour être failproof… Quelle que soit la fréquence d'affichage réelle (≤ 120Hz), tu auras au minimum un rafraîchissement de l'état du jeu par image. (En pratique ça peut capoter un peu vers 90 FPS ou au dessus, mais "peu" de chances que ça arrive, et encore moins que ça se voie )

J'ai commencé à coder comme ça :
-> un thread qui appelle tous les 1s/60 le gestionnaire d'évènements. Suite à quoi il y a le rendering, qui met un flag ready_to_draw à vrai.
-> un thread qui regarde le flag, et qui fait un SDL_Flip quand c'est prêt, puis remet le flag à false

Ca fait une seule variable partagée entre les deux threads, donc rien de compliqué question locks.

C'est correct comme méthode ? En tout cas, la vitesse du jeu est réglée sur un timer, vu que c'est la fréquence des évènements qui régule la vitesse de la physique et des animations.

Ben du coup, c'est plus utile de te dire que c'était pas bon

GoldenCrystal (./26) :
(En pratique ça peut capoter un peu vers 90 FPS ou au dessus, mais "peu" de chances que ça arrive, et encore moins que ça se voie )

avoir du frame skipping une fois sur trois, non ?

Et euh... ton "ouep" est pas très emballé, c'est "suffisamment correct, pas la peine d'aller chercher un truc overkill", ou alors "c'est exactement ça qu'il faut faire" ?

Heu, la première option.
C'est juste qu'il faut que tu fasses attention à l'opération de "copie des données du jeu", parce que ton code de rendu n'aura pas besoin de toutes les données du jeu, et que tout copier peut être largement overkill. (Dans tous les cas je pense que faire du multithreading pour un jeu simple c'est overkill, mais ça peut te permettre d'apprendre comment ça marche… ^^)

GoldenCrystal (./28) :
Dans tous les cas je pense que faire du multithreading pour un jeu simple c'est overkill, mais ça peut te permettre d'apprendre comment ça marche… ^^

C'est aussi le but. J'étais tout émoustillé en faisant mon premier MutexP

Et oui pour les données, pas de souci bien sûr.

(Par contre, les primitives de synchronisation de SDL c'est de la merde en boîte. Pour avoir regardé un peu le code la dernière fois qu'on a touché le sujet, je me suis aperçu qu'ils utilisent des primitives de synchronisation du noyau sur Windows (=syscall…), au lieu d'équivalents légers avec les mêmes fonctionnalités…)