Packaging - Page 2

Je suis déjà dans la vraie T2 dont vous usurpez les initiales: la TIGCC Team.

Kevin : Ah oui... elle est terrible ton équipe... elle est composé de 1 personne

Martial Demolins (./32) :
C'est très couteux? shrnklib va te décompresser ton niveau en qq centièmes de secondes, rien de dramatique, faut pas être ridicule.

Alors déjà shrnklib est plus lent que ttunpack_small (et je ne parle même pas de ttunpack_fast là). Et ensuite, si c'est pour charger un niveau, le niveau est censé être dans un fichier de données, pas une lib conditionnelle. Si c'est pour du vrai code, je te vois mal décompresser une lib comme ça en pleine action de jeu, ça va ramer à fond. Donc je vois mal un jeu où un tel chargement de code sur demande est faisable, sauf si tu abuses du chargeur de code en tant que chargeur de données.

On peut donc avoir 20 niveaux dont un seul sera en RAM avec le moteur de jeu

Sais-tu ce qu'est un fichier de données? C'est parfaitement faisable en _nostub de charger un niveau externe, et le fait que ce sont des données pures fait qu'on n'a pas à se soucier de la protection anti-exécution.

Kevin, toi qui court après les économies de RAM, je vois pas pourquoi tu es contre ça

Parce que ça gaspille de l'archive, l'économie de RAM ne sert à rien quand tu consommerais de toute façon moins que pas mal de jeux courants (parce qu'il faut de toute façon garder cette RAM libre pour les jeux qui consomment plus) et finalement oui, aussi parce que ça nécessite un kernel.

Moi je ne trouve pas que nécessiter un kernel soit un problème. Le kernel donne accès à plein de fonctionnalités, dont celle que décrit Martial. C'est très bien.

Martial Demolins (./32) :
Thibaut : j'ai commencé à écrire un jeu dont l'intro se décharge complètement quand on passe au about, le about se décharge quand on passe aux options, les options quand on charge un niveau, le chargement de niveau (parsing du niveau préparation des graphismes etc...) quand on joue etc...

J'avais fait ça dans KryptonII #vapor#

Kevin Kofler (./36) :
Donc je vois mal un jeu où un tel chargement de code sur demande est faisable, sauf si tu abuses du chargeur de code en tant que chargeur de données.

Pour tout ce qui est menus, c'est parfaitement faisable... Et ça permet de faire des menus complexes (je n'ai pas dit "compliqués à utiliser" !) en se souciant moins de l'impact que ça peut avoir sur la mémoire / la taille du prog / la limite des 64Ko

Martial Demolins (./38) :
De puis quand parles-tu de vitesse toi?

C'est toi qui as parlé de vitesse:

Martial Demolins (./32) :
shrnklib va te décompresser ton niveau en qq centièmes de secondes, rien de dramatique, faut pas être ridicule.

Et sinon, je te signale que shrnklib est aussi plus grosse que ttunpack_small. (Nettement plus grosse. J'ai viré tous les trucs qui ne servent pas pour pstarter et ça a quand-même donné un pstarter plus gros qu'avec ttunpack_small.)

Un truc qu'il faut envoyer/archiver en plus du programme. C'est tout sauf user-friendly ça.

Alors déjà mettre un fichier de données compressé dans le même PPG que le programme est faisable en principe, Lionel voulait faire un format pour les PPGs à plusieurs morceaux, il ne l'a jamais fait. Je vais peut-être en faire un.

Mais sinon je ne vois pas ce que ça change de devoir envoyer 3 fichiers (lanceur+PPG+fichier de données) à la place de 2, et ça a l'avantage que le fichier de données peut utiliser les pleins 64 KO (même 64 KO compressés si c'est un fichier à plusieurs morceaux, genre ttarchive).

squale92 (./39) :
Pour tout ce qui est menus, c'est parfaitement faisable... Et ça permet de faire des menus complexes (je n'ai pas dit "compliqués à utiliser" !) en se souciant moins de l'impact que ça peut avoir sur la mémoire / la taille du prog / la limite des 64Ko

Pour les menus, un jeu qui s'intègre correctement à la plateforme utilise les menus du système! Et du coup pas de problèmes de place, parce que tout le code est en FlashROM.

T'es nul là Kevin.

Kevin Kofler (./40) :
Je vais peut-être en faire un.

Tu as d'autres choses plus urgentes à faire.
(Au passage, je précise que les Pack Archive ne sont pas obligatoirement liées à shrnklib. A écouter Kevin, on dirait. Donc je précise).

Dans un programme _nostub, on a forcément besoin d'un lanceur séparé pour contourner la limite de taille de certains AMS.

Voilà pourquoi le kernel apporte un avantage à l'utilisateur (et GTC également).

Pour les menus, un jeu qui s'intègre correctement à la plateforme utilise les menus du système! Et du coup pas de problèmes de place, parce que tout le code est en FlashROM.

Je vois trop CF avec les boites de dialogue d'AMS

