Discussion :

[shuygar]

Salut tout le monde,

Je m'apprette à faire le fameux snake en C ( ou C++ ), j'ai (comme dit la bonne habitude ) pris ma feuille et mon crayon en esseyant d'arriver a une structure de code plus ou moins vraisemblable.

Dans un premier temps, il me faudrai donc d' un coté un serpent qui bouge et de l'autre une interface I/O ( que le joueur puisse controller le serpent ).

On m'a parlé de threads pour pouvoir faire les 2 tâches en même temps, mais voila que depuis quelque jours que je lis sur les pthreads (gnu/linux) et ça me semble quandmême pas mal compliqué, surtout si après je veux en faire une version graphique ( GTK par exemple ).

Donc voila, je veux savoir si je suis en train de perdre mon temps avec les fameux pthreads ou si l'on utilse vraiement des threads pour faire des jeux-vidéos.

J'ai aussi pensé à l'utilisation d'événements ( très utilisé pour les interfaces graphiques ) mais je n'ai pas la moindre idée de comment l'appliquer à mon serpent

PS: On m'a aussi évoqué la fonction kbdhit() (DOS) mais cela ne m'interesse pas vraiement, mon objectif étant d'avoir plusieurs procès en même temps.

[Swoög]

pour ce qui est du multi tache, il n'y a pas 36 solution...
Je crois qu'il te faudra effectivement passer par les threads...

tu parlais d'évènements... mais le plus souvent, programmation évènementielle sous-entend mutlithread

[shuygar]

D'accord donc je continue ma guerre avec les pthreads. D'autre part, est-ce que la plupart des jeux les utilisent ? Ou y-a-til d'autres solutions / manières ?

Donnezmoi des pistes :-)

[Swoög]

Oui, je pense qu'on peut dire que la plupart des jeux utilisent les threads...

Il y a bien un autre moyen, mais il en est très proche, ce sont les process...

pour se représenter la chose, disons que chaque application a (peut avoir) plusieurs process et chaque process a (peut avoir) plusieurs threads...

Ensuite, je n'ai jamais utilisé les process personellement... et même si ç'a l'air compliqué de prime abord, tu verra qu'en fait la lib pthread est très simple d'utilisation
Malheureusement, je ne possède pas de tuto sur cette lib...

[shuygar]

Bein merci beaucoup pour ta réponse, depuis quelques jours je me demandai vraiement si j'essayai de peindre la lune avec une plume.
Je continue donc ma croisade, hier je suis allé faire un tour sur Amazon et je pense que je finirai par achetter un livre à propos des pthreads. Pour le moment tous les docs que j'ai trouvé sur Internet me semblent difficiles de comprendree ou incomplets ...

D'autre part, si je choisi les Pthreads j'assume que mon jeux ne sera plus portable sur Win32, il y a quoi comme lib de threads sinon ?

Merci encore.

[Swoög]

