XLib, GraphX, Extgraph ou Genlib ??? - Page 5

Kevin> OK.
Thibaut> moi non plus (mais on sait jamais )

Bon j'ai pas beaucoup le temps de parler de ca, mais la difference des sprites est du au fait que j'ai bencher avec la routine la plus lente de XLib... qui par ailleur est beaucoup plus rapide dans la nouvelle version
Sinon pour ce qui est du bench, il a ete fait dans certaines conditions qui arrange extgraphlib.. sachant que extgraphlib gerer pas le cliping, si j'avais fait un buffer plus grand, je vous explique pas la diff de rapidité.....

Il ne me semble pas que nous t'ayons interdit d'intégrer les routines clippées à ExtGraph. En plus, je te signale que Thomas en a fait (c'est sûr, il faut être au courant).
Mais tu n'aideras pas ExtGraph: tu es bien trop attaché à ta petite lib propriétaire !


Thibaut: tu as optimisé GX_DrawStr depuis la version du 18 août ?

Non, elle est assez rapide à mon goût. Si un utilisateur a besoin de plus rapide, je le ferai.

G rien dit j'avais mal lu...

XDanger a écrit :
Il ne me semble pas que nous t'ayons interdit d'intégrer les routines clippées à ExtGraph. En plus, je te signale que Thomas en a fait (c'est sûr, il faut être au courant).
Mais tu n'aideras pas ExtGraph: tu es bien trop attaché à ta petite lib propriétaire !

Thibaut: tu as optimisé GX_DrawStr depuis la version du 18 août ?

quel interet de rajouter du clipping à Extgraph pour TiMad ? il voulait sa propre lib, en ASM, donc bcp plus rapide qu'Extgraph, c tt.

Pendant que j'y suis, et avant de me faire insulter encore alors que ça n'était pas vraiment mon but:
Je rends la phrase "Mais tu n'aideras pas ExtGraph: tu es bien trop attaché à ta petite lib propriétaire !"
moins équivoque:
"Mais tu n'aideras pas ExtGraph: tu es bien trop attaché à ta petite lib chérie propriétaire !"

Je ne voulais pas dire que XLib était une petite librairie (un truc minable), car ce n'est pas vrai: elle n'est petite ni par la taille ni par les fonctions...


Thibaut: tu es sûr que tu ne pourrais pas optimiser ? Sous quel format sont stockés tes sprites de police (2 lignes de 4 pixels par octet, ou une seule) ?
Tu te demandes peut-être pourquoi je t'embête avec l'optimisation de GX_DrawStr... C'est parce que j'ai fait un bench avec un copain (qui programme lui aussi), j'ai montré le source de ce bench à Joël et à Kevin (c'est tout bête, une boucle qui affiche 1000 ou 2000 fois la même chaîne de caractères au même endroit de l'écran et qui mesure le temps avec un countup timer). Il en ressort que GX_DrawStr est distancée par les routines de TICT (dont le source est public).
Il reste néanmoins que les deux routines sont au moins 8 fois plus rapides que celles d'AMS, sous AMS 2.xx...

lol, cette réponse me fait penser à kevin qui dit que les routines de sprite Extgraph sont presque aussi rapides que celles de Gen

Donc TinyX est okus rapide que que GX pour afficher les chaines de caractères

XDanger : tu as comparé ce qui est comparable au moins ? c'est à dire que tu as bien comparé la fonction de GraphX avec la fonction correspondante de la TICT ?

GRRRRRRRRRRRRRRRRRRRRRrrrrrrrrrrr...

Je vois pas pourquoi je perdrai mon temps avec extgraphlib

D'ailleur meme en C on peu fire plus rapide que X/gen/GX... il suffit de connaitre le bon algo
De toute maniere c'est pas dans la mentalité de la tict et tigcc team (enfin il me semble qu'elles se sont paxées ces 2 teams).

Pour finir: pouet pouet, meuh meuh et camember

>> il me semble qu'elles se sont paxées ces 2 teams

Je le crois aussi. Mais en France nous sommes aussi tous pacsés, puisque toutes les équipes se retrouvent sur ce forum

lol

ZLib rulez!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

héhé

Apres ca toutes les autres lib seront obsoletes
D'ailleur elle serat programmé en C

C'est une TIGCClib n°2 optimisée en vitesse ?

Non... pas du tout pour moi extgraphli = ams
enfin pour la faire tourné, il faudra plus de 120 Ko de ram

Ha oué d'accord, il ne restera plus rien pour le programme vu qu'il faut aussi le compter dans la RAM prise (relocation en RAM des progs)

Bon courrage

En fait tout depend ...
par exemple fsbomber et plus gourmant encore
et dans les 120 Ko, ca compte l'extraxtion des gfx

120 ko ?
houla ! ça fait bcp !

j'en suis à 70ko pour KII, en comptant les Vscreen (Gplan et autres), les gfx...
(pas compté le relogement du prog là dedans)

TiMad
a écrit : De toute maniere c'est pas dans la mentalité de la tict et tigcc team (enfin il me semble qu'elles se sont paxées ces 2 teams).

