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.