Je ne sais pas ce qu'est le 4k, mais, sur un écran d'il y à 15 ans (ça va, ça remonte assez?) on avais régulièrement des résolutions de type 1024*768, en 32 bits (soit 4 octets par pixel).
Dans les 32 bits, 8 (1 octet) sont utilisés pour la transparence, aucun intérêt dans le cas d'un affichage déporté. Donc, on peut se baser sur 3 octets par pixel.
Partons de 30 FPS, soit 30 images par seconde.
30* 3* (768*1024) = 70778880 octets par seconde. Pour avoir un truc plus lisible, on divise par 1024 deux fois (pour avoir d'abord en Kio, puis en Mio, qui sont plus parlants):
70778880 / 1024 / 1024 = 69120 / 1024 = 67,5 Mio. Pour une seule instance à une résolution qui était régulièrement employée il y à 15 ans (mais pas la meilleure de l'époque, loin de là) à une vitesse médiocre (particulièrement pour un FPS) il te faudrait donc un réseau capable de supporter 67.5Mo/s par client (instance de jeu).
Je te laisse refaire le calcul avec un framerate décent (45 FPS minimum) et une résolution potable (disons 1440*900, c'est pas nickel, mais décent...), tu verras que ce n'est pas gérable, particulièrement si tu passes par du WI-FI (ou il faut prendre en compte les nombreuses pertes réseau) sans même parler du fait que le serveur devra être très costaud.
Multiplies ensuite par le nombre de joueurs dans ton LAN...
Connexion a distance par VNC, oui mais il y a pas d'autre moyens? Comme par http ?(je m'y connais pas du tout la dedans)
Les logiciels comme VNC utilisent des protocoles (un "langage privé" qui permets la communication entre plusieurs logiciels) spécialisés dans le déport d'affichage.
La plupart des formats et protocoles qui traitent avec l'audio-visuel tendent à perdre des données, afin de faciliter les calculs. Les autres, ceux qui ne perdent pas de données, sont nettement plus gourmands en terme de CPU et de RAM, au minimum (je ne sais pas à 100% si ceux-ci sont d'efficacité identique à ceux impliquant une perte de données, en terme de bande-passante (aka: taille des données) mais à CPU/RAM identique, j'en serai extrêmement surpris).
HTTP est un protocole spécialisé, à l'origine, dans la transmission de fichiers en conservant (et en transmettant) des méta-données à leur sujet (par exemple, si c'est une image, une musique, un texte, un programme...).
Étant spécialisé dans le transfert de fichiers, il y à plusieurs limites. L'une d'entre elle est l'absence d'authentification et de chiffrement. Pour l'authentification, les sites web utilisent un contournement: les cookies. C'est du bricolage, et il y à régulièrement des problèmes de sécurité avec ça.
Pour le chiffrement, ça à été résolu avec le HTTPS. Je ne connais pas assez le fonctionnement des techniques de chiffrement pour essayer d'expliquer ça à un néophyte, mais le chiffrement implique également du temps de calcul pour que les données ne soient pas transmises en clair.
De plus, la compression est généralement plus performante quand les données se répètent suivant le même modèle régulièrement. Ce n'est plus trop le cas dans les jeux modernes, toujours plus réalistes, sans parler des effets de lumière et d'ombres.
Il n'y aurait pas moyen de "compressé les données" de manière a réduire le débit ...?
La plupart des algorithmes de compression audio-visuels "perdent" des données. Les autres sont gourmands en terme de calcul.
À noter que quand je parle de temps de calcul, c'est du temps qui est dépensé des deux côté du réseau.
Au final, ce serait faisable, mais pas avec des jeux rapides. Un jeu en tour par tour? Oui, sans problème. Un jeu de stratégie, pourquoi pas, avec des graphismes au minimum probablement, par contre un FPS c'est mort.
[^] # Re: Facile
Posté par freem . En réponse au message Avis (Serveur + Gaming en lan). Évalué à 3.
Je ne sais pas ce qu'est le 4k, mais, sur un écran d'il y à 15 ans (ça va, ça remonte assez?) on avais régulièrement des résolutions de type 1024*768, en 32 bits (soit 4 octets par pixel).
Dans les 32 bits, 8 (1 octet) sont utilisés pour la transparence, aucun intérêt dans le cas d'un affichage déporté. Donc, on peut se baser sur 3 octets par pixel.
Partons de 30 FPS, soit 30 images par seconde.
30* 3* (768*1024) = 70778880 octets par seconde. Pour avoir un truc plus lisible, on divise par 1024 deux fois (pour avoir d'abord en Kio, puis en Mio, qui sont plus parlants):
70778880 / 1024 / 1024 = 69120 / 1024 = 67,5 Mio. Pour une seule instance à une résolution qui était régulièrement employée il y à 15 ans (mais pas la meilleure de l'époque, loin de là) à une vitesse médiocre (particulièrement pour un FPS) il te faudrait donc un réseau capable de supporter 67.5Mo/s par client (instance de jeu).
Je te laisse refaire le calcul avec un framerate décent (45 FPS minimum) et une résolution potable (disons 1440*900, c'est pas nickel, mais décent...), tu verras que ce n'est pas gérable, particulièrement si tu passes par du WI-FI (ou il faut prendre en compte les nombreuses pertes réseau) sans même parler du fait que le serveur devra être très costaud.
Multiplies ensuite par le nombre de joueurs dans ton LAN...
Les logiciels comme VNC utilisent des protocoles (un "langage privé" qui permets la communication entre plusieurs logiciels) spécialisés dans le déport d'affichage.
La plupart des formats et protocoles qui traitent avec l'audio-visuel tendent à perdre des données, afin de faciliter les calculs. Les autres, ceux qui ne perdent pas de données, sont nettement plus gourmands en terme de CPU et de RAM, au minimum (je ne sais pas à 100% si ceux-ci sont d'efficacité identique à ceux impliquant une perte de données, en terme de bande-passante (aka: taille des données) mais à CPU/RAM identique, j'en serai extrêmement surpris).
HTTP est un protocole spécialisé, à l'origine, dans la transmission de fichiers en conservant (et en transmettant) des méta-données à leur sujet (par exemple, si c'est une image, une musique, un texte, un programme...).
Étant spécialisé dans le transfert de fichiers, il y à plusieurs limites. L'une d'entre elle est l'absence d'authentification et de chiffrement. Pour l'authentification, les sites web utilisent un contournement: les cookies. C'est du bricolage, et il y à régulièrement des problèmes de sécurité avec ça.
Pour le chiffrement, ça à été résolu avec le HTTPS. Je ne connais pas assez le fonctionnement des techniques de chiffrement pour essayer d'expliquer ça à un néophyte, mais le chiffrement implique également du temps de calcul pour que les données ne soient pas transmises en clair.
De plus, la compression est généralement plus performante quand les données se répètent suivant le même modèle régulièrement. Ce n'est plus trop le cas dans les jeux modernes, toujours plus réalistes, sans parler des effets de lumière et d'ombres.
La plupart des algorithmes de compression audio-visuels "perdent" des données. Les autres sont gourmands en terme de calcul.
À noter que quand je parle de temps de calcul, c'est du temps qui est dépensé des deux côté du réseau.
Au final, ce serait faisable, mais pas avec des jeux rapides. Un jeu en tour par tour? Oui, sans problème. Un jeu de stratégie, pourquoi pas, avec des graphismes au minimum probablement, par contre un FPS c'est mort.