Bonjour,  
 
je réfléchis aujourd'hui à la mise en place d'un tetris (ou pacman, à voir) en multijoueurs.
 
Le souci que je me pose, est que dans les sockets, nous ne pouvons pas envoyer de pointeurs, ou alors, il faut les convertir en tableau de char, tableau d'int, etc..
 
Alors, moi qui n'ai jamais codé utilisant la SDL, est-ce que quelqu'un pourrait me dire si c'est possible de voir l'écran de notre adversaire en temps réel sans consommer un max de ressources ?
Faut-il envoyer un gros paquet contenant toute l'image ou plein de petits packets au fur et à mesure du temps ?
 
Aussi, y a-t-il un moyen d'envoyer et de recevoir en même temps sans abuser de select ?
 
Car personnellement, j'utilise pour un autre projet:

 
ça veut dire que pour envoyer et recevoir il faut faire ça ?
 

 
Merci pour vos conseils

Déjà, tu peux utiliser l'extention dédiée au réseau de SDL, ca te facilitera un peu la vie.
 
Ensuite, tu peux tout à fait te débrouiller pour avoir un jeu déterministe (connaitre des deux côtés du réseau la séquence de pièces qui va arriver) et ne transmettre que la liste des mouvements avec un identifiant de frame à laquelle ca s'est passé. Du coup, il ne te reste qu'à faire une simulation locale de ce que l'autre joueur fait et à l'afficher à côté.

Merci de ta réponse rapide.
 
Si je posais cette question (pour la manière dont je vais envoyer les packets et les recevoir) c'est parce que je comptais faire plusieurs modes:
 
un mode "j'te-fais-perdre-le-plus-vite-possible" (le joueur 2 envoie les pièces au joueur 1)
un mode "concours" (les 2 joueurs ont les mêmes pièces, et c'est celui qui ne perd pas le premier qui gagne)
un mode "pwnage" (quand un joueur réussit à enlever des lignes, ce même nombre de lignes est envoyé dans l'écran de l'autre joueur)
 
Donc je ne veux pas "ruser pour arriver à `presque` le résultat", mais bien "arriver au résultat".
 
Merci pour l'info de l'extention réseau du SDL
Pendant ce temps, je me renseigne sur la SDL et les réseaux y compris et je reviendrai vers ce forum.
 
Merci encore.

Ah non, mais se servir du côté déterministe, synchroniser les frames et ne transmettre que les actions de l'utilisateur, c'est pas de la ruse, c'est simplement ce qui se fait dans des jeux tout à fait respectable (c'est une pratique très courante dans jeux de stratégie, mais c'est aussi sur ce genre de principe que repose la transmission des niveaux dans un diablo ou ce genre de chose)
 
Tu peux effectivement vouloir transmettre tout le tableau, mais c'est pas nécessairement recommandé. En mieux, tu peux aussi transmettre des "différences" quand le tableau change (si tu considères que tu ne montres pas la pièce actuellement manipulée par un joueur, ca peut réduire ton traffic ... Et je crois que c'est ce que faisait tetrinet ... Auquel tu peux jeter un oeil si tu veux de l'inspiration sur du tetris en réseau)
 
Pour en revenir à ton histoire de select, en général on fait un thread réseau qui se charge de réceptionner les données et de les mettre en forme pour que ce soit utilisable par le reste du jeu. Du coup, tu n'as pas à te soucier de mélanger des attentes de réception et des envois.
 

Envoyer toute l'image c'est hyper dégueu comme technique, mettons tu as simplement ta fenêtre en 800x600/RGB8, bah ça te fait 1.7Mo à envoyer à chaque maj du screen
Ce que tu peux tenter de faire, c'est peut être juste envoyer les touches pressées par l'adversaire (mais à la moindre perte, toufoulcamp).

Bref, j'pense que l'idéal c'est effectivement une synchronisation des tableaux en faisant la maj des parties modifiées (pas beaucoup d'octets à envoyer), après tout dépend de comment ton jeu est implémenté.

edit : Et +1 pour le thread, c'est ce que j'avais fait pour un jeu sur internet, un thread récupérait en boucle tout les paquets, les empilaient dans une liste et ensuite à chaque début de maj de ton jeu, tu traites les paquets. Même chose dans l'autre sens, lorsque tu veux envoyer tu remplis une liste et tu envois à la fin des majs.

Salut salut, je viens donner des nouvelles !
 
Mon tetris est presque complet, il ne manque plus que la suppression des lignes...
 
