Vous la voulez? - Page 7

[sondage=13120]

A savoir que si je met les 2, il faut faire une sorte d'émulation de Mode comme sur les console.. et que cela rendra le code un peu plus lourd (XGMod(SwapBuffering);...)

J'ai voté swap buffering.

Ben ouai sinon Xlib serait plus lente que GraphX ! quel dommage

lol... t'inquiette ya de la marge (genlib utilise le swapbuffering, mais elle est plus lente).

erf c'est vrai
Enfin voilà quoi, ta lib pourrait être encore plus rapide avec le swap buffering

heurf, CpyBuffering rulez

a la limite ce qui m'interesserai dans le swap buffering, c'est pas la vitesse (negligeable) mais le gain de place (pas de fonction de cpy..)

oué mais c moins bien

la méthode la mieux pour la qualité de l'image ! sur HW1 comme sur HW2

au fait TIMad, la taille des fonctions, ça donne quoi ?

j'aurais besoin ds mon prog des 2 fonctions de sprite 16*16 (GT et GM), des fonctions de plan (création, néttoyage, recopie sur le LCD). Et aussi des fonctions de textes s'il y en a.
Ca prend combien ???

bein:
XLib va générer automatiquement sa fonte a partir d'effets (pas encore defini, j'en parle avec neuroo en ce moment)
donc t'as pas besoin de fonte. (-1.5 Ko)
sinon pour le reste faut compter 5 Ko je pense.. je sais pas du tout en fait

Bah tu le calcules en gros avec un prog au pire (prog avec la dernière version de Xlib)
Un prog active les grays, crée un Gplan, le nettoie, affiche un sprite 16*16 maské puis affiche un sprite 16*16 par transparent, recopie le Gplan à l'écran , détruit le Gplan ert désactive les grays et quitte.

En stockant les 2 def de sprites globalement ds le prog (dehors de toute fonction), tu soustraits ensuite au prog (2*16*3 /*mask*/ + 2*16*2 /*transp*/), et qq octets pour l'appel des fonctions et passage par registre, et tu as en gros la somme des taille des fonctions demandées, et ça me renseigne .

6.5ko ...
Mais il faut savoir que:
> si tu veux maintenant une routine de fonte, ca te prendre que 60 octets, si tu veux afficher une Pic (image par exemple de taille 16x*16x) ca te rajoute que 70 octets.
tu auras aussi les routines:
extern void XClrGPlan(void)__ATTR_LIB_ASM__;
extern void XClrDPlan(void)__ATTR_LIB_ASM__;
extern void XClrLPlan(void)__ATTR_LIB_ASM__;
extern void XClrBWPlan(void)__ATTR_LIB_ASM__;
extern void XGPlanc(register void *plan asm("a0"))__ATTR_LIB_ASM__;
extern void XBWPlanc(register void *plan asm("a0"))__ATTR_LIB_ASM__;
extern void XCpyBWPlanToLPlan(void)__ATTR_LIB_ASM__;
extern void XCpyBWPlanToDPlan(void)__ATTR_LIB_ASM__;
extern void XCpyGPlanToLCD(void)__ATTR_LIB_ASM__;
extern void XCpyGPlanToInvLCD(void)__ATTR_LIB_ASM__;
extern void XCpyDPlanToLLCD(void)__ATTR_LIB_ASM__;
extern void XCpyDPlanToLCD(void)__ATTR_LIB_ASM__;
extern void XCpyLPlanToDLCD(void)__ATTR_LIB_ASM__;
extern void XCpyLPlanToLCD(void)__ATTR_LIB_ASM__;
extern void XCpyGPlanToGPlan(register void *planc asm("a0"),register void *plan asm("a1"))__ATTR_LIB_ASM__;

> Le ratio de compression est de 50 % (normal car les routine sont assez repetitives.) ca fait 2.9ko

> Ton GPlan n'est que de 3840*2 octets.

> La routine de Gray de TIGCC qui fait 1 Ko. + tout le bordel de tigcc.

Voila donc en fait, si les routines sont assez grosses, c'est pour obtenir un maximum de rapidité... elle sont ensuite reprises pour pas mal de routine.

Je vais peut etre prevoir des routines plus petites? je sais pas
Ou alors je la met en DLL ? comme genlib sauf que gen c'est un dll dynamique....

Mais bon apres faut voir certains avantages:
Tu n'as pas besoin de fonte ... XLib genere automatiquement ta fonte en 4 gray avec des effets **** etc...

