J'ai eu une idée... - Page 3

Et pourquoi nécessairement passer par un pack?

Pour eviter d'avoir plusieurs fichiers. Mais rien ne t'obbliges a compresser tes fichiers dans le pack !

Pourquoi mon système d'une seule dll ne serait-il pas mieux? sans compter les 80 octets du header en moins ^^

Parce que croire qu'on peut enlever cet overhead est utopique. Il y en aura toujours.
On peut faire mieux, mais une fois qu'on met la main dedans, on ne sait pas jusqu'où il faudra aller.

A moins de créer une BSS avec le launcher, et d'exporter son adresse au lancement du launcher (launcher@0000: dc.l BSS_Adress 0). Ca n'a pas de raison de ne pas marcher non?

Oui.

Et sinon, le truc que je ne comprends vraiment pas, c'est comment faire un system de cache si je laisse tout faire au kernel, ie si je passe par le format des pack archives... J'ai du mal saisir quelquechose, tu pourrais me détailler ça stp?

topics/52397-cachelib
A moins que tu ne veilles plus de details techniques ?
En gros, ton cache fait croire a PreOS que la librairie est toujours chargee (il a une table interne ou il charge les libs).
Puis il la decharge par un LibsEnd : tant que le cache conserve une ref sur la lib (en gros nbr de LibsBegin > nbr de LibsEnd effectué, la lib reste chargée en mémoire).

Martial Demolins :
Et j'ai toujours l'idée de faire pareil pour des données fixes (par ex. des sprites 16*16 4ng). Je pourrais à ce moment là créer une lib par donnée, mais je te raconte pas la perte de place ^^

Mais pour les données fixes, les libs read-only suffisent... (ou j'ai mal compris ce que tu veux ?)

Ah, effectivement

>ouep, sauf si ces données sont compressées (maintenant, vu la taille de l'archive...)
Oue, mais dans ce cas tu les mes en ro, et le cache determine que le cout memoire de la lib est nul. Donc elle reste en permanence accessible.
(Sauf les maps /gfx qui sont compresses)

>Mais sinon, quelle est ta méthode à toi pour cacher des données pour CF?
Ben "cachelib" pour tout.

Pas forcement. Tout depend de ce que tu veux faire exactement.

J'ai pas écrit de lib. C'est intégré dans cf, et pas vraiment sortable maintenant :\

J'attend avec impatience ce jeu !!!!!

ça dépend, si tu utilises ER_catch et compagnie (je ne me souviens plus des détails), ton programme reste maître et tu as le code d'erreur
sinon, le kernel reprend la main
s'il n'y a pas de kernel, y a une boîte de dialogue qui s'affiche avec le code d'erreur et ton programme est quitté brutalement

il ne se termine pas bien, tout simplement aucune mémoire libérée, le programme reste verrouillé il me semble, bref, c'est mal fichu

pour rattraper un ER_Throw, la bonne méthode c'est d'utiliser
http://tigcc.ticalc.org/doc/error.html#ER_catch
http://tigcc.ticalc.org/doc/error.html#ER_success
http://tigcc.ticalc.org/doc/error.html#ERD_dialog

comme ça, ton programme garde la main à tout moment
après, tu peux laisser le kernel bosser, mais bon, c'est mieux d'avertir gentiment l'utilisateur du problème

>- j'aurais voulu savoir si tu utilises un système intelligent de libération de cache, à partir de la taille et de la fréquence de ce que tu gardes/effaces dans le cache.
FIFO mais je compte améliorer.

>- quand tu veux garder une lib en cache, tu fais juste un LibBegin sur cette lib, non?
Oui

>quelle est la taille moyenne des libs que tu emploies?
1K-60Kb.
Moyenne, je sais pas.

Moyenne 3-4Kb.

60K = en general Map compressée ou tiles compressée.

oui pour la première question (on passe bien en superviseur avec un trap #12)
et il me semble que masquer le bit S du SR suffit à basculer en mode utilisateur