Mais Martial, je ne vois absolument pas pourquoi tu rigoles, voyons
Kevin a parfaitement raison, comme toujours, et là, c'est complètement évident qu'il a raison: tu sais pourtant bien que l'intégration à la plate-forme telle qu'elle est prévue par TI, nécessite qu'on n'utilise pas de niveaux de gris. Donc l'utilisation des menus d'AMS est beaucoup moins un problème.
Arrête donc de critiquer Kevin à tout bout de champ, vilain (prends exemple sur moi )

Et puis ils sont tellement beaux les menus d'AMS... D'ailleurs c'est bien connu, tous les jeux PC utilisent des boîtes de dialogue de Windows pour interagir avec l'utilisateur...

Thibaut (./45) :
Voilà pourquoi le kernel apporte un avantage à l'utilisateur (et GTC également).

La méthode de GTC ne fonctionne pas pour les programmes de plus de 7 KO compressés (c'est-à-dire la plupart des programmes sérieux - 7 parce qu'il faut aussi de la place pour le code de décompression/lancement et on n'a que 8 KO en tout), on en a déjà discuté.

Kevin Kofler (./40) :

squale92 (./39) :
Pour tout ce qui est menus, c'est parfaitement faisable... Et ça permet de faire des menus complexes (je n'ai pas dit "compliqués à utiliser" !) en se souciant moins de l'impact que ça peut avoir sur la mémoire / la taille du prog / la limite des 64Ko

Pour les menus, un jeu qui s'intègre correctement à la plateforme utilise les menus du système! Et du coup pas de problèmes de place, parce que tout le code est en FlashROM.

j'étais sûr que tu répondrais ça

Kevin, oui, on en a déjà discuté. Et je t'avais expliqué que la limite est de 24 ko pour 90% des utilisateurs. Tu as la mémoire courte

Et je t'avais expliqué que ce qui compte pour TIGCC, ce sont 100% des utilisateurs, pas 90%.
De plus, je t'avais expliqué qu'il existe plein de jeux qui font plus de 23 KO compressés.
Donc c'est toi qui as soit la mémoire courte, soit de la mauvaise foi. Et surtout tu réponds à côté parce que mon ./44 parlait justement de la limite de taille à contourner et que la méthode de GTC ne contourne pas du tout la limite de taille, donc GTC était totalement hors sujet dans ton ./45.

Alors moi je t'explique que "plein de jeux" ne signifie pas "la majorité des programmes".

Plus de la moitié des programmes sont en-dessous de la limite de 24ko une fois compressés, et sont donc accessibles à 90% des utilisateurs (d'ailleurs le chiffre "90%" augmente d'année en année étant donné que la Titanium n'a pas de limite je crois).

Tous ces programmes peuvent donc êtres compilés avec GTC, ce qui apporte un avantage sympathique aux utilisateurs. Les autres peuvent se compiler avec le système de TIGCC.

Je ne pense pas être hors-sujet. Il te manque peut-être un peu de discernement : il n'y a pas de vérité absolue mon cher. Tout dépend du programme.

Kevin Kofler (./51) :
Et je t'avais expliqué que ce qui compte pour TIGCC, ce sont 100% des utilisateurs, pas 90%.

On s'en fout de ce qui compte pour TIGCC, de ton avis. Ce sont les programmeurs qui choisiront entre GTC ou TIGCC, selon qu'ils préfèrent 1 fichier ou 2 fichiers, et selon la taille de leur programme.

> Ce sont les programmeurs qui choisiront entre GTC ou TIGCC, selon qu'ils préfèrent 1 fichier ou 2 fichiers,
Argument moyennement valable: non seulement il y a le lanceur générique non transparent ttstart("ppgname"), mais aussi, il y a le lanceur générique transparent (FlashApp, AMS 2.05+) SuperStart

Ben ça fait toujours 2 fichiers et complique l'étape du lancement du programme. Ca renforce ce que je dis, ça ne l'invalide pas

> Ben ça fait toujours 2 fichiers
Depuis quand les FlashApps sont des fichiers, une fois qu'ils sont transférés sur la TI-68k ?
(Bon, là, je fais exprès de faire la mauvaise foi, parce que sur l'ordinateur, les FlashApps sont bien des fichiers, et que ça fait bien un fichier supplémentaire à transférer )
Mais que ce soit pour ttstart ou sstart, le transfert est fait une fois pour toutes (sauf mise à jour, mais il n'y en a plus pour sstart et pas beaucoup pour ttstart). Comme toute FlashApp, sstart est réinstallée automatiquement à chaque reset, contrairement à ce qu'on appelle "kernel".

En RAM, pratiquement pas, quelque chose de l'ordre de 24 octets. C'est une FlashApp, donc tout en FlashROM.

Super Start ne charge rien du tout en RAM, c'est une FlashApp.
Le problème, évidemment, est celui des signatures, c'est pour ça que mettre à jour Super Start est pénible et donc que ça n'évolue pratiquement pas (par exemple la routine ttunpack là-dedans n'est pas optimisée).