__ATTR_LIB_ASM__ est réservé pour l'usage dans TIGCCLIB. À ne pas utiliser dans _X_Lib!

timad> t'as oublié les routines geométriques .. alors pim89 si tu veux prendre toutes les fonctions geométrique dans ton programme, ca le fera gonfler ...

TiMad a écrit :
Je vais peut etre prevoir des routines plus petites? je sais pas
Ou alors je la met en DLL ? comme genlib sauf que gen c'est un dll dynamique....

ok
en DLL ??? cad ???
Xlib en fichier externes au prog ? ça m'arragerait un peu remarque, car mon prog gonfle avec Xlib et je vais manquer de place.
Enfin si je me gourre, tant pis, je me débrouillerai qd même.
Tant que j'ai la nouvelle version, c cool.

en Dll = librairie dynamique pour prog nostub

squale92: t'en pense quoi? dll ca peu etre benfique..

Je t'ai répondu en mini-msg, mais je le remet ici pr que tout le monde puisse voir ma réponse.

En Dll, ça vet dire que toutes les fonctions de la lib doivent être en RAM pour l'exécution...
En statique, ça veut dire que seule les fonctions qu'on utilise sont incluses, en donc que celles-ci sont en RAM pour l'exécution.

Pour KII (et pour tous les projets qui ont besoin de BCP de RAM), je préfère la seconde solution.

A mes yeux, l'idéal serait que Xlib soit distribuée en statique, et en Dll, et que ce soit au programmeur du jeu de choisir.

Pour ce qui est de la dll, il n'y aurai pas grand chose dedans:

XOn;XOff
La routine pour creer une fonte a partir du tios: 400 octets
Les routines: XGT XGM XGT (tu doit surment toute les utiliser)
Les routines de plans ( XClrPlan et XCpyPlan .. toute les autres fonctions de plans ne font que 10 octets chacune ex(XCpyGPlanToLCD...) donc ces fonctions sont utilisées dans K2.

Les fonctions de pxl (elles prennent pas plus de 1Ko).
La fonction Xprintf et le Joypad.


Le reste serai en statique:XDrawLevel (car par exemple toi tu l'a reprog en C.., ).
X2d (toutes les fonctions 2d)

La je pense que c'est le meilleur moyen d'optimiser la RAM et la FLASH dans tous les cas...

Oué, une DLL avec les fonctions de sprites 16*16, les fonctions de plan ça m'arrangerait !

Il faudrait qu'il n'y ait pas plus de 7 - 8 Ko copié en RAM pour l'execution.

6 - 7 Ko c'est jouable... faudra que j'optimise qqs truc en taille mais ouai...

JS> moué...

les fonctions de texte, je sais pas si je les utiliserai.
Le joypad, je l'utiliserai pas
(je parle pr KII)
fonctions de pxl, peut-être que j'utilise un BWPixelGet

si elle est toujours open-source, je penses que je recopierai le code des fonctions pr les mettre en statique (avec ton autorisation)

Car pour mon RPG j'en suis à 10.5 Ko pour l'instant, et sachant qu'avec les menus (home, gestion d'objet, stats perso, sauvegarder ect) ça va me faire 10 Ko dans l'executable en plus, bah il me restera peu de place pour rajouter le moteur de combat.
En fait, combien peut faire la taille d'un prog nostub en C sur ASM 2.05 ??? pour qu'on puisse l'executer sans prob ? 24 Ko ?

elle existe(ra) aussi en version complete en statique et en DLL ...

Pim89 : avec GraphX tout s'arrangerait por ton problème de taille d'exe

nEUrOne> bien

Pim> sur 2.05, c 24ko.
mais suffit d'utiliser un launcher pr casser ça...
c pas un problème, normalement

la limite est de 64k par fichier

nEUrOne> je penses qu'il parlait de la stupide protection de TI, les 8/24ko

oué, je parlais du fichier compressé par tigcc

Oui oui, je savais déjà qu'il fallait pas dépasser les 64 Ko, mais c'était pour la taille minimal autorisée par l'ASM 2.05, soit les 24 Ko.
Bon, tant mieux alors si c'est cassable, car ça va faire un peu plus de 24 Ko pour le jeu pur à mon avis (et avec les graphismes, dial ect, j'en parle même pas ).
Je met un petit screen bientôt des dernières évolutions.

héhé, bien ca ..