Système de ressources à la Qt : viable ou pas ?

[Gabriel]

Bonjour,

Je cherche à créer un système de ressources à la Qt (pour avoir les ressources dans l'exécutable) avec une fonction qui renvoie les informations sur les images lorsque celles-ci sont demandées (selon le nom de leur fichier sans le répertoire avant). J'ai déjà réussi à générer le C++ pour le tableau d'Uint8 de l'image (les composantes des couleurs). Je choisis les fichiers, je choisis un fichier source à créer, et je lance la compilation. Je n'ai pas terminé, les fichiers source générés ne sont pas encore utilisables.

Mais avant d'aller plus loin, j'aimerais quand même savoir si ce que je cherche à faire est viable et portable (en dehors du fait que j'utilise bien le type portable sf::Uint8).

Voici un exemple de code généré :

#include "RessourceManager.h"

void RessourceImage::registeredImages(sf::String filename, RessourceImage * img)
{
if(filename.toUtf8() == sf::string("block1.png").toUtf8()){
unsigned int pX = 37;
unsigned int pY = 37;
const sf::Uint8 pixels[] = { composantes des couleurs };
//stockage des informations dans img
else {
unsigned int pX = 0;
unsigned int pY = 0;
const sf::Uint8 pixels[] = { 0 };
// stockage des informations dans img
}
}
 

pX = nombre de pixels en longueur
pY = nombre de pixels en hauteur
const sf::Uint8 pixels[] = tableau des composantes des couleurs

Comme je l'ai dit je n'ai pas terminé, je ne cherche pas des critiques sur le code généré, mais bien de savoir si l'idée est bonne, conventionnelle, et si elle peut me poser des problèmes. J'ai mis le sujet ici car le système ne concerne pas qu'un module, mais tous les modules qui peuvent utiliser des ressources.

Merci d'avance.

[Laurent]

Je cherche à créer un système de ressources à la Qt

Je crois que ça répond à ta question non ? Sans trop me mouiller, je pense pouvoir dire que le sytème de ressources de Qt est viable et conventionnel

[Gabriel]

Merci pour ta réponse Laurent. Je viens de terminer et je me rends compte d'un gros problème avec les fichiers générés : le temps de compilation. En effet pour des petites images 30x30 la compilation du fichier généré prend 5 secondes max alors qu'avec un fichier supérieur avec plus de 1000 pixels ça commence à prendre des minutes de compilation. Je vais essayer de voir si je peux compresser les données avec zlib (pour décompresser à l'exécution), le problème c'est que je dois faire un choix : soit je compile lentement et le programme est rapide parce qu'il ne fait pas beaucoup de traitements, soit je compile vite et le programme est lent parce qu'il fait beaucoup de traitements. C'est valable pour toutes les alternatives je suppose.

[Laurent]

Vraiment ? J'ai habituellement plusieurs Mo de ressources dans mes programmes Qt et ça ne met que quelques secondes à recompiler le fichier de ressources. Tu t'y prends peut-être mal dans ton propre système.

[Gabriel]

C'est peut-être le fait que je "stocke" la ressource dans le return d'une fonction qui augmente le temps de compilation, alors que Qt stocke les ressources dans des variables globales statiques au fichier de ressources. Je vais essayer de voir si je peux faire pareil, ce qui ne m'enchante pas. :/ Au début de pensais le faire à "ma façon" mais mon système a ce problème qui est le temps de compilation, problème que le système de ressources de Qt n'a pas.

Au fait, j'ai quand même réussi à compresser le tableau de pixels avec zlib, j'ai réussi à mettre 5476 Uint8... dans un tableau d'une vingtaine d'Uint8. La décompression fonctionne bien. Maintenant que je sais comment faire, il faut bien le faire, en gros comme Qt. :p Parce que pour l'instant, la compilateur compile en 2 secondes un fichier ressources Qt, alors que mes fichiers ressources prennent 5 minutes à être compilés...

Il faut savoir que je n'utilise absolument aucun pointeur, j'utilise des std::vector pour éviter les fuites de mémoire, ou plus généralement tous les problèmes de mémoire. C'est vachement plus sécurisé, et je me casse pas la tête.

EDIT : J'ai trouvé ce qui ralentit la compilation : lorsque je crée le tableau à l'intérieur de la fonction, la compilation est lente. Lorsque je crée la variable sous forme de "globale statique" au fichier, la compilation est instantanée. Par contre ce qui m'énerve, c'est que le tableau statique est alloué au début du programme, alors que si je le crée dans la fonction, la compilation est lente mais le tableau est alloué lorsque j'en ai besoin (c'est à dire lorsque la fonction de chargement le demande). J'aimerais avoir les 2 avantages (compilation instantanée + tableau alloué si nécessaire) mais je n'ai vraiment pas d'idée. Quelqu'un aurait une solution s'il vous plaît ? (je parle du tableau qui contient les données sur les fichiers sous forme compressée, par exemple les pixels pour les images, les samples pour les sons)

EDIT : Finalement je laisse mon test de côté. Je me pencherai sur cette mécanique qui est de mettre ses ressources sous une autre forme que celle d'origine plus tard, mais pour l'instant j'en n'ai vraiment pas besoin, j'ai bien réfléchi. Merci tout de même pour l'aide apportée dans ce topic.

[Gabriel]

UP.

Je reviens sur ce topic pour parler à peu près de la même chose mais cette fois, j'ai terminé un système de fichiers data qui fonctionne. [EDIT : Le fichier data permet de stocker des fichiers sous forme compressée et de restituer leur contenu dans un programme.] Le fichier data (utilisant zlib) a un index au début qui contient la liste des fichiers et leur position par rapport au début du premier fichier (se trouvant donc à la position 0). Les fichiers sont compressés à la suite, et j'ai une fonction pour renvoyer le contenu du fichier voulu (en gros le fichier original) sous forme de std::string. J'utilise un std::string parce que c'est plus facile de travailler avec une chaîne de caractères qui peux varier en taille à mon goût. J'aurais quelques questions pour pousser un peu plus ce système :

- Devrais-je découper les fichiers en plusieurs morceaux compressés, du genre plusieurs parties de 1 ko ? Quelle taille me conseilleriez-vous pour les parties ? (je tiens à utiliser sf::InputStream pour lire les musiques, c'est l'idéal dans mon cas) ;

- En parlant de InputStream, cela risque-t-il de me gêner ? Je veux dire, est ce que la fonction

bool sf::Music::openFromStream  (       InputStream &   stream  )      

lance un thread ? Si c'est le cas, alors je ne vais pas pouvoir utiliser mon fichier pour autre chose en même temps, donc lire un son à partir du même fichier. Si les std::ifstream sont optis pour le multithreading alors je suis tranquille.

- Sachant que mon système de fichiers data fonctionne (j'ai même créé un exécutable à la 7z pour décompresser les fichiers data, ou créer des fichiers data à partir des fichiers choisis), et qu'il est portable (il écrit automatiquement en little endian, à la lecture convertit en big endian si nécessaire, et n'écrit que par octets), pourrait-il intéresser des gens ? Je veux dire, compresser plusieurs ressources dans un fichier, et pouvoir restituer leur contenu à l'intérieur d'un jeu si par exemple on veut une image, est-ce que cela intéresserait d'autres développeurs ?

- Est-ce que j'ai d'autres questions à me poser sur ce système de fichiers data ?

Merci d'avance et merci d'avoir pris le temps de lire. :p

[Laurent]

- Devrais-je découper les fichiers en plusieurs morceaux compressés, du genre plusieurs parties de 1 ko ? Quelle taille me conseilleriez-vous pour les parties ? (je tiens à utiliser sf::InputStream pour lire les musiques, c'est l'idéal dans mon cas) ;

Pourquoi faire ?

- En parlant de InputStream, cela risque-t-il de me gêner ?

La lecture se fait dans un thread, oui. std::istream n'est pas thread-safe, donc dans tous les cas il faudra que tu rendes certaines parties de ton système thread-safe.

- Sachant que mon système de fichiers data fonctionne (j'ai même créé un exécutable à la 7z pour décompresser les fichiers data, ou créer des fichiers data à partir des fichiers choisis), et qu'il est portable (il écrit automatiquement en little endian, à la lecture convertit en big endian si nécessaire, et n'écrit que par octets), pourrait-il intéresser des gens ? Je veux dire, compresser plusieurs ressources dans un fichier, et pouvoir restituer leur contenu à l'intérieur d'un jeu si par exemple on veut une image, est-ce que cela intéresserait d'autres développeurs ?

Sûrement. Mais il existe très probablement déjà pas mal de gens qui ont fait des choses similaires. Après, dans tous les cas ça ne peut pas faire de mal de partager ton travail.

- Est-ce que j'ai d'autres questions à me poser sur ce système de fichiers data ?

Ca c'est vraiment une drôle de question...

[Gabriel]

Pourquoi faire ?

Pour ne pas stocker toute la musique en mémoire d'un coup. Je ne décompresse que les parties de la musique demandées par sf::Music au InputSteam.

La lecture se fait dans un thread, oui. std::istream n'est pas thread-safe, donc dans tous les cas il faudra que tu rendes certaines parties de ton système thread-safe.

Du coup il faudra que j'utilise plusieurs std::ifstream (si on peut lire un fichier à partir de plusieurs ifstream en même temps). Cela me permettra aussi de faire un dégradé de musiques, du genre je baisse progressivement le son d'une musique pendant qu'une autre commence à se jouer. C'est pour ça que je veux pouvoir lire plusieurs musiques "en même temps".

Sûrement. Mais il existe très probablement déjà pas mal de gens qui ont fait des choses similaires. Après, dans tous les cas ça ne peut pas faire de mal de partager ton travail.

Oui c'est ce que je veux faire, il faut juste que j'apprenne à utiliser un dépôt git pour partager mon code source. Sinon tout est stable, du moins j'ai pas rencontré de bug, de plus c'est assez évident à utiliser, et portable.

Ca c'est vraiment une drôle de question...

Quels problèmes peut me poser un tel système de fichier ?

[Laurent]

Pour ne pas stocker toute la musique en mémoire d'un coup. Je ne décompresse que les parties de la musique demandées par sf::Music au InputSteam.

Ah. Dans ce cas oui, j'imagine que ça peut être une solution.

Quels problèmes peut me poser un tel système de fichier ?

Je ne sais pas, mais je pense que tu le découvriras bien assez tôt.