Cacher les fichiers images,gfx,sons utilisés dans une appli (un jeu)? - C++ - Programmation
Marsh Posté le 06-07-2004 à 17:40:37
Jesus Army a écrit : (Un systeme de fichier "pack" comme on peut trouver dans les quake3 serait l'ideal s'il pouvait présenté un certain niveau de sécurité... |
les "pak" de quake3 sont en fait de simples fichiers zip
Marsh Posté le 06-07-2004 à 17:41:43
Beh ué, donc justement j'aurais aimé un truc un chouilla plus sécurisé plutot qu'un truc qui finalement sert juste à avoir un repertoire d'install plus clair...
(Par contre tu es sur que ce sont carrement des zip ?)
Marsh Posté le 06-07-2004 à 18:17:51
oui, t'as pas forcément besoin de les renommer pour les ouvrir. (7-zip se fout de l'extension)
Marsh Posté le 06-07-2004 à 18:20:35
sinon tu mets tout un zip encrypté par mot de passe, et t'auras le mot de passe dans l'éxécutable..
enfin bon bof quoi...
Marsh Posté le 06-07-2004 à 19:48:50
tu utilises un hashage que seul ton executable connait.
Ce n'est pas à l'épreuve des hackers mais ça évite les spoilers..
Marsh Posté le 06-07-2004 à 23:55:38
bjone a écrit : oui, t'as pas forcément besoin de les renommer pour les ouvrir. (7-zip se fout de l'extension) |
Vivi je sais bien que l'extension n'influe en rien le contenu, mais je pensais que c'etait quand meme une autre methode de compression. (D'ailleurs je pensais aussi que ce n'etait pas compréssé afin de garder une bonne vitesse d'accès)
Sinon le mot de pass ca me tente pas trop, je vais pitètre plutot me pencher sur la technique du hachage...
Marsh Posté le 07-07-2004 à 00:27:25
en fait la compression améliore la vitesse d'accès/chargement à tes ressources, car un fichier compressé réduit le temps d'accès disque, et généralement la décompression du Zip est très très rapide.
Marsh Posté le 07-07-2004 à 00:36:51
Tu peux jetter un coup d'oeil sur http://zziplib.sourceforge.net/ (mais je n'ai pas testé)
Marsh Posté le 07-07-2004 à 11:00:49
sinon y a LZO qui est pas mal, la decompression est ultra rapide et ne necessite que tres peu de memoire (de l'ordre de 16ko si mes souvenirs sont bons)
http://www.oberhumer.com/opensource/lzo/
c'est parfois utilise sur des clusters pour compresser en temps reel les donnees a transferer
Marsh Posté le 07-07-2004 à 12:11:56
Et avec ca je pourrais le mettre dans le readme. Ce jeu se sert de techniques utilisées par la NASA.
Marsh Posté le 07-07-2004 à 15:58:42
nan mais j'avoues que le LZO, ça peut être utile pour compresser les snapshots du monde lors de synchro réseau d'un jeu.
j'ai pas regardé Quake 3 il compresse ses datagrammes, mais il utilise quoi du LZW ?
Marsh Posté le 19-07-2004 à 18:46:55
J'ai teste une idee et elle marche (en tout cas avec DirctX). Il est possible de modifier l'extension des fichiers images (e.g. : "image.aaa" ) pour les rendre inacessible pour l'utilisateur banal. Bien entendue les images sont toujours editables avec paint quelque soit l'extension mais bon. De plus l'extension n'effecte pas le chargement des fichiers images dans une surface (DirectDraw). On peut aussi mettre toutes les petites images dans une grande, la charger et ensuite la repartir dans des surface avec les fontions Blt et BltFast de DirectDraw
Marsh Posté le 19-07-2004 à 21:49:36
si tu es sous windows tu peux peut etre les mettre en ressources dans ton executable
c'est fait pour ca
Marsh Posté le 20-07-2004 à 10:16:13
Oualb a écrit : si tu es sous windows tu peux peut etre les mettre en ressources dans ton executable |
Ué je pense que je vais tout betement faire ca, ca devrait etre bien suffisant en fait...
Marsh Posté le 20-07-2004 à 11:18:04
Ben non, parce que d'une tu te retrouves avec un executable de plusieurs Mo, de deux n'importe qui peut récupérer tes images avec un éditeur de ressources...
Marsh Posté le 20-07-2004 à 12:20:43
la méga idée de noob (oui oui c'est moi):
tu reecris byte par byte ton fichier en le prenant de la fin par exemple.
Ce qui fait qu aucun logiciel ne pourra le lire,et que cela n'a aucune importance pour toi puisqu'une fois qu il est en memoire ca ne pose plus de probleme.
Ou bien tu rajoute une entete bateau.
Ou bien tu split le fichier en deux en ecrivant un byte sur deux dans chacun.
Ou bien tu regroupes deux fichier en alternant un byte de l'un, un byte de l'autre (en indiquant la longueur de chacun dans une entete)
Ou bien...
C'est un cryptage bateau mais ca va freiner la plupart des gens.
edit : en fait je viens de me rendre compte que tu voulais justement eviter ca. Mais ca ne doit pas etre aussi laborieux que tu le dis !
d'ailleurs n'est ce pas ce que fait easports pour les musiques de ses jeux ? Ils ont un format asf tout bizare !
Marsh Posté le 06-07-2004 à 17:29:35
Bonjour à tous
J'ai fait quelques recherches, mais je n'ai pas trouvé grand chose... Cela dit, je ne chercher peut etre pas les bonnes choses...
Je réalise un jeu, et je voudrais que l'utilisateur ne puisse pas trouver les images, sons et autres fichiers utilisés dans le jeu. (Le but du jeu etant entre autre de debloquer des zimages par exemple, si le joueur peut les trouve dans le repertoire du jeu il n'y a plus aucun interet... Et de plus, ces images ne doivent pas pouvoir, dans la mesure du possible, se balader librement...) Pour les infos sous forme textuelles je pensais utiliser un simple fichier binaire pour stocker les information, mais je n'ai pas trop d'idées pour cacher le reste.
Bien sur je pensais à un cryptage de ces éléments, mais ca me parait bien compliqué pour si peu... Décrypter tout à chaque fois me parait bien laborieux comme methode... Il y a surement un moyen bcp plus simple que je ne connais pas... (Un systeme de fichier "pack" comme on peut trouver dans les quake3 serait l'ideal s'il pouvait présenté un certain niveau de sécurité...
Donc si vous avez des idées, celles-ci sont les bienvenues. (D'autant plus que le timing de dev est très sérré ! )
Voila, merci d'avoir pris le temps de me lire.