alors, phtread est la libraire POSIX pour les threads (c'est à dire UNIX et BSD je crois) pour windows, il te faut utiliser WinThread (go to MSDN)

à l'époque, j'avais commencer à réempaqueter les deux API dans de classes (C++) mais il faudra que j'y retravaille... Quand ce sera fait, tu pourras peut-être t'en inspirer pour faire un empaquetage en C...

l'avantage, c'est que tu as quelques .h, .o/.c et directives de compilation à changer, au lieu de devoir modifier tout le code qui utilise les threads

[ash.ice.loky]

Lol je vois pas l'interet d'utiliser les Treads Posix pour un jeu et encore un moins un serpent (si c'est bien de ca dont tu parles).

Les threads (dont les Pthread ne sont qu'un exemple propre a linux, tu peux aussi prendre ceux de la SDL qui sont portable ou ceux de boost ou autre) servant surtout lors de calcul tres compliqué afin de parralélisé tout ca. Ensuite dans la pluspart des cas tu reparti tes "threads" a des processeur afin de tout traité mais dans ton cas c'est completement inutile.

Regarde sur le site la FAQ de la SDL, on y parle de thread propre a la librairie si jamais ca t'interesse, mais dans ton cas c'est inutile sauf pour si tu veux apprendre comment ca marche.

[shuygar]

Lol je vois pas l'interet d'utiliser les Treads Posix pour un jeu et encore un moins un serpent (si c'est bien de ca dont tu parles).

Les threads (dont les Pthread ne sont qu'un exemple propre a linux, tu peux aussi prendre ceux de la SDL qui sont portable ou ceux de boost ou autre) servant surtout lors de calcul tres compliqué afin de parralélisé tout ca. Ensuite dans la pluspart des cas tu reparti tes "threads" a des processeur afin de tout traité mais dans ton cas c'est completement inutile.

Regarde sur le site la FAQ de la SDL, on y parle de thread propre a la librairie si jamais ca t'interesse, mais dans ton cas c'est inutile sauf pour si tu veux apprendre comment ca marche.

La SDL je ne l'ai pas trop touché pour le moment, je le fait sur console puis après j'essairai de switcher en graphique.

Donc finalement, les pthreads ne sont pas utitilisé dans le cas ou l'on veut avoir une interface i/o pendant que le jeu se déroule ou ce genre de choses simples, mais pour faire des opérations qui demandent pas mal de CPU c'est bien ça ?

Je fait donc servir des simples bucles ? Pas la peine de me casser la tête ?

[MatRem]

Une boucle toute simple peut en effet largement suffir pour la plupart des "petites" applications. Et là c'est sur que c'est le cas.

[Invité]

Hem... comment dire, les threads pour ca... non, ca va faire repetition...

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
while(fini == false) {
   if((event = get_events()) == true ) {
      //Ici le code pour deplacer le serpent en fonction
      //de la touche appuyée
   }
 
   mettre_buffer_a_zero();
   deplacer(serpent);
   swap_buffer();
}

est-ce que cela n'irait pas ? (bon, ce n'est pas du code... mais ca devrait peut etre t'eclairer...)

[ash.ice.loky]

il me semble shuygar que tu confonds un peu les threads et le multi-processeurs.

un thread peut-etre assimilé à une émulation d'un environement multiproccesseurs. Quand tu créés un thread tu imagines un proc supplémentaire pour pour traiter le thread.

le probléme dans ton cas 2 thread un pour l'interface et l'utre pour le jeu :
- thread graph sur PC A
- thread jeu sur PC A
mais ton proc ne peut pas faire les 2 à la fois donc tes thread serons traité de facon séquentiel et non parralelle.

Je le répète (je c'est je radote :-) )mais les thread ne sont utile que dans un monde a grande échelle ex :
- un serveur qui communique avec plein de PC, chaque thread est envoyé sur un PC pour X raisons (synchronisation, rapidité, ...)
- un PC dans un réseau qui doit faire de grand algo, alors on trouve les parties paralelle de l'algo et on les envoi a plusieurs PC pour tout accelerer.

AUtrement c'est inutile !

[ash.ice.loky]

Au fait la SDL permet de faire énormément de choses et pas seulement du une interface, un peu à la facon de l'API WIN32 comme :
- les I/O
- une GUI
- le Son
- le reseau
- les threads
...

[bafman]

arggg... commencer à coder un jeu avec des threads... un candidat au suicide
en fait dans les jeux video, les threads sont tres peut utilisé pour plusieurs raisons :

• les problemes de syncronisations ne sont pas forcement evidents surtout quand on veut faire du temps réel et ou bloquer un thread peut impliquer l'arret temporaire du jeu (generalement imperciptible mais c'est un risque à prendre en compte)
• l'utilisation de thread implique des changement de contextes suplementaires, ce qui alourdit le programme et le rend donc potentiellement plus lent

dans le faits, les thread ne sont utilisé dans les jeux que pour le reseau et le son (parfois aussi pour les entrée/sortie mais c'est plus rare car pas indispenssable.)

neanmoins, on voit arrivé de plus en plus de librairies pour les jeux qui sont multi threadé (un tres bon exemple est la librairie physX qui a une gestion tres bien concue du multi processus), mais elle sont justement crée de facon a ce que le developpeur n'ai pas à gerer lui même les problemes de synchronisations...

en gros, l'utilisation de thread est à reserver au cas ou :

• c'est indispenssable au bon deroulement du programme (son, reseau...)
• on peut gagner réelement en vitesse d'execution (calcule physique sur une carte/core separé comme pour le physX)

[mat.M]

On m'a parlé de threads pour pouvoir faire les 2 tâches en même temps,

On n'utilise pas des Threads pour un simple Snake !!!
A quoi cela va-t-il te servir ?
Et ça risque de ralentir le jeu ...


A croire que cela soit contagieux : on veut faire compliqué alors qu'on peut faire simple !
Fais le plus simple possible sinon c'est ingérable

[KiLVaiDeN]

Bonjour,

Je pense que faire des threads est nécessaire quand on a envie de faire deux actions en simultané, ce qui n'est pas ton cas, car tu as envie que ton serpent réagisse tout de suite après l'appui sur ta touche.

Imaginons le cas de threads pour le serpent : tu appuierais sur les touches de déplacement, et cette séquence de touche irais dans une queue; ton thread d'affichage du serpent déplacerait le serpent en vidant la queue, et quand ta queue serait trop grande, tu aurais un temps de latence entre le moment où tu appuierais, et le moment où le serpent se déplacerait, ce qui serait ennuyeux pour le gameplay

A+

[cladsam]

tu appuierais sur les touches de déplacement, et cette séquence de touche irais dans une queue;

Non surtout pas car dans ce cas le jeu serait perdu

Désolé je pouvais pas la rater

[Rafy]

Moi perso j'ai fait mon premier projet graphique il y a maintenant 2 ans :
C'était une jeu de serpent en C++, avec DirectDraw pour afficher, DirectInput pour ce qui est des périphériques, mais je n'ai pas utilisé de thread, ni de process....
Avant de surcharger le processeur avec un jeu comme un serpent il y a 2 solutions : soit c'est codé comme un porc et le proc rame dans la mer**, ou alors il ne ressemble pas trop à un serpent traditionel, il y a des effets de fou qui demande de la ressource....
J'ai mis environ 6 mois pour faire (ou commettre ) ce projet....
Avec du recul maintenant je n'aurai pas fait certaines choses de la même manière. Si tu veux des conseils, demande moi...

Pour ce qui est des jeux en multithread, je ne suis pas certain qu'énormement de jeu soient en multi thread....
Il y a énormement de contraintes : la syncronisation de l'ensemble de l'application, le calages entre les threads.... Seul les jeux très récent et encore commence à toucher au multi-threading.