On reste 2 équipes séparées, même s'il y a un esprit de collaboration entre les 2 équipes (nous partageons un forum, et Thomas et Lionel ont fait certaines contributions à TIGCC).

Voici le bench, que Joël et Kevin connaissent.
(L'émulation de FiftyMsecTick sur AMS 1.xx n'est pas postée, pas plus que le source de la routine de TICT qui de toute façon est public).

void _main(void)
{
unsigned short i=0;
unsigned long t1,t2;

ClrScr();

OldInt5 = GetIntVec (AUTO_INT_5);
SetIntVec (AUTO_INT_5, MyInt5);

OSSetSR(0x0400);
t1=FiftyMsecTick;
for(i=0;i<1000;i++)
{
__DrawLittleString__(0,0,"ABCDEFGHIJ0123456789",LCD_MEM);
// __DrawString__(0,0,"ABCDEFGHIJ0123456789",LCD_MEM,F_4x6); // Version moins optimisée qui gère les trois polices, mais cette version reste plus
// rapide que GX_DrawStr (33 ticks environ)...
}
t2=FiftyMsecTick;
printf_xy(0,10,"%lu",t2-t1); // 30 ticks environ

OSSetSR(0x0400);
t1=FiftyMsecTick;
for(i=0;i<1000;i++)
{
GX_DrawStr(LCD_MEM,0,20,"ABCDEFGHIJ0123456789",FALSE);
}
t2=FiftyMsecTick;
printf_xy(0,30,"%lu",t2-t1); // 42 ticks environ

short f=FontGetSys();
FontSetSys(F_4x6);
OSSetSR(0x0400);
t1=FiftyMsecTick;
for(i=0;i<1000;i++)
{
DrawStr(0,40,"ABCDEFGHIJ0123456789",A_NORMAL);
}
t2=FiftyMsecTick;
printf_xy(0,50,"%lu",t2-t1); // 380 ticks environ

FontSetSys(f);

GKeyIn(NULL,0);

SetIntVec (AUTO_INT_5, OldInt5);
GKeyFlush ();
}

Et tu n'as pas répondu à ma question: "Sous quel format sont stockés tes sprites de police (2 lignes de 4 pixels par octet, ou une seule) ?"
J'aimerais en savoir un peu plus sur tes fonctions, ça serait sympa de ta part de me répondre pour que je n'aie pas à passer du temps à désassembler le programme.

ca prend 30 seconde a dasm.. et 20 second a lancer une recherche sur un or ...

squale92: 120Ko c'est avec les gfx extrait (environs 190 sprite 16x16 en GT..).
Donc je pense que c'est raisonable et la rapidité est plutot bonne

190 sprt en GT...
faudrait que je compte combien en demande KII

bein disons que il faut mettre ses sprites dans un fichier externe et ne charger que ceux qui sont necessaire pour le niveau!

En fait je vais utiliser une methode de prechifting.
faut compter un peu pres 672 octets par sprite + 10 Ko de lib.
Mais c'est faisable. d'ailleur fzbomber utilise cette technique (voir ptetre encore plus bourin ...
Mais bon 150 sprites c'est deja beaucoup.. et dans un jeu d'action (car dans les rpg.. Xlib suffit largement) c'est enorme.

bein disons que il faut mettre ses sprites dans un fichier externe et ne charger que ceux qui sont necessaire pour le niveau!

Tiu crois que je fais quoi ?

tout charger en RAM, même ce qui est pas nécessaire, c pas vraiment le top !
(je le sais, car c'est ce que je faisait dans K1 )

XDanger : qu'est-ce que ça peut te faire ? je stocke ma font comme je veux pour ma routine

héhé thibaut (bien répondu)

Squale92>ben tu comme moa pour kirby!!
Les données dans des lib read only et non compressé!
Tu gagne de la ram de cette facon!
Petite question!
Le format DLL est tres bien mais on pourrait pousser le systeme un peu plus loin!
Comme le dit kevin,Les DLL nes sont pas concu pour des appels frequents et tu es obliger de la charger entiere en ram!
Mais une autre solutions est possible (je bosse dessus)
On ne charge les que les fonction necessaire!Et on les decharge quand on juge qu'il faut les decharger!
Du genre on alloue un tableau de pointeur intialement a NULL
Chaque pointeur est une fonction!
Si le pointeur est a NULL le fonction n'a pas encore été chargé et il faut la charger!
Sinon ben elle est chargé et utilisable!
etc..
Il est vrai que programmer avec ce systeme ajoute une contrainte de plus mais je le trouve innovateur et en reflechissant bien un peu on peut obtenir kelkechose de correcte et même utilisable avec des appels frequent (la on charge la fonction frequemment utilisé et on la decharge qu'a la fin du programme)
Kevin qu'en pense tu!
Je vais essayer de l'implementer!!!!