Discussion :

[Invité]

Salut,

je me penche sur un problème depuis quelque temps déjà maintenant.

Je suis entrain de me demander quelle est la façon la plus rapide de transférer des textures en réseau.

Sinon j'ai quelque idées déjà :

Au 1er lancement du client, transférer les textures du serveur vers le client, et les écrire dans un fichier. (côté client)

Au second lancement vérifier si toutes les textures sont bien les même côté serveur et côté client, sinon, transférer les textures qui manque. (pour les mises à jour par exemple)

J'écris les textures (chargées à partir d'image .png) dans un flux, chaque texture possède une taille ainsi que un tableau de pixels. (un tableau d'unsigned char)
Je sérialise les données comme ceci dans le flux en format texte : (il y a deux types de données possibles : des nombres ou bien des caractères)
Lors de l'écriture je sépare tout les caractères et les nombres par un \n et si c'est une liste de nombres ou bien de caractère alors j'écris la taille de la liste.
Lors de la lecture, si c'est un nombre, alors, je lis jusqu'à rencontré le \n avec l'opérateur>> de ifstream, si c'est un char ou un unsigned char, je lis juste un caractère avec get, si c'est un liste je lis le nombre de nombres ou bien de caractères et je lis tout les éléments un par un avec une boucle for.

Ceci me donne donc un flux avec beaucoup de ligne, mais c'est le seul moyen pour bien tout séparer et bien lire les chaînes de caractère contenant un \n, un \r et autres caractères spéciaux. (sans devoir les échapper)

Bref ceci est bien, mais, je crains que ça ne sois pas assez rapide, les images peuvent être lourde, alors, je recherche actuellement des algorithme de compression qui me permettraient de compresser et de décompresser des fichiers textes. (J'ai trouvé un algorithme mais il ne marche seulement qur pour les caractères codé sur 16 bits mais mon algorithme ne prend pas encore en charge les wstring.
De plus je ne peux pas utiliser des wchat_t vu que mes char sont les composantes rgba des pixels de ma texture en fait.

Par contre je n'ai pas trouvé grand chose concernant les caractères codé sur 8 bits, il y a des librairies opensource comme par exemple zlib mais, la plupart de ces librairies et code source que j'ai trouvé sont écris en C, en plus elles utilisent leur propre fonction pour écrire et lire dans des fichiers mais moi je veux juste une fonction de compression et de décompression, rien de plus, ni de moins.

Merci d'avance. (Je crains de devoir écrire mon propre algorithme de compression, décompression. :/)

[ternel]

La partie transfert, c'est un téléchargement.
Si tu ne veux pas t'embêter, il suffit d'utiliser curl pour une requete ftp.

Il faut savoir que la compression/décompression sans perte est un vrai défi, et qu'écrire ton algorithme serait une erreur.

Par contre, utiliser un algo efficace et bien paramétré est possible. Regarde du coté de 7Zip pour un algo généraliste.
Pour un algo dédié aux images, je crains qu'il ne faille rechercher en fonction du format.

Rien ne t'empeche de procéder en trois étapes.
créer le fichier de texture en .bidule sur le serveur, et le compresser. (une fois par mise a jour)
laisser les clients récupérer l'image compressée.
le client décompressera l'image lors de la récupération, et vivra avec.

Il ne faut surtout pas compresser l'image à chaque téléchargement.


Par contre, tu m'inquiètes un peu, avec ton projet.
Tu n'es pas en train de tenter le diable en développant un MMO-je-ne-sais-quoi?

[Invité]

Non, non, juste une bibliothèque proposant diverses fonctionnalités. (aussi bien pour développez des mmos ou n'importe quoi d'autre)

Je sais très bien que à moi tout seul je ne pourrai pas développer de mmorpg, le mieux que je pourrais faire c'est un petit RPG. (Ou bien un fps tout simple)

Ok je vais regarder du côté de 7Zip, je cherche plutôt un algorithme généraliste, je ne transfert pas que des images mais aussi toutes sortes d'informations sur les entités mais toutes les informations finissent toutes par être converties en nombres ou bien en caractères avant d'être compressée et transférée (je peux compresser et sauvegarder dans un fichier pour ne pas avoir à compresser à chaque fois) et à la réception je les décompresses et ensuite je reconverti tout ça en objets.

En gros il ne me reste plus que ça à gérer pour mon projet (la compression et la décompression) ainsi que quelques algorithme utilitaire pour la 3D.
Mais même si j'ai bientôt fini ma bibliothèque je ne pense pas pouvoir faire un mmorpg tout seul, trop de boulot au niveau des graphismes, du codage de gameplay, etc...

Il me resterait à faire toutes les graphismes : interfaces graphiques, les ennemis, les héros, ainsi que codé tout le gameplay (joueur vs environnement, les guildes, le pvp, le système de compétence, l'inventaire, etc, etc..., trop de boulot pour moi tout seul.)

[ternel]

Il faut voir que théoriquement, la charge du transfert de l'image n'est pas au programme graphique.

Je veux dire par là que la compression et le réseau n'existe même pas pour le code qui charge l'image en mémoire.
C'est une autre partie du code qui va créer le fichier image quand besoin est, en chargeant une archive (compressée ou non).

D'un point de vue plus général, je te conseille de créer un jeu le plus vite possible pour mettre ton moteur à l'épreuve.
Ton moteur ne sera valable que si son utilisation ne rend pas le jeu complètement tordu à coder.

[Invité]

Oui, je ferais ça dès que j'aurai fini de nettoyé un peu le code de la bibliothèque. (pour le moment je vais me limiter à la 3D isométrique)

Le code qui charge l'image en mémoire est un tout autre code, je parle ici du transfert des données de l'images, pas du chargement de l'image.
Donc on est bien dans ce cas là. (le chargement et la compression de l'image se font côté serveur avec la classe sf::Image et les archives après je n'y touche plus sauf pour transférer l'image compressée au client afin de passer les informations nécessaire à opengl pour charger la texture.)

Le client ne charge pas d'image donc et il n'y a aucun transfert d'images, juste les données nécessaires pour créer la texture sont transférée.
Je n'ai d'ailleurs pas envie de toucher à la classe sf::Image, alors j'ai fais ceci : (j'ai juste récupérer le pointeurs sur le tableau de pixels et je l'écris dans l'archive)

Code cpp :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
void Texture::onSave(std::vector<sf::Uint8>& vPixels) {
    glCheck(glBindTexture(GL_TEXTURE_2D, m_texture));
    const std::size_t size = 4 * m_size.x * m_size.y;
    sf::Uint8* pixels = new sf::Uint8[size];
    glCheck(glGetTexImage(GL_TEXTURE_2D, 0, GL_RGBA, GL_UNSIGNED_BYTE, pixels));
    vPixels.assign(pixels, pixels + size);
}
void Texture::onLoad(std::vector<sf::Uint8>& vPixels) {
    sf::Uint8* pixels = &vPixels[0];
    create(m_size.x, m_size.y);
    glCheck(glBindTexture(GL_TEXTURE_2D, m_texture));
    glCheck(glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, m_size.x, m_size.y, GL_RGBA, GL_UNSIGNED_BYTE, pixels));
    glCheck(glFlush());
}

Ce que je cherche c'est juste un algorithme qui pourrait compresser les données des pixels. (Par exemple si plusieurs pixels on la même couleur ou bien que un texte à plusieurs fois la même lettre)

PS : glGetTexImage est plus lent mais pas le choix c'est un transfert entre gpu et gpu de deux machines différentes, pas un transfert entre cpu et gpu sur la même machine.
Tout ce que j'espère c'est que le temps de transfert ne soit pas trop long.

[Médinoc]

Franchement, je pense que pour transférer des textures, tu aurais plus vite fait de les transférer sous leur format de stockage d'origine (tu as parlé de PNG) plutôt que les décompresser et tenter d'appliquer une compression "maison" lors du transfert... Par contre, ça nécessite que le destinataire ait accès au code de décompression que l'émetteur utilisait jusqu'alors.

[Bousk]

Je plussoye Medinoc, les formats d'image sont déjà de la compression. (Pour t'en assurer, essaye de réenregistrer ton image en BMP..)
PNG et TGA m'ont toujours satisfait sur le ratio poids/qualité, sans perte notable.
TGA est en plus très aisément intégrable, le format est fort simple. PNG nécessitera d'utiliser libpng, qui a une dépendance à zlib je crois.

[Médinoc]

PNG utilisant Deflate, la dépendance à zlib est probable.

[Invité]

Erf, je n'ai pas accès à l'algorithme de décompression. :/
Je pense que sf::Image décompresse les images en utilisant la bibliothèque libjpeg mais je n'ai pas accès à ce code.
Je vais essayer de modifier sf::image pour avoir l'image compressée mais je ne sais pas si c'est possible.

[Médinoc]

Je pense que tu te compliques la vie pour rien. Le serveur ne devrait même pas avoir besoin de sf::image, si tout ce qu'il fait c'est les envoyer au client.
Le serveur devrait charger directement les fichiers images pour les transmettre tels quels au client, et c'est le client qui devrait utiliser sf::image pour les ouvrir et les afficher.

[Bousk]

Encore une fois tu veux réinventer une bombe nucléaire pour écraser un moucheron.

Comme je l'ai dit plus haut, semblerait que tu ne lises pas tout.., les fichiers d'image sont déjà compressés.
Fun fact: tu archives un fichier .png, en 7z, et... le résultat est similaire, souvent même un peu plus gros, que l'original.

Après avoir perdu ~5s à faire ce test, tu redescends sur terre : la compression d'image, c'est aussi vieux qu'internet, surtout aux débuts quand on avait 28.8k de débit, mais toujours ajd pour fournir des webapp et consors toujours plus sophistiqués.
Donc au lieu d'espérer réinventer une roue carré, ce qui est de toutes manières clairement voué à l'échec, et tu vas te retrouver avec une boule de pate à modeler malformée, tu les utilises.

Et pour envoyer une image.. je sais pas si j'ôserai.. allez si, je mets du code..

Code :

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

1
2
3
4
5
6
7
ifstream file("file.png", ios::binary);
file.seekg(0, ios::end);
int size = file.tellg();
file.seekg(0, ios::beg);
char* buffer = new char[size];
file.read(buffer, size);
send(pSocket, buffer, size, 0);

sf::Image ne fait rien de magique, et tout son code est disponible sur le repo de SFML.
Comme dit plus haut, j'ai l'impression de me répéter mais ça va peut-être finir par rentrer, les images sont des fichiers compressés.
Sauf que bien sûr, OpenGL et DirectX eux ils veulent un buffer de pixels.
Tout ce que fait sf::Image, ou n'importe quelle lib aussi haut niveau d'image, c'est lire le fichier et recréer un buffer de pixels.

[ternel]

Mon cher Lolilolight, tu n'as visiblement pas encore saisis l'intérêt de la conception modulaire.

Certaines parties du code doivent être indépendante.
Le serveur n'affiche rien, il n'a pas de code graphique. Si ton serveur requiert SFML, c'est une erreur de conception.

Ton serveur ne sérialise que les données de gameplay, et transmet uniquement des fichiers (suites d'octets) au client.
Ton client, lui, ne fait que demander les fichiers qu'il sait avoir besoin au serveur, et les utilise comme il le souhaite.

Exactement comme un navigateur et un serveur web. Le serveur web propose des fichiers, éventuellement pré-traités pour les langages serveurs comme PHP ou ASP.
C'est le navigateur qui différencie une page web, d'un script ou d'une image.

Rappelle toi la règle de base:
Une seule chose à la fois.

Un bout de code transforme une donnée en fichier, un autre choisit où le garder sur le serveur, un troisième l'envoie, un quatrième écoute les demandes de fichiers.

[Invité]

Ok donc lorsque sf::image lis une image au format .png, alors celle-ci reste bien compressée.
Donc normalement je peux envoyé l'image tel quel au client lors du téléchargement alors vu que celle-ci est déjà compressée.

Merci.

(Je pense que finalement, je n'aurai pas besoin d'algorithme de compression)

Bref je me disais que si une image sérialisée (donc transformée en format texte) pourrait être compressée et décompressée serait pas mal.
Donc au final c'est du texte que je veux compresser, pas une image, l'image est déjà compressée.

Ne pas devoir recharger l'image côté client avec sf::Image et avoir les images sérialisée en format texte côté client me semble être plus simple que de transférer ça via un système genre curl ou bien via un ftp.
Le client sera moins lourd à télécharger, mais peut être plus long à lancer la 1ère fois, bref...

[ternel]

Mais comment vas-tu faire ton transfert de manière portable, sans pourrir tes performances?

Et pourquoi voudrais-tu que ton serveur ouvre le fichier, le charge dans un sf::image, sérialise dans un buffer énorme, pour finalement l'envoyer à un client qui va le dé-sérialiser dans une sf::image?

Alors que tu peux te contenter d'envoyer directement le fichier original, et laisser le client le charger dans une sf::image...

Et il en sera de même avec toutes tes ressources (modèles 3D, son, fichier de carte, etc).

Le processus de sérialisation n'appartient normalement qu'au client qui fait une sauvegarde des données utilisateurs.
Et au serveur pour les données de jeu, si tu limiter la triche.

[Invité]

Ha, ok, donc selon toi je ne devrais pas charger les images, shaders, modèles, etc... et les sérialiser avec le serveur pour les envoyer au client pour les désérialiser mais juste envoyer les images, shaders, modèles, .etc... au client lors du lancement d'un patch de mise à jour et ensuite charger les images côté client avec sf::Image, c'est bien ça ?

[Médinoc]

Ok donc lorsque sf::image lis une image au format .png, alors celle-ci reste bien compressée.

Non! Non! Non! Où crois-tu avoir lu ça?

Le serveur n'a pas à utiliser sf::image. En fait, il n'a même pas besoin de savoir que le fichier qu'il envoie au client est une image. Il charge le fichier avec ifstream etc. (et non pas avec sf::image) et l'envoie tel quel au client, c'est tout.

[ternel]

Et encore, avec curl ou ftp ou autre, c'est normalement encore plus direct.
Tu n'écris que connection.send("nom du fichier").

[Bousk]

Ok donc lorsque sf::image lis une image au format .png, alors celle-ci reste bien compressée.
Donc normalement je peux envoyé l'image tel quel au client lors du téléchargement alors vu que celle-ci est déjà compressée.
[...]
Ne pas devoir recharger l'image côté client avec sf::Image et avoir les images sérialisée en format texte côté client me semble être plus simple que de transférer ça via un système genre curl ou bien via un ftp.
Le client sera moins lourd à télécharger, mais peut être plus long à lancer la 1ère fois, bref...

Ha, ok, donc selon toi je ne devrais pas charger les images, shaders, modèles, etc... et les sérialiser avec le serveur pour les envoyer au client pour les désérialiser mais juste envoyer les images, shaders, modèles, .etc... au client lors du lancement d'un patch de mise à jour et ensuite charger les images côté client avec sf::Image, c'est bien ça ?

Lis-tu seulement les réponses que l'on te fait ou bien tu te contentes de balancer des mots au hasard jusqu'à ce qu'on te dise "oui tu as raison" ?
Chacune de nos réponses ci-dessus semble suffisamment claire..

Alors soit, fais comme tu l'entends, charge les images en (v)ram sur le serveur, et envois des BMP en raw pixels à tes clients.