IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Langage C++ Discussion :

Transfert d'image en TCP pendant un jeu en réseaux


Sujet :

Langage C++

  1. #1
    Futur Membre du Club
    Profil pro
    Inscrit en
    Février 2011
    Messages
    7
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2011
    Messages : 7
    Points : 5
    Points
    5
    Par défaut Transfert d'image en TCP pendant un jeu en réseaux
    Bonjour à tous et à toutes !

    Donc voila, tout est dans le titre.
    A l'état où mon projet est; il ne fait que prendre des belles capture d'écran (ce qui déjà pas mal ). J'ai déjà pu obtenir un bonne compression avec le format jpeg: Les images ne font que 30 à 60 ko. C'est par la méthode GDI+ que je sauvegardes les captures.

    Mais voila, je sollicite votre aide, afin de m'indiquer vers qu'elle direction aller pour la suite:
    --> Transférer les captures et autres informations vers un master sans affecter la latence du jeu. Car si le jeu en question est un FPS, hors de question d'avoir des coups de lags !! Comme Punkbuster en fait (Personnes n'auraient son code source ?? )

    Donc quelles fonctions TCP pourraient me permettre de réaliser cela ?
    Quelles termes dois-je rechercher ?
    Ne serrait-ce pas mieux d'envoyer directement la frame de capture plutôt que l'image enregistré sur le pc client... Je sais pas.

    Merci à vous.

  2. #2
    Expert éminent sénior

    Femme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2007
    Messages
    5 184
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Juin 2007
    Messages : 5 184
    Points : 17 118
    Points
    17 118
    Par défaut
    Tu as plusieurs possibilités:
    Par exemple, faire un client de capture, lancé sur le serveur, qui recevrait les demandes de screens, et ferait les captures en local.

    Tu peux aussi transférer l'image lentement (quelques kilos par secondes?).
    Ou encore, la transmettre en fin de partie, ou sur les temps morts du joueur (délai de résurrection, menu, fin de partie, etc)

    Le problème c'est la quantité de données à transmettre. Si faire la capture ne ralentit pas le joueur, il faut doser le flux parallèle pour ne pas faire laguer violemment
    Mes principes de bases du codeur qui veut pouvoir dormir:
    • Une variable de moins est une source d'erreur en moins.
    • Un pointeur de moins est une montagne d'erreurs en moins.
    • Un copier-coller, ça doit se justifier... Deux, c'est un de trop.
    • jamais signifie "sauf si j'ai passé trois jours à prouver que je peux".
    • La plus sotte des questions est celle qu'on ne pose pas.
    Pour faire des graphes, essayez yEd.
    le ter nel est le titre porté par un de mes personnages de jeu de rôle

  3. #3
    Futur Membre du Club
    Profil pro
    Inscrit en
    Février 2011
    Messages
    7
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2011
    Messages : 7
    Points : 5
    Points
    5
    Par défaut
    Bonjour et merci de votre réponse.
    Citation Envoyé par leternel Voir le message
    Tu as plusieurs possibilités:
    Par exemple, faire un client de capture, lancé sur le serveur, qui recevrait les demandes de screens, et ferait les captures en local.
    Les captures d'écrans doivent se faire côté client seulement, en effet c'est pour le surveiller.

    Citation Envoyé par leternel Voir le message
    Tu peux aussi transférer l'image lentement (quelques kilos par secondes?).
    Cela m'intéresse beaucoup, c'est à tester, mais j'ai essayé de trouver sur le net, mais j'ai pas trouvé. Il me faudrait une base en faite, quelque chose de quoi je puisse partir.

    Citation Envoyé par leternel Voir le message
    Ou encore, la transmettre en fin de partie, ou sur les temps morts du joueur (délai de résurrection, menu, fin de partie, etc)
    Là je suis d'accord aussi, mais je ne vois comment détecter un changements de carte, ou la fin du partie avec le Hooking de directX9.
    Si quelqu'un à une idée ?

    Citation Envoyé par leternel Voir le message
    Le problème c'est la quantité de données à transmettre. Si faire la capture ne ralentit pas le joueur, il faut doser le flux parallèle pour ne pas faire laguer violemment
    Euh là j'ai pas trop compris

  4. #4
    Expert confirmé

    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2007
    Messages
    1 895
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Septembre 2007
    Messages : 1 895
    Points : 4 551
    Points
    4 551
    Par défaut
    Citation Envoyé par benjahwest Voir le message
    Bonjour et merci de votre réponse.

    Les captures d'écrans doivent se faire côté client seulement, en effet c'est pour le surveiller.
    Le joueur va adorer l'idée

    Citation Envoyé par benjahwest Voir le message
    Cela m'intéresse beaucoup, c'est à tester, mais j'ai essayé de trouver sur le net, mais j'ai pas trouvé. Il me faudrait une base en faite, quelque chose de quoi je puisse partir.
    C'est de la logique - tu n'as pas besoin de te baser sur le code de qui que ce soit. Tu as une socket TCP ; au lieu d'envoyer toute l'mage directement, tu n'envoie que quelques dizaines - ou centaines d'octets à chaque frame (ou toutes les 10 ms). De cette manière, tu limites l'impact sur l'autre flux de données (les données propres au jeu).

    Citation Envoyé par benjahwest Voir le message
    Là je suis d'accord aussi, mais je ne vois comment détecter un changements de carte, ou la fin du partie avec le Hooking de directX9.
    Si quelqu'un à une idée ?
    Meh ? C'est toi qui fait le jeu, donc tu sais parfaitement lorsqu'une map est terminée - du coté client comme du coté serveur. Si ton serveur n'est pas capable de savoir ça, alors tu risque d'avoir de gros soucis

    Citation Envoyé par benjahwest Voir le message
    Euh là j'ai pas trop compris
    En gros : QoS, pour quality of service. Tu as deux flux à envoyer : le flux de données correspondant au jeu lui-même (probablement en UDP, n'est-ce pas ?) et le flux TCP contenant l'image. Il te faut trouver un moyen de donner une priorité à chaque flux, de manière à ce que le flux prioritaire passe toujours avec un très faible latence, pendant que le flux non prioritaire envoie ses données petit à petit.
    [FAQ des forums][FAQ Développement 2D, 3D et Jeux][Si vous ne savez pas ou vous en êtes...]
    Essayez d'écrire clairement (c'est à dire avec des mots français complets). SMS est votre ennemi.
    Evitez les arguments inutiles - DirectMachin vs. OpenTruc ou G++ vs. Café. C'est dépassé tout ça.
    Et si vous êtes sages, vous aurez peut être vous aussi la chance de passer à la télé. Ou pas.

    Ce site contient un forum d'entraide gratuit. Il ne s'use que si l'on ne s'en sert pas.

  5. #5
    Futur Membre du Club
    Profil pro
    Inscrit en
    Février 2011
    Messages
    7
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2011
    Messages : 7
    Points : 5
    Points
    5
    Par défaut
    Ah j'ai du mal me faire comprendre en fait; Je n'ai pas fait un jeu, loin de là !
    J'ai fait un logiciel de capture d'écran, tout ceci est extérieur au jeu. Voila pourquoi je doit hooké le jeu afin d'y parvenir. Une dernière chose, l'utilisateur sera au courant de ce que fera le logiciel car c'est pour un but commun, l'anti-triche.

    Mais bon, si j'ai bien compris, en limitant le nombre d'octets lors du transfert donc en TCP, cela me permettrait d'éviter d'affecter le ping du joueur.
    Dois-je utiliser TCP NODELAY ou quelque chose comme ça ?

  6. #6
    Expert confirmé

    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2007
    Messages
    1 895
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Septembre 2007
    Messages : 1 895
    Points : 4 551
    Points
    4 551
    Par défaut
    Citation Envoyé par benjahwest Voir le message
    Ah j'ai du mal me faire comprendre en fait; Je n'ai pas fait un jeu, loin de là !
    J'ai fait un logiciel de capture d'écran, tout ceci est extérieur au jeu. Voila pourquoi je doit hooké le jeu afin d'y parvenir. Une dernière chose, l'utilisateur sera au courant de ce que fera le logiciel car c'est pour un but commun, l'anti-triche.

    Mais bon, si j'ai bien compris, en limitant le nombre d'octets lors du transfert donc en TCP, cela me permettrait d'éviter d'affecter le ping du joueur.
    Dois-je utiliser TCP NODELAY ou quelque chose comme ça ?
    J'avais mal compris

    Sur l'utilisation de TCP NODELAY : non ; ça ne fait pas ce que je pense que tu crois (et par défaut, on est en nodelay dans la plupart des cas).

    Il te faut vraiment limiter toi même l'envoi de données sur la socket TCP. Le plus simple : se fixer un budget par seconde (par exemple, 2ko par seconde), découper ça en plusieurs envois (par exemple 10, un toutes les 100 ms), et envoyer un packet de la taille correspondante à chaque envoi.

    En pseudo-code :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
     
    t = taille totale de l'image en octets
    s = socket TCP
    b = budget par seconde en octets
    i = buffer image
    n = nombre d'envoi par seconde
     
    b_envoi = b / n;
    i_end = i + t;
    while (i < i_end) {
      send(s, i, b_envoi);
      i += b_envoi;
      sleep_milliseconds(1000 / n);
    }
    En choisissant bien b et n, tu peux te retrouver à n'envoyer que des petits paquets TCP, à une fréquence qui ne mettra pas en péril le transfert des données de jeu.
    [FAQ des forums][FAQ Développement 2D, 3D et Jeux][Si vous ne savez pas ou vous en êtes...]
    Essayez d'écrire clairement (c'est à dire avec des mots français complets). SMS est votre ennemi.
    Evitez les arguments inutiles - DirectMachin vs. OpenTruc ou G++ vs. Café. C'est dépassé tout ça.
    Et si vous êtes sages, vous aurez peut être vous aussi la chance de passer à la télé. Ou pas.

    Ce site contient un forum d'entraide gratuit. Il ne s'use que si l'on ne s'en sert pas.

  7. #7
    Expert éminent sénior

    Femme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2007
    Messages
    5 184
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Juin 2007
    Messages : 5 184
    Points : 17 118
    Points
    17 118
    Par défaut
    Je n'ai pas tout compris. Où interviens-tu dans cette histoire?

    Supposons un jeu en réseau classique, avec ses dix joueurs et son serveur.
    De ce que j'ai cru comprendre, chacun des dix postes joueurs lance un programme de captures d'écran pour surveiller les joueurs.
    Ce programme est censé envoyer les captures à un serveur qui sera chargé de les comparer.
    Si c'est bien cela, ca ressemble diablement à la problématique d'un keylogger.

    Une solution, c'est d'avoir une lib de capture vidéo pendant la partie puis chercher l'écran de fin de partie (reconnaissable au panneau de score, au VICTORY, etc) et d'envoyer au serveur ce qui ne l'a pas été depuis la dernière fin de partie (donc la vidéo de la partie).

    Mais un anti-triche ne peut pas fonctionner avec l'accord du joueur. Pour qu'il soit utile, cela doit se faire plus ou moins sans son intervention.
    Mes principes de bases du codeur qui veut pouvoir dormir:
    • Une variable de moins est une source d'erreur en moins.
    • Un pointeur de moins est une montagne d'erreurs en moins.
    • Un copier-coller, ça doit se justifier... Deux, c'est un de trop.
    • jamais signifie "sauf si j'ai passé trois jours à prouver que je peux".
    • La plus sotte des questions est celle qu'on ne pose pas.
    Pour faire des graphes, essayez yEd.
    le ter nel est le titre porté par un de mes personnages de jeu de rôle

  8. #8
    Futur Membre du Club
    Profil pro
    Inscrit en
    Février 2011
    Messages
    7
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2011
    Messages : 7
    Points : 5
    Points
    5
    Par défaut
    Merci pour vos précisions à tout les deux.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. [TCP]Transfert d'image par le réseau
    Par seeme dans le forum Qt
    Réponses: 3
    Dernier message: 13/07/2009, 02h04
  2. mettre image ou texte pendant chargement d'un menu
    Par Mitaka dans le forum Général JavaScript
    Réponses: 3
    Dernier message: 16/02/2006, 12h44
  3. transfert d'images client/serveur
    Par anarpunk dans le forum Web & réseau
    Réponses: 6
    Dernier message: 31/01/2006, 18h20
  4. Réponses: 16
    Dernier message: 28/11/2005, 20h09
  5. [VB6] [Graphisme] Transfert d'image pixel par pixel
    Par SpaceFrog dans le forum VB 6 et antérieur
    Réponses: 16
    Dernier message: 15/10/2002, 10h53

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo