Taille maximum atteinte :( - Page 1

Je viens d'avoir une assez mauvaise surprise en compilant gbs : il a dépassé 65520 octets, et ce en exportant quasiment tout en fichiers externes. En clair il ne reste plus que quelques GFX (qui vont également être passés en externe tout de suite), et le reste c'est du code...

En virant les derniers sprites je vais gagner un peu de place, mais pas grand chose. Je vais peut-être utiliser XLib en dynamique, c'est à dire la version avec une DLL (à condition que XLib 1.05 existe en dynamique), mais à part ça je ne vois pas comment faire pour : soit réduire la taille du code (pas la peine de me dire d'optimiser, croyez bien que si il y a des optimisations à faire c'est parceque je ne les ait pas vues), soit le découper en plusieurs parties mais je ne sais pas trop si c'est possible.

Voilà, les idées sont les bienvenues...

Je sais que c'est possible découper du code en plusieurs fichiers externes, mais Kevin saura sûrement t'expliquer comment faire en C contrairement à moi.
En asm, je crois que c'est pas trop sorcier, il faudrait trouver l'adresse du fichier externe avec la méthode habituelle, et faire un jmp sur l'adresse de ton code + $40000 (enfin je pense).

Vertyos a écrit :
Je viens d'avoir une assez mauvaise surprise en compilant gbs : il a dépassé 65520 octets, et ce en exportant quasiment tout en fichiers externes. En clair il ne reste plus que quelques GFX (qui vont également être passés en externe tout de suite), et le reste c'est du code...
En virant les derniers sprites je vais gagner un peu de place, mais pas grand chose.

Bon:
* vérifie que tu n'as pas de gros tableaux globaux; si tu en as, utilise malloc à la place
* utilise GCC 3.3 (prerelease)
* compile avec -Os -fno-if-conversion
* compile avec -mregparm=6
* essaye -fomit-frame-pointer, c'est presque toujours une amélioration
* compile avec -DUSE_FLINE_ROM_CALLS -DUSE_INTERNAL_FLINE_EMULATOR -fno-function-cse
* si c'est acceptable pour toi, utilise -DUSE_FLINE_EMULATOR (attention, plantage automatique si l'utilisateur ne suit pas les instructions) ou -DMIN_AMS=204 à la place de -DUSE_INTERNAL_FLINE_EMULATOR
* regarde aussi du côté des options pour supprimer le code de démarrage si c'est vraiment nécessaire

Je vais peut-être utiliser XLib en dynamique, c'est à dire la version avec une DLL (à condition que XLib 1.05 existe en dynamique)

* XLib 1.05 n'existe pas en DLL. Seulement 1.00.
* Il est beaucoup plus efficace de créer une DLL à toi. En utilisant une DLL XLib, tu gagnes 8 KO maximum. En utilisant une DLL à toi, tu peux gagner jusqu'à 64 KO.
* Lis http://tigcc.ticalc.org/doc/htdll.html.
* Fais cela seulement si toutes les autres solutions ne servent à rien.

Et pour ce que je proposais, c'est possible (de jumper à l'adresse du code externe) ?

Oui, mais il faut s'occuper de copier le fichier en RAM s'il est archivé etc. Le système de DLLs fait ça tout seul. C'est la manière prévue de règler ce problème.

Ok

Et dans les 2 cas (bidouillage avec jmp/jsr ou système de DLLs), il faut définir EXECUTE_IN_GHOST_SPACE. Avec ton bidouillage, tu risques un plantage si tu l'oublies, le systéme de DLLs détecte le problème et donne une erreur en temps d'exécution.

Tu as aussi -freg_relative-a5 comme flag.
Ou compile en kernel, aussi.

-

C'est ce qu'il dit. Il a qu'a utiliser les libraries kernels et creer une pack archive des 2 fichiers : personne ne verra que c'est 2 fichier séparé

-

PpHd
a écrit : Tu as aussi -freg_relative-a5 comme flag.

Si ça marche pour lui. Ce flag est (et a toujours été) un flag expérimental.

Ou compile en kernel, aussi.

...
Si c'était ce qu'il voulait, il n'aurait pas posté ce topic...

PpHd a écrit :
Il a qu'a utiliser les libraries kernels et creer une pack archive des 2 fichiers : personne ne verra que c'est 2 fichier séparé

Mais il faut un kernel...

C'est pas interdit de lui proposer après il fait ce qu'il veux

Kevin Kofler a écrit :
Bon:
* vérifie que tu n'as pas de gros tableaux globaux; si tu en as, utilise malloc à la place

