[xml][conception] accès optimisé à des ressources

bonjour,
je voudrai implémenter une application qui facilite la récupération d'images et de sons et qui sera expoitable plus tard pour la programmation d'un jeu par exemple.
je crois qu'il est hors de question d'utiliser une base de donnés dans ce cas.
voici mon idée: j'ai un fichier .zip par exemple qui contient l'ensemble de mes images (bien classées et répertoriées bien sûr).
mon appli prend ce fichier en entrée comme paramètre et fabrique un fichier xml qui décrit le contenu de ce zip (images, taille, référence, emplacement...).
ensuite l'appli qui veux acceder à ces images n'a qu'à taper dans le fichier xml pour récupérer ce qu'elle cherche...
je ne sait pas si cette solution est bonne ou non surtout de point de vu de performance plus tard.
j'attends vos commentaires
merci

C'est bien sûr une bonne idée (les fichiers .pak sont largement utilisés dans les Quake, Half-Life ou autres Warcraft), par contre puisque tu parles de performances, je pense qu'il est préférable de stocker les fichiers tels quels (non compressés) dans le pack, sauf si tu souhaites vraiment économiser de l'espace disque.

Citation:

---

Envoyé par Loulou24

C'est bien sûr une bonne idée (les fichiers .pak sont largement utilisés dans les Quake, Half-Life ou autres Warcraft), par contre puisque tu parles de performances, je pense qu'il est préférable de stocker les fichiers tels quels (non compressés) dans le pack, sauf si tu souhaites vraiment économiser de l'espace disque.

---

merci pour ta réponse,
mon premier souci c'est la performance(en temps et en memoire et quand je dis performance je ne parle pas de la performance de l'appli qui va générer le xml mais plutôt la performance en accés aux images plus tard grace à ce fichier xml) sinon c'est quoi les .pak?

Les .pak ce sont des fichiers fourre-tout utilisés par les jeux que je t'ai cité pour stocker leurs ressources (images, sons, modèles, ...).

Salut,

un .pak en gros c'est ce que tu proposais. Il s'agit d'un (gros) fichier contenant bout à bout tous les fichiers dont tu as besoin. Ce fichier est indexé (par du xml par exemple) et tu tape directement dedans au bon offset... Donc pour reprendreton idée, c'est tout pareil la compression en moins. Ceci permet d'avoir de meilleur accès car pas de décompression à faire.

Bonne continuation,
Tarrke

et ce .pak c'est une espece de repertoire ou on peut tout mettre? 8O 8O
sinon est ce que vous avez des liens qui éxpliquent comment ce truc marche? car j'ai fait une recherche sous google mais je n'ai pas trouvé un truc intéressant...

:!: donc si j'ai bien compris mon appli devra plutôt construire ce fichier .pak à partir du repertoire qui contient les différentes ressources c'est ça :?:

Il s'agit juste d'un format (plusieurs en fait) de fichier créé par les concepteurs de ces jeux. Il existe des explorateurs pour de tels fichiers, c'est-à-dire que oui tu peux les gérer de la même façon qu'un répertoire.

Par contre il n'y a rien de magique, ce "truc" marche parce que quelqu'un l'a programmé (d'ailleurs ce n'est pas très difficile), c'est comme pour tout. Après, peut-être que tu pourras trouver des sources pour ce genre de système sur le net, mais le coder toi-même peut être un bon exercice.

merci loulou pour ton aide je vais faire une recherche plus approfondie pour comprendre comment ça marche et l'adapter à mes besoins.

je viens de télécharger un exemple de pack et il parait que c'est très simple (je suis en train de mater le code).
c'est encourageant et ça fera un bon exercice comme l'a dit Loulou.
en tout cas merci beaucoup :merci:

Les fichiers pk3 de Quake3 sont de simples zip. Les fichiers sont décompressés à la demande et un système de cache optimise leur utilisation suivante.

Je me demande, quel est l'interêt des .pak comparé a une arborescance "normale" de fichier par repertoire sur le DD ?
( visiblement ce n'est pa la protection des fichiers si il existe des methodes simple pour parcourir ces .pak ... )

les méthodes pour se déplacer d'un certain nombre d'octect dans un fichier et pour lire les informations dans ce fichier doivent être plus rapide que le parcours de l'arborescence