Par contre je ne fais pas de double buffering (sans doute la flemme qui fera qu'un jour, quand je m'ennuirai, je sais ce que j'aurai à faire)
C'est effectivement la meilleure solution, même si en réalité je n'envoie pas 1,7 Mo comme tu peux le dire.
A la limite, comme j'ai un tableau rempli de chiffres entre 0 et 9, si j'envoie tout le tableau (une case représentant 50*50 pixels), j'envoie au final 13*20 soit 260 octets.
 
Donc avec le double buffering je devrai envoyer environ 16 octets. Pas trop négligeable.
Je pense que vous avez raison
 
Et en effet, pour la touche envoyée par l'adversaire, en se basant sur le temps, c'est peut-être pas plus mal!
Merci pour l'idée, j'y penserai si vraiment ça marche pas trop.
 
(je posterai à mon réveil une vidéo de ce que ça donne pour le moment si vous voulez voir ce que ça donne )
 
EDIT : Je n'ai en fait pas dormi, mais voici la vidéo ! http://www.youtube.com/watch?v=IRXZ37KsNUA
EDIT 2 : Descente des pièces automatique + suppression des lignes complètes : fait
EDIT 3 : Points mis en place + pièce suivante visualisable + mise au pause possible

Je vois difficilement le rapport entre double buffering et volume de données à envoyer sur le réseau ...
Si tu sais que tes valeurs sont spécifiquement entre 0 et 9, tu peux sans doute t'arranger pour mettre ton tableau en 130 octets au lieu de 260 en n'allouant que 4 bits à chaque case.
 
Pour la vidéo, je suis déçu, je m'attendais à voir le résultat du mode réseau

Haha, en 3 jours seulement ?
 
Non en fait actuellement ce que je cherche à faire, c'est une amélioration de l'usage du CPU, car en effet, ça me pompe de 20 à 40% sur chaque processeur, sachant que j'ai un i7 (2,8 ou 3Ghz, me souviens plus).
 
Ducoup j'ai essayé de créer un deuxième tableau (qui est égal au premier), pour que le premier puisse se modifier, et à ce moment, je vérifie les deux tableaux, si ils ont une valeur identique, je ne fais rien, sinon, je met la valeur du tableau qui a été modifié en avant.
 
Mais je ne comprends pas pourquoi ça ne marche pas, ça fait 1 jour que je suis sur cette connerie
 
(et puis même quand ça marche, ca améliore pas les perfs...)

Ton problème de perfs vient très probablement du remplissage de tes surfaces SDL qui doit être fait en soft. Si tu veux te soucier de performance, sors un profiler. Ca ne sert pas à grand chose d'optimiser sans, vu que tu vas perdre ton temps à améliorer des trucs négligeables.

Ah ouais.. un petit screen :
 
Est-ce que si je met des sprites au lieu de cubes dessinés avec SDL_FillRect, ça sera + performant ?

Peut-être que tu pourrais simplement stocker tes carrés pré-remplis à coup de fill rect. Si ton buffer de rendu est en mémoire vidéo et tes carrés aussi, le blit de tes carrés pour composer ton image sera peut-être plus rapide.

Edit : d'ailleurs, je ne suis pas sur de bien voir. display_actual, ca utilise SDL_FillRect pour quel motif ? Ton do_square est bien appelé pour chaque carré pour raffraichir l'intégralité de ton écran, j'ai bien compris ?

 
Oui, c'est ultra crade...
 
Ah, et :
 

 
C'est pour ça qu'utiliser des sprites, ça pourrait être moins consommateur.

Ah vu ton code, oui, tu as tout intérêt à te faire un ensemble de carrés de chaque couleur stockés dans une surface dédiée (ou chacun dans sa propre surface, mais ca parait overkill) et à blitter depuis cette (ces) surface(s) plutôt que de redessiner les carrés à chaque fois. C'est probablement ce que tu veux dire quand tu parles de sprite.
 
Pareil pour ton background, faire une seul fois des SDL_FillRect puis utiliser des blits, ca devrait aussi t'aider.

Non, quand je parle de sprite, je veux vraiment dire une image que je fais avec photoshop, par exemple.
 
Si je mets une surface avec tous mes carrés dedans, c'est bien, mais après comment je fais pour pouvoir juste envoyer une partie de la surface, sur une autre partie d'une autre surface ? (éviter d'avoir une couleur par surface et donc d'avoir 8 surfaces)

 
En gros, tu as une surface qui sert d'Atlas et ton index est une liste de rectangles donc tu stockes des SDL_Rect correspondants à tes carrés individuels à côté de la surface elle-même. La fonction de blit attend ce genre de rectangle en entrée.

 
Ca consomme plus !
 
Dans ma structure :
 

 
Avec une fonction par carré (un de chaque couleur)

essaye avec le flag SDL_HWSURFACE quand tu crées tes surfaces. Pour celle qui contient tes carrés comme pour celle que tu remplis à coups de blit

Fait, et au lieu d'utiliser 69,39 il utilise 73 dans la colonne "Self". C'est identiquement pareil....

hmmm, c'est surprenant. Tu initialises ton mode vidéo avec les flags SDL_HWSURFACE|SDL_DOUBLEBUF ?

J'initialise avec : SDL_HWSURFACE | SDL_DOUBLEBUF | SDL_ANYFORMAT

bon, ben ca devrait rouler, alors ... Au pire, tu peux aussi vérifier que les formats collent bien, mais je doute que le problème soit de là.
Tu peux toujours tenter de reséparer l'atlas, ou d'utiliser des puissances de deux pour les tailles de tes carrés, pour voir s'il y a des restrictions ridicules qui empêchent de faire le blit en hardware ... Parce que là, on dirait que c'est le CPU qui fait la copie de mémoire vidéo à mémoire vidéo, pour avoir un résultat aussi faible.

Edit : d'après le graph qu'on trouve là il semblerait que ce soit pourtant ce qui doit aller le mieux quand ta surface de rendu est intialisée avec du SDL_HARDWARE
Edit2 : je ne suis pas ultra familier de linux, j'ai peut-être mal interprété les résultats, à toi de me dire, du coup

Corrigez-moi si je me trompe, mais il me semble que la SDL ne se sert pas du tout de la CG

Le lien que j'ai posté ci-dessus semble prouver que ca peut utiliser une accélération matérielle. L'API ne s'y oppose pas, en tout cas. Mais vraisemblablement, ca dépend au moins du contexte d'exécution, peut-être d'options de compilation de la lib.
Bref, je suis désolé d'avoir trainé djswiti sur un terrain glissant
 

Avec un masque d'initialisation de la video, on peut apparemment se servir du GPU (je dis peut-être une bêtise), je l'ai lu dans un man...
 

Aucun problème, c'est avec l'expérience qu'on apprend, et quand on apprend, c'est de ses erreurs, donc pas de problèmes, au moins je saurai la prochaine fois
Peut etre qu'utiliser la SDL n'est pas la meilleure des solutions.
 
A l'école, (je suis à Epitech) un mec de ma promo m'a conseillé d'utiliser la SFML. Je ne me suis pas encore du tout renseigné sur cette dernière, mais il est vrai que je risque de me tourner vers cette lib graphique si les résultats ne sont pas meilleurs...
 
EDIT : j'ai remarqué une chose. Moi, je suis en 32bpp. Si j'initialise mes surfaces en 32 bpp, c'est le blit est est consommateur.
 
En revanche, si je crée des surfaces en 24bpp, c'est le SDL_Flip qui consomme (transformation 24 -> 32)
Alors, où pourrais-je trouver le juste milieu ?

l'autre solution, c'est de pousser un peu plus l'effort et de faire un peu d'OpenGl (SDL te permet d'initialiser ton mode vidéo pour) pour rendre tes carrés sous forme de quelques primitives dans l'espace de ton écran.
 
Bref pour ce que tu décris, ca ressemble à un souci de bande passante ... Du coup, j'aurais tendance à te dire de ne pas trop t'en soucier parce que ca doit être inhérent au fait de bosser en soft dans des trop hautes résolutions.
 
 
 

J'en avais presque oublié la taille de l'écran de jeu. Effectivement, ça se trouve c'est plutot performant pour jouer sur sur 1900 * 1200.
De toute façon, le mode réseau ne sera pas consommateur, puisque j'envoie seulement quelques octets par "tour de boucle".
 
Par contre, pour dessiner les deux écrans, ça, ça risque de consommer ! Donc je crois que je vais adopter une solution plus économe : réduire la taille de l'écran de jeu.

 
Yep, surtout qu'un tetris, c'est pratique pour limiter la taille de la zone à raffraichir, techniquement

Mais ça veut pas dire que je ferai des BlitSurface moins souvent! Donc à voir si ça va améliorer la consomation?

 
C'est probablement pas le coût de l'appel qui est cher, mais plutôt la copie de mémoire, ici, donc même si ton nombre d'appel rest fixe, copier moins de mémoire devrait t'apporter un gain.

Et aussi du fait que si c'est plus rapide, ça le fait plus souvent, vu que c'est une boucle.
J'ai donc décidé de rajouter un usleep(500000); et finalement ça sauve 10 à 20% de chaque processeur (un peu random disons...)
 
Donc je passe de 71 à 45 en performances avec le SDL_FillRect. (Groooos changement !!)
 
Et je n'arrive meme pas à recoder ce que j'avais fait avec les SDL_BlitSurface (et j'ai un peu pas envie.) x) Donc voilà !

ton "71 à 45", c'est en quelle unité ?
Le usleep, ca me semble foireux ... C'est censé t'aider à quoi ?

71 c'est le nombre qu'il y avait dans "Self" je pense que c'est le pourcentage à la seconde d'énergie du processeur que ça bouffe.
 
Etant donné que j'ai une boucle, si je dessine à l'écran plus vite, je vais aussi dessiner plus souvent à l'écran, c'est logique non ?
 
Donc le usleep m'aiderait  à faire une minipause avant de retourner dans la boucle..

Ok, alors visiblement, ton 71 ou 45, c'est un pourcentage du temps de l'appli. En ajoutant un usleep quelque part, tu minimises la proportion de temps passé dans le FillRect, mais tu n'accélères en rien le traitement qu'elle fait. C'est donc une fausse optim.

C'est pas une fausse optimisation.
Tu n'as pas l'air de comprendre ^^'
Je passe moins de fois dans la fonction, avec le même rendu visuel. Certes elle consomme autant, mais le fait d'ajouter un usleep évite de consommer (rafraichir l'image) pour rien.

  dans ce cas, tu dois pouvoir simplement détecter si t'as besoin de faire un raffraîchissement (que ce soit parce que l'utilisateur a bougé ou parce que la pièce doit descendre).
faire un sleep avec une durée fixe, c'est en général mauvais signe. Par contre, vouloir rendre la main à ton scheduler pour ne pas ponctionner tout le temps que ton scheduler pourrait t'allouer, c'est louable, mais ca se fait pas avec un usleep(50000)

+1 pour openGL, en projection ortho pour faire de la 2D. Par contre, je recommande pas d'utiliser la SDL avec (du moins, pas la 1.2) elle gère très mal le contexte, et il est perdu en cas de redimensionnement
 
Tu peux faire le fenêtrage avec la SFML, mais c'est un peu sortir la grosse artillerie.
Si t'as le temps, j'te conseille de faire le fenêtrage toi-même, avec X11 pour linux, et les libs pour Windows, c'est pas compliqué (que de l'initialisation en gros), et tu as masse de tutos / sources sur le net.
 