Aucun tableau directement en global, uniquement des pointeurs

* utilise GCC 3.3 (prerelease)

C'est ce que j'utilise

* compile avec -Os -fno-if-conversion

Ok

* compile avec -mregparm=6

Ce switch fait planter Vertel quand je la compile avec, donc j'ai un peu tendance à l'éviter, mais j'essayerais.

* essaye -fomit-frame-pointer, c'est presque toujours une amélioration
* compile avec -DUSE_FLINE_ROM_CALLS -DUSE_INTERNAL_FLINE_EMULATOR -fno-function-cse

Ok

* si c'est acceptable pour toi, utilise -DUSE_FLINE_EMULATOR (attention, plantage automatique si l'utilisateur ne suit pas les instructions) ou -DMIN_AMS=204 à la place de -DUSE_INTERNAL_FLINE_EMULATOR

Non ça je préfere éviter (j'ai essayé de rendre le jeu le plus stable possible en vérifiant partout que toute la mémoire était bien rendue et que le jeu se quittait normalement en cas d'erreur).

* regarde aussi du côté des options pour supprimer le code de démarrage si c'est vraiment nécessaire

Je pense que c'est un trop petit gain pour être réellement interessant.

* XLib 1.05 n'existe pas en DLL. Seulement 1.00.
* Il est beaucoup plus efficace de créer une DLL à toi. En utilisant une DLL XLib, tu gagnes 8 KO maximum. En utilisant une DLL à toi, tu peux gagner jusqu'à 64 KO.
* Lis http://tigcc.ticalc.org/doc/htdll.html. * Fais cela seulement si toutes les autres solutions ne servent à rien.

Je pense que c'est une des solutions les plus efficaces, si les autres ne suffisent pas j'aurais sans doute à en venir là.

PpHd
a écrit : Ou compile en kernel, aussi.

Désolé, mais non.

Orion_ a écrit :
Vertyos > tu depasse les 65Ko de code pur ????

Quasiment, il reste 2~3 gfx dans le programme, une fois que je les aurait virés il n'y aura plus que du code (je soupçonne tout de même XLib de prendre une place monstrueuse, je verrais avec la version DLL).

Vertyos a écrit :
Ce switch [-mregparm=6] fait planter Vertel quand je la compile avec, donc j'ai un peu tendance à l'éviter, mais j'essayerais.

Quand tu es en OPTIMIZE_ROM_CALLS, c'est 5 maximum. C'est peut-être ça le problème.

Je pense que c'est un trop petit gain pour être réellement interessant.

Quand tu es à 65519 octets, n'importe quel petit gain est décisif.

Quasiment, il reste 2~3 gfx dans le programme, une fois que je les aurait virés il n'y aura plus que du code (je soupçonne tout de même XLib de prendre une place monstrueuse, je verrais avec la version DLL).

Tu gagnes 8 KO au mieux dans ton programme principal, vu que c'est la taille de la DLL. Et comme tu n'utilises pas forcément toutes les fonctions qui sont dans la DLL, tu gagnes probablement encore moins.

Et attends, mais une lib graphique, ça ne prend pas non plus une place énorme... Enfin, ça dépend ce que tu appelles énorme.
Regarde, genlib avec toutes les fonctions dedans (et il y en a vraiment un paquet) et non compressées tient dans 18ko. Une fonction d'affichage de sprite, ça fait dans les 200 octets MAXI.

Sinon, Kevin> est-ce qu'on ne risque pas d'avoir des pb avec la technique que propose Nerick, si on utilise du code qui contient des instructions avec des références vers des adresses absolues ? (je suppose qu'il faut exécuter EX_Patch pour résoudre le pb, non ? c'est compliqué en tout cas)

jackiechan
a écrit : Sinon, Kevin> est-ce qu'on ne risque pas d'avoir des pb avec la technique que propose Nerick, si on utilise du code qui contient des instructions avec des références vers des adresses absolues ? (je suppose qu'il faut exécuter EX_Patch pour résoudre le pb, non ? c'est compliqué en tout cas)

En effet.

c quoi gbs?

Un jeu.

Bon en appliquant tous les conseils (ou presque ) et en supprimant les derniers sprites globaux, la taille est pas mal redessendue (~10ko ).
Tout irait bien si un nouveau problème n'était pas apparu, que j'essaye de comprendre depuis maintenant une heure sans succès...

