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.