Après, l'apprentissage d'openGL c'est une autre histoire, c'est plus compliqué que la SDL mais surtout plus performant (en même temps, ça vise pas les même choses ), et les shaders c'est

Ben non, je faisais pas ça, car moi je suis un gros porc :B
Et pour moi, le C, c'est pas trop optimisé pour faire un jeu.. C'est pas de la POO quoi.
Je vois difficilement comment dire à mon programme "Attends que y'ait quelque chose qui change !". Car dans tous les cas, il y aura une boucle et/ou un sleep.
 

Je n'avais pas prévu de redimensionnement, mais je dessine tout suivant des .h (taille de la fenetre, taille des cubes, etc..)
 
Disons que oui, j'ai le temps. J'ai le temps d'apprendre
Je ne code jamais (juste jamais) sous windows ni pour windows.
Merci du conseil
 
Sinon, de retour au réseau, que dois-je utiliser ?

Si tu comptes utiliser la SFML (C++ only par contre), le module réseau est vraiment cool. Après, pour Linux en C je sais pas.

Merci

 
D'une part, tu peux faire de la POO en C, même si c'est pénible, d'autre part, la POO, c'est pas considéré optimal pour les jeux.
 
 
 
L'Epitech ne force plus la main pour aire du NetBSD plutôt que linux, maintenant ?
Et accessoirement, si t'es branché développement de jeux vidéo, tu vas en bouffer, au final, du dev sous windows, donc ce serait pas mal que tu sois ouvert là-dessus (Visual Studio est quand même très bien foutu)
Après, j'ai rien contre le fait de chercher à être cross platform au maximum, bien au contraire.
 
 
Je connais pas la SFML donc je vais pas la recommander ou non. Par contre, sur le site de la SDL, tu pourras trouver SDL_Net qui te fait une abstraction bien sympa.