Au lancement le jeu cherche le fichier des sprites, comme il faisait avec celui des tiles, obtient un pointeur dessus, et en tire des pointeurs vers tous les sprites qu'il contient. J'ai vérifié, ils sont tous valides et pairs. Mais dès que j'appelle une fonction d'XLib qui les utilise -> Adress Error. Le plus curieux est qu'en les affichant avec une "mauvaise" fonction, comme Sprite16 par exemple, non seulement ça ne plante pas mais en plus la partie visible déformée du sprite me confirme que le pointeur est bon.

Je ne vois pas pourquoi ça serait dut à XLib puisque les tiles sont affiché suivant exactement le même procédé sans aucun problème

Merci de ta reponse concise Vertyos, lol.

Tu pourrais montrer un screen, car sur le forum du jeu, ben on va dire que les screen sont des liens morts...

D'ailleurs c'est une preuve que genlib en fichier separe est une bonne idee

tu ne peux pas faire deux fichiers séparés et compressés ayant du code ? (sans passer par la DLL ou les libs kernels)
Y'a pas moyen d'implanter un truc comme ca efficacement, pas comme les DLL

PpHd a écrit :
D'ailleurs c'est une preuve que genlib en fichier separe est une bonne idee

Non. Vu que le code ne peut pas disparaître, tu ne gagnes pas de taille au total. Tu gagnes donc pour le programme principal au maximum la taille du fichier DLL externe. Pour genlib, ce sont au maximum 16 KO. Probablement moins, puisque les 16 KO ne sont pas forcément tous utilisés. Pour une DLL spécifique au programme, on peut mettre jusqu'à 64 KO dans la DLL, donc gagner jusqu'à 64 KO pour le programme principal. On gagne donc 4 fois plus avec une DLL spécifique au programme qu'avec une DLL de genlib.

Pour qu'une DLL partagée ait vraiment un sens, il faut que sa taille soit au moins de 32 KO, et idéalement le plus proche possible des 64 KO. FAT Engine avec ses 50 KO en est un bon exemple.

nEUrOne
a écrit : tu ne peux pas faire deux fichiers séparés et compressés ayant du code ? (sans passer par la DLL ou les libs kernels)

Oui, mais il faut faire à la main tout le travail effectué par le système de DLLs.

Y'a pas moyen d'implanter un truc comme ca efficacement, pas comme les DLL

Le système de DLLs _nostub est efficace pour passer à travers la limite des 64 KO.

C'est vrai que la DLL est une bonne solution dans ce cas.

> C'est vrai que la DLL est une bonne solution dans ce cas.
Oui.

Vertyos: tu peux aussi faire comme FAT-Engine: refaire le support DLL en interne dans ton programme. Comme ça, tu pourras charger un DLL avec les fonctions de TIGCC, en plus du fichier externe déjà chargé. C'est quand même improbable que tu aies besoin de faire ça...

XDanger
a écrit : Vertyos: tu peux aussi faire comme FAT-Engine: refaire le support DLL en interne dans ton programme. Comme ça, tu pourras charger un DLL avec les fonctions de TIGCC, en plus du fichier externe déjà chargé. C'est quand même improbable que tu aies besoin de faire ça...

Je vais peut-être avoir recours aux DLL. Pourquoi ça serait improbable ?

Il ne doit pas connaitre ton projet ...

s'il te reste de la place dans un de tes fichiers de données, pkoi ne pas y mettre du code ?
(et, qui plus est, tu peux le compresser )
=> comme ça, tu le laisse en archive, et tu ne le décompresse en RAM que qd c nécessaire (enfin, fo pas avoir peur d'une demi seconde de chargement)
=> ça te laisse même plus de RAM libre pr le moteur

par exemple, c tout à fait jouable pour les fonctions de menus, un truc comme ça (c ce que je fais dans KII)

Tous les fichiers de données (sauf celui des gfx principaux) sont destinés à être modifiés par l'utilisateur, donc j'évite de mettre du code dedant, sans compter que ça ne me semble pas très rigoureux comme méthode. Tant pis pour la ram, de toute façon le jeu en utilise moins de 40ko pour l'instant donc j'ai de la marge (read-only powa).

Au fait, je n'ai rien vu la dessus, y a-t-il moyen d'utiliser la compression ppg pour les DLL ?

squale92 a écrit :
s'il te reste de la place dans un de tes fichiers de données, pkoi ne pas y mettre du code ?
(et, qui plus est, tu peux le compresser )

Parce qu'il faut:
* le reloger.
* penser à la protection des HW2.
Je déconseille très fortement cela sauf si on sait exactement ce qu'on fait.

Vertyos
a écrit : Au fait, je n'ai rien vu la dessus, y a-t-il moyen d'utiliser la compression ppg pour les DLL ?

Pour le moment, non.