Author Topic: Données dans exe  (Read 18347 times)

0 Members and 1 Guest are viewing this topic.

Offline xoofx

  • Base
    • Pouet.net
    • View Profile
    • xoofx
  • Ancienneté: 1989
  • Groupe: FRequency
  • Rôle: code (+musique), web
  • Ville: Grenoble
Re : Données dans exe
« Reply #15 on: 18 May 2011 à 22:07:41 »
Comme cela a été dit, les bin2h, les links avec nasm, les archives externes sont des bons candidats... Je ne partirais pas trop en revanche sur une solution resource windows.

Mais ce qui est surtout important dans cette histoire de chargement des données, c'est de développer une API qui fasse abstraction de la source des données (filesystem, archive, socket...etc). Normalement, tout chargement de data doit ensuite passer par une telle API.

Côté utilisation, cela doit donner quelque chose du style:
Code: [Select]

// Init du AssetManager au début de l'appli
AssetManager assetManager = new AssetManagerFromXXX();

...

// Chargement d'une resource
assetManager.Load<Texture>("/images/mytexture.jpg");

AssetManager propose une interface de chargement pour laquelle on a plusieurs classes concrètes (AssetManagerFromZip, AssetManagerFromFS, ou même les deux combinés lorsque par exemple, on veut charger d'abord à partir du Zip, sinon à partir du FS).

Derrière, à chaque type d'asset, il y a un loader à partir d'un stream abstrait, que le loader soit une classe extérieure ou intégré à la classe de l'asset (TextureLoader ou Texture). L'AssetManager est sensé créer des stream en fonction du type de la source de données.

Bon, voila le principe en gros, après, il y a une variété d'implem! ;)

Offline Patapom

  • Base
    • View Profile
    • www.patapom.com
  • Ancienneté: 1988
  • Groupe: Bomb!
  • Rôle: Coder
  • Ville: Lyon
Re : Données dans exe
« Reply #16 on: 18 May 2011 à 23:02:44 »
Mmmh... Moi ce que j'ai fait c'est simplement tout baser mes chargements sur le type System.IO.Stream, du coup pas besoin de faire d'asset manager.
Si tu charges du disque alors les streams sont des FileStreams, si tu charges d'une archive alors les streams sont des MemoryStreams...
.  Pom  .

Offline xoofx

  • Base
    • Pouet.net
    • View Profile
    • xoofx
  • Ancienneté: 1989
  • Groupe: FRequency
  • Rôle: code (+musique), web
  • Ville: Grenoble
Re : Données dans exe
« Reply #17 on: 18 May 2011 à 23:16:33 »
Mmmh... Moi ce que j'ai fait c'est simplement tout baser mes chargements sur le type System.IO.Stream, du coup pas besoin de faire d'asset manager.
Si tu charges du disque alors les streams sont des FileStreams, si tu charges d'une archive alors les streams sont des MemoryStreams...
Oui oui, je passe aussi par un Stream abstrait (l'AssetManager utilise la classe Stream), mais je conseille d'avoir un endroit qui centralise les chargements, et qui encapsule le type de stockage. C'est l'asset manager, suivant sa config, qui fournit un Stream qui charge à partir d'un fichier, ou d'un zip...etc. Il ne faut pas que dans le code, il y ai une référence explicite au fait que le chargement se fait à partir d'un fichier du FS ou autre... enfin, tout ça, c'est à la condition que tu veux pouvoir rendre transparent le chargement à partir de n'importe quelle source sans changer ton code...

Offline Patapom

  • Base
    • View Profile
    • www.patapom.com
  • Ancienneté: 1988
  • Groupe: Bomb!
  • Rôle: Coder
  • Ville: Lyon
Re : Données dans exe
« Reply #18 on: 19 May 2011 à 00:06:20 »
Bah oui justement : si tu passes pas un stream t'es dépendant de rien. Après derrière je construis in BinaryReader à partir de ce stream.
Le stream peut venir de n'importe quelle source, disque ou mémoire comme je disais.

L'asset manager c'est un + ouais mais c'est pas nécessaire. C'est même plutôt encombrant si tu veux supporter tous les types d'assets possibles...
Genre "Ah merde, j'ai oublié de faire une méthode pour charger une TPage qui prend en paramètre un array de textures et les tailles des sprites dans la TPage"... Cas hyper particulier, mais si t'es obligé de te le refarcir pour un manager à partir du disque, ou un manager à partir de la mémoire, ou manager qui fait du streaming ou je ne sais quoi encore... Ou alors j'ai pas compris l'intérêt de ton assets manager ? C'est toujours le même quelle que soit la source c'est ça ? Me suis gouré ?
.  Pom  .

Offline xoofx

  • Base
    • Pouet.net
    • View Profile
    • xoofx
  • Ancienneté: 1989
  • Groupe: FRequency
  • Rôle: code (+musique), web
  • Ville: Grenoble
Re : Données dans exe
« Reply #19 on: 19 May 2011 à 10:40:00 »
Bah oui justement : si tu passes pas un stream t'es dépendant de rien. Après derrière je construis in BinaryReader à partir de ce stream.
Le stream peut venir de n'importe quelle source, disque ou mémoire comme je disais.
Le Stream est une étape, mais il te faut bien avoir une instanciation du stream. Si dans ton code, tu instancies directement des FileStream à chaque fois que tu veux charger un asset, et bien t'es parti pour devoir tout changer si tu veux charger à partir d'un zip ou autre.

Ce qu'il faut éviter, c'est ce genre de code
Code: [Select]
var mytexture = new Texture(new FileStream("./images/mytexture.jpg"));

mais le remplacer par un intermédiaire "StreamProvider" (qui derrière, peut charger à partir d'un zip, fs, socket...etc.):
Code: [Select]
var mytexture = new Texture(streamProvider.Find("./images/mytexture.jpg"));

L'AssetManager dans ce cas n'est qu'un intermédiaire supplémentaire par rapport à un "StreamProvider":

Code: [Select]
var mytexture = AssetManager.Load<Texture>("./images/mytexture.jpg");

Comme tu dis, il n'est pas absolument nécessaire, mais il permet de centraliser l'instanciation des Assets (et la manière dont il sont instanciés), de pouvoir affecter par exemple le nom du fichier directement à la texture, de pouvoir garder une liste des assets chargés, de pouvoir faire un cache d'objet...etc.

Aprés, en général, la quasi totalité des assets chargés sont en général des assets simples ( texture, mesh, musique...etc.). Le cas que tu décris nécessiterais, quelque soit la méthode de charger plusieurs assets simples pour les combiner ensemble.

Bon, comme je l'ai dit, l'important dans cette histoire, c'est d'avoir un code qui peut s'abstraire de la source de données et que la source puisse être changée en une ligne de code ou de config pour tout le reste de la démo.

Offline maracuja

  • Base
    • View Profile
Re : Données dans exe
« Reply #20 on: 19 May 2011 à 11:35:23 »
Un decorator est une excellente solution pour charger des données.

En ce qui me concerne, j'évite au maximum d'utiliser les incbin pour charger des datas, car certes, c'est super pratique mais pas portable du tout. Entre les différents outils d'assemblages et architectures matérielles, c'est cauchemardesque  alors qu'un bon vieux bin2h n'a pas tous ces inconvénients.

Bon après c'est de la cuisine suivant les sensibilités de chacuns :=)

Offline xoofx

  • Base
    • Pouet.net
    • View Profile
    • xoofx
  • Ancienneté: 1989
  • Groupe: FRequency
  • Rôle: code (+musique), web
  • Ville: Grenoble
Re : Données dans exe
« Reply #21 on: 19 May 2011 à 12:47:07 »
J'oubliais qu'il y a aussi une technique que j'utilise souvent pour packer des données avec un exe. C'est assez simple et portable: Je constitue une archive de fichiers (souvent dans un format propriétaire très simple: nombre de fichiers + liste de [taille du nom du fichier + nom du fichier + taille dans l'archive + data du fichier ] ) que j'ajoute à la fin de l'exe (par une simple concaténation binaire). Je rajoute juste à la fin de l'exe, la taille de l'archive (ou l'offset dans le fichier exe où l'archive est stocké, ce qui correspond à la taille de l'exe sans l'archive colée aux fesses) et un magic-number dans un entier pour être sûr que l'archive est bien présente. Tout ça s'automatise avec des simples scripts python, ruby, C# ou autres...
Ensuite, dans l'exe, il se recharge lui même en mémoire et vérifie la présence du magic-number à la fin, si oui, il fait pointer vers l'archive en mémoire, sinon, il la charge autrement (par le procédé décrit précédemment, via une archive externe, des répertoires...etc.).

Offline maracuja

  • Base
    • View Profile
Re : Données dans exe
« Reply #22 on: 19 May 2011 à 13:26:20 »
tu fais comme x garreau grossomodo ? Par contre sur les OS recents (xp/vista/seven) cela fonctionne bien ce genre de chose ? Il n'y a pas de verification outre mesure quand il mappe le pe et les sections ?
« Last Edit: 19 May 2011 à 13:38:28 by maracuja »

Offline flure

  • Base
    • Pouet.net
    • View Profile
  • Ancienneté: 1998
  • Groupe: PoPsY TeAm
  • Rôle: Codeur Linux
  • Ville: Lyon
Re : Données dans exe
« Reply #23 on: 19 May 2011 à 13:51:07 »
Pas mal ta technique @lx, ça ressemble assez au système des ressources (ou à l'idée que je m'en fais).

Offline maracuja

  • Base
    • View Profile
Re : Données dans exe
« Reply #24 on: 19 May 2011 à 14:08:08 »
Flure: Oui mais alors quel est l’intérêt de ne pas passer par le système de resource(s) d'un fichier PE vu que c'est "gratuit" ?

Offline flure

  • Base
    • Pouet.net
    • View Profile
  • Ancienneté: 1998
  • Groupe: PoPsY TeAm
  • Rôle: Codeur Linux
  • Ville: Lyon
Re : Données dans exe
« Reply #25 on: 19 May 2011 à 14:22:01 »
Maracuja : l'intérêt ? Ca marche sur tous les systèmes, et pas que Windows :)

Offline xoofx

  • Base
    • Pouet.net
    • View Profile
    • xoofx
  • Ancienneté: 1989
  • Groupe: FRequency
  • Rôle: code (+musique), web
  • Ville: Grenoble
Re : Données dans exe
« Reply #26 on: 19 May 2011 à 14:41:21 »
tu fais comme x garreau grossomodo ? Par contre sur les OS recents (xp/vista/seven) cela fonctionne bien ce genre de chose ? Il n'y a pas de verification outre mesure quand il mappe le pe et les sections ?
xgarreau xgarreau... c ki ça?... ahhh ok ;D, J'avais pas vu le lien xgarreau! donc oui oui, c'est effectivement le même principe.

Sur Windows Vista/Seven, je n'ai jamais eu un seul problème avec cette méthode. Ca n'interfère pas avec le mapping des sections du PE en mémoire.

Flure: Oui mais alors quel est l’intérêt de ne pas passer par le système de resource(s) d'un fichier PE vu que c'est "gratuit" ?
Comme le souligne flure, c'est portable, ça permet même d'avoir un format plus compact que les ressources Windows classiques. Après, il y a un petit surcoût à développer le petit outil pour gérer l'outil de packing des ressources et le chargement de celle-ci, mais sinon, c'est plutôt raisonnable. In fine, le même système de chargement peut aussi être utilisé pour une archive externe, en utilisant exactement le même format de ficiher (signature à la fin du fichier...etc)

Offline maracuja

  • Base
    • View Profile
Re : Données dans exe
« Reply #27 on: 19 May 2011 à 15:44:27 »
xgarreau xgarreau... c ki ça?... ahhh ok ;D, J'avais pas vu le lien xgarreau! donc oui oui, c'est effectivement le même principe.

Sur Windows Vista/Seven, je n'ai jamais eu un seul problème avec cette méthode. Ca n'interfère pas avec le mapping des sections du PE en mémoire.
Comme le souligne flure, c'est portable, ça permet même d'avoir un format plus compact que les ressources Windows classiques. Après, il y a un petit surcoût à développer le petit outil pour gérer l'outil de packing des ressources et le chargement de celle-ci, mais sinon, c'est plutôt raisonnable. In fine, le même système de chargement peut aussi être utilisé pour une archive externe, en utilisant exactement le même format de ficiher (signature à la fin du fichier...etc)

Alors pris la main dans le sac de ne pas suivre regarder mes liens !!! ;)

Ok, comme tu le précises, ce n'est pas énorme de coder cela au regard du reste  et qui plus est cela apporte une souplesse. :)

Par contre, on peut faire mieux qu'une structure arborescente. La section resource  en est une. Que peux t'on utiliser comme structure de données pour améliorer le stockage d'info ?

nystep

  • Guest
Re : Données dans exe
« Reply #28 on: 19 May 2011 à 18:33:39 »
Perso j'aime bien tout stocker dans un gros fichier .dat (données binaires) à coté de l'executable (maintenant, oui, je sais qu'en 2006 j'ai fait une démo sans aucune archive...). Celà signifie que si l'on veut distribuer sur plusieurs plateformes et bien pas besoin de faire un fichier executable de 40 mb pour chaque plateforme, le code tiendra amplement dans chaque executable de 1mb pour chaque plateforme, et les données dans un bon gros fichier .dat de 39mb.

Celà permet aussi de cacher un peu les choses pour les regards un peu trop indiscrets :) Mais c'est selon votre niveau de parano pour ça. On peut ajouter de la compression et du cryptage pour se faire plaisir. Un fichier .dat permet aussi de gérer l'archivage, ce qui est un problème intéressant, lorsqu'on fait une démo à mon humble avis. Le comportement typique, c'est (en mode développement) d'aller chercher les fichiers dans l'archive, et s'il n'y sont pas où s'il y a une version plus récement modifiée sur le disque il faut remplacer le fichier existant dans l'archive et réécrire le tout sur le disque. On peut aussi gérer un historique des versions de chaque asset (shaders, modèles 3d, musique, textures...) au besoin, comme ça si on regrette un changement, on peut revenir facilement à une version antérieure.

J'ai utilisé une interface comme ça dans la dernière version de mon moteur de démos, même si c'est un peu... porc, j'avoue. Je ne suis pas très satisfait et je pense que ça leake un peu de mémoire... Bref à réitérer donc. C'est basé plus ou moins sur le design template composite, ce qui permet de gérer des répertoires également dans le fichier .dat qui sont invisibles dans la distribution. Pas de parano, c'est juste pour trier les choses proprement là. :)

http://pastebin.com/j20F5eGe


Offline RaHoW

  • Base
    • Pouet.net
    • View Profile
    • Apex - official site
  • Ancienneté: 1993
  • Groupe: Apex
  • Rôle: Gfx, code, orga
Re : Données dans exe
« Reply #29 on: 19 May 2011 à 23:21:03 »
Mais pour les 64kb ce ne sont pas ses méthodes qui sont retenues. Pour la zik se sont les synths et pour les graphs c'est pratiquement que du procedural + shaders.

Bien sûr, mais que je sache, même si c'est "pas moderne" et que "ça plait pas au "tout-pouet" ", aucune loi à ma connaissance n'interdit de faire des 64k "à l'ancienne", avec un bon vieux XM et quelques gfx par ci par là ^^
=RaHoW/Apex=