Utilisation des fichiers externes - Page 1

quand un programme utilise des données dans un fichier externe, vous préférez que les fichiers soient compressées (peu de place mais tps de chargement et utilisation supp. de RAM) ou des fichiers non compressés (aucun tps de chargement mais fichiers volumineux)[sondage=14054]

cela depend !

Si c'est au demarrage du prog je prefere qu'il soit compresse mais si il doit tous le tps travailler dedans il vaut mieux qu'il ne le soit pas

Pour moi le vrai problème c'est surtout la conso de RAM. Et tout dépend du taux de compression de tes données : ce n'est peut-être pas la peine de perdre 10ko de RAM si c pour gagner 1ko en archive, mais si c pour en gagner 8, ça a des chances d'être rentable (sauf si évidemment tu es déjà très juste au niveau de la RAM).

perso, je compresse les fichiers externes...
au chargeent du jeu, je décompresse les données générales
et au chargement de chaque niveau, je décompresse les données spécifiques au niveau

je pense que la solution de squale92 est la meilleur

je pense que la solution de squale92 est la meilleur

disons que c'est celle que je préfére...
ça implique une ou deux secondes au chargement du jeu, plus une ou deux secondes au chargement de chaque niveau... mais je suis d'avis que une ou deux secondes sont peu de temps par rapport au gain de place réalisé.

mais je suis d'avis que une ou deux secondes sont peu de temps par rapport au gain de place réalisé.

Entierement d'accord et attendre une ou 2 secondes entre chaque niveux n'est pas bien grave ce qui serait grave c'est que cela ce produise pendant le jeu !

le pb C ke pour super metroid les niveaux sont gros (+ de 50ko pour certains) donc les tps de chargement sont de l'ordre de 5sec si C pa +.
pour le moment ils sont compressés mais j'avoue ke j'hésite a les utiliser comme ca
les données génerales (le perso, les objets, les textes, ...) le sont aussi et ils sont décompréssés au lancement et C vrai ke ca ne gène pa trop.
du coup la RAM est tres utilisée (en plus j'utilise genlib donc il y a les dscreen a ajouter)

Tibz8
: Entierement d'accord et attendre une ou 2 secondes entre chaque niveux n'est pas bien grave ce qui serait grave c'est que cela ce produise pendant le jeu !

le pb est ke les changements de niveau font parties du jeu, C pa juste un passage du niveau 1-1 au niveau 1-2, C plutot un passage de la zone A a la zone B

le pb est ke les changements de niveau font parties du jeu, C pa juste un passage du niveau 1-1 au niveau 1-2, C plutot un passage de la zone A a la zone B

la j'avoue que je ne comprend pas !!

le pb C ke pour super metroid les niveaux sont gros (+ de 50ko pour certains) donc les tps de chargement sont de l'ordre de 5sec si C pa +.

Tu peux avoir un temps de 2 secondes maxi avec le format de Pollux

Je vous rapelle qu'il existe les 'Pack Archive'

Thibaut B
:

le pb C ke pour super metroid les niveaux sont gros (+ de 50ko pour certains) donc les tps de chargement sont de l'ordre de 5sec si C pa +.

Tu peux avoir un temps de 2 secondes maxi avec le format de Pollux

La routine de décompression tourne autour de 80 ko/s, donc 50 ko ça se décompresse en à peine plus d'une demi-seconde

Entierement d'accord et attendre une ou 2 secondes entre chaque niveux n'est pas bien grave ce qui serait grave c'est que cela ce produise pendant le jeu !

oué, clair
qd tu met en pause, aussi, tu peux te permettre une demi-seconde de temps de chargement, pour décompresser la fonction de pause...
pareil pr la fonction d'enregistrement de record...

Je vous rapelle qu'il existe les 'Pack Archive

ttpack + ttarchive, ça marche bien

Pollux
:

Thibaut B
:

le pb C ke pour super metroid les niveaux sont gros (+ de 50ko pour certains) donc les tps de chargement sont de l'ordre de 5sec si C pa +.

Tu peux avoir un temps de 2 secondes maxi avec le format de Pollux

La routine de décompression tourne autour de 80 ko/s, donc 50 ko ça se décompresse en à peine plus d'une demi-seconde

Pourtant mon shell met plus de 0,5 secondes à se lancer je crois. A ce propos, j'ai un mini-message à t'envoyer

pour le moment je V rester avec ttpack, je verrai par la suite s'il vo mieux changer.

est-ce k'il est possible d'implanter xpack directement dans le prog plutot ke de l'utiliser en externe? j'avoue ke je préfèrerai mais bon j'en ferai pa un drame si C pa le cas

Tibz8
: la j'avoue que je ne comprend pas !!

en fait le jeu est un ensemble de zones accollées les unes aux autres et on peu passer de l'une a l'autre qd on ve. C pas comme un shoot'm up par exemple ou tu passe de niveaux en niveaux et ou tu peux te permettre un tps de chargement.

Pourtant mon shell met plus de 0,5 secondes à se lancer je crois

Bon, j'ai mesuré sous VTI : la décompression ne prend que 0.45 secondes, et AMS prend 0.1 secondes juste pour copier le programme en RAM (erf, je sais pas comment il se débrouille pour prendre autant de temps ). En mettant un "return;" tout au début de _main() et en le faisant tourner en boucle, il met 0.6 secondes pour se charger puis se décharger (d'où la différence de 0.05 secondes).
Après, le reste du temps de lancement doit être bouffé par Einstein (il doit y avoir un truc comme 0.9 secondes pour lancer Einstein, sous VTI).

En plus la compression pour les programmes (celle de GTC) est plus "lourde" que celle pour les données (XPak), elle prend 0.45 secondes alors que XPak se contenterait de 0.35 secondes. D'ailleurs, 30 ko en 0.35 secondes, ça fait 90 ko/s : donc un peu plus que ce que j'avais dit plus haut (mais ça, ça dépend des données à décompresser : parfois on fait du 70 ko/s, parfois 90 ou plus).

PS : oui, Kevin, on ne peut pas faire des bench avec VTI. Mais vas t'amuser à bencher le temps que met l'appel de HeapMoveHigh (fait par AMS) sur ta calc Et l'ordre de grandeur est correct.

est-ce k'il est possible d'implanter xpack directement dans le prog plutot ke de l'utiliser en externe? j'avoue ke je préfèrerai mais bon j'en ferai pa un drame si C pa le cas

Le décompresseur est en lib statique (il n'est pas très gros, 800 octets environ), mais je n'ai pas encore fait de lib au format TIGCC (fichier .a), seulement au format GTC.

en fait le jeu est un ensemble de zones accollées les unes aux autres et on peu passer de l'une a l'autre qd on ve. C pas comme un shoot'm up par exemple ou tu passe de niveaux en niveaux et ou tu peux te permettre un tps de chargement.

SMA a aussi ce problème, et fait une petite pause (une demi-seconde) lorsqu'on changeait de zone. Il utilise shrinklib (qui est assez rapide, un peu plus lent que XPak je crois mais pas forcément de beaucoup), mais c'est pour kernel. Attention, si tu utilises ttpack, tu risques d'avoir de gros problèmes de vitesse et/ou de taux de compression (si tu essayes de trop morceler tes niveaux).

Pollux
: Le décompresseur est en lib statique (il n'est pas très gros, 800 octets environ), mais je n'ai pas encore fait de lib au format TIGCC (fichier .a), seulement au format GTC.

j'attendrai un petit peu alors

Pollux
: SMA a aussi ce problème, et fait une petite pause (une demi-seconde) lorsqu'on changeait de zone. Il utilise shrinklib (qui est assez rapide, un peu plus lent que XPak je crois mais pas forcément de beaucoup), mais c'est pour kernel. Attention, si tu utilises ttpack, tu risques d'avoir de gros problèmes de vitesse et/ou de taux de compression (si tu essayes de trop morceler tes niveaux).

de toute facon le jeu est en mode kernel.
pour ce ki est des niveaux j'essai de les faire le plus etendue possible.
en fait il y a un plan de tiles pour un arrière plan (plan "standard") + un premier plan (plan avec posibilité de flipping, ..) + une matrice 2x2 (2o par tile) pour la gestion des différents blocs, objets, ...
en gros pour un tiles il me fo 5o donc ca me fait des zones de 13000 tiles ce qui est pa mal je trouve

Une solution pour minimiser la consommation de la RAM tout en réduisant celle de l'archive, mais évidemment au dépens de la vitesse, est de décompresser on-the-fly, c'est-à-dire d'utiliser une compression simple (par exemple RLE) et d'utiliser des routines d'affichage de sprites compressés (RLE).

A part pour un écran de titre où il y a plein de blanc, les sprites sont très mal compressés en RLE, en tout cas si tu le fais octet par octet. D'ailleurs comme type de compression context-independent, à part RLE ou Huffman, je vois pas trop... Et Huffman est soit lent, soit compliqué à décompresser, et de toute façon il ne sera pas extraordinairement efficace (même s'il le sera plus que RLE ).

J'ai aussi une méthode qui pourrait booster pas mal la décompression XPak, mais j'ai vraiment la flemme de l'implémenter... (elle nécessiterait un changement assez important au niveau du format d'entrée).

Et de toute façon dans tout les cas ça reste dépendant du contexte. D'ailleurs (désolé si ce truc est un peu confus pour ceux qui ne connaissent pas bien LZ ) je me demande si ce serait pas possible d'implémenter un LZ (ou plus généralement, un PuCrunch-like comme TTPack ou XPak) à dépendance limitée (et non à distance de LZ limitée) : i.e. quand on décompresse une séquence LZ, il faut qu'elle soit à une distance d du point d'insertion de moins de d_max et que les octets auxquels elle fait référence soient des littéraux ou bien des séquences LZ à une distance d' de moins de d_max-d, et qu'elle ne fasse elle-même référence qu'à des littéraux ou des séquences LZ à une distance de moins de d_max-d-d', et ainsi de suite... Je ne suis pas sûr que la pénalité de taux de compression soit complètement dissuasive (ça doit rester qd même assez supérieur à Huffman), et ça permet de pouvoir accéder à un endroit quelconque du fichier compressé en décompressant seulement d_max octets en trop (et accessoirement, on peut aussi se contenter d'un buffer de taille d_max). En limitant seulement la distance du LZ, on a l'avantage de la mémoire en O(d_max), mais on n'a pas le "temps d'accès" (comme sur les disques durs ) en O(d_max).

Kevin Kofler
: Une solution pour minimiser la consommation de la RAM tout en réduisant celle de l'archive, mais évidemment au dépens de la vitesse, est de décompresser on-the-fly, c'est-à-dire d'utiliser une compression simple (par exemple RLE) et d'utiliser des routines d'affichage de sprites compressés (RLE).

dans mon cas il est tres dur de reduire l'archive dans la mesure ou il y a un tas d'animation du perso et parfois du décor. je ne peu pas non plus me laisser la vitesse de coté meme si genlib est tres rapide.

a mon avis je vais rester sur une utilisation des fichiers compressés et en décompresser le + possible au lancement
pour le moment avec ttpack et apres je verrai avec xpack

Perso:
+ Les graphs du persos, ennemis, bref les sprites -> Fichier archivee non-compressee.
+ Les graphs du decor, les niveaux -> Compresse et decompresse seulement si besoin.

Le plus simple est de laisser le choix a l'utilisateur (Pack Archive powa: compresses ou non-compresses (et quel que soit le format de compression): kernel::ExtractFile + HeapFree). L'utilisateur final pourra compresser avec shrnklib, ou Xpack ou TTpack.

+ Les graphs du persos, ennemis, bref les sprites -> Fichier archivee non-compressee.

Ca dépend. S'il y a des gros sprites assez redondants (comme dans SF2), ça peut être très rentable d'en compresser une partie.

en y refléchissant ca n'apporte pa vraiment de compresser les sprites, ca va consommer pour rien, par contre ma matrice 2x2 et mon premier plan le seront puisque je les modifie (et C svt le cas) lors du jeu et C modification ne doivent pas rester -> un fichier compressé est extrait dans de la mémoire libérée par la suite et ca ne modifie pas le fichier d'origine

Pollux->la plupart des BGS du perso font 32x48 et les ennemis (16 ou 32)x(16x32). j'obtient avec ttpack des compressions de l'ordre de 30 ou 40% de la taille initiale

ou puis-je trouver de la doc sur la création et l'utilisation depack archive?

Dans le pack de preos il y a tous les outils et la doc pour créer des pack archives.
Attention ca ne marche qu'avec preos.

C'est pas ma faute.

G comris comment les créer mais pas comment les utiliser.
dans la doc de preos G vu qu'il y avait des fonctions (kernel::ExtractFromPack, kernel::ExtractFile et kernel::ExtractFileFromPack) mais je n'ai pas vu + d'explications.

tant pis pour le fait que ca ne marche qu'avec preos, C bien dommage!

C'est vrai que la doc n'est pas extrèmement détaillée mais elle me semble suffisante

je viens de trouver les fonctions en question dans ext.asm, je vais voir si j'arrive à comprendre qqchose (bah voui avec un niveau comme le mien en asm C pas gagné!)