Pb avec Genlib... - Page 5

Comment il faudrait faire alors pour avoir un bench correct. Parce que franchement ça m'intéresse.
Tu veux que je porte ma routine pour qu'elle écrive sur deux plans ?

mon bench me disait que genlib affichait les lignes en niv de gris 3x + vite qu'extgraph.
(Cf bench sur http://www.timetoteam.fr.st)

Mais est-ce que la fonction gl_draw_bwhline_b n'est pas équivalente à celle d'extgraph ?

Vertyos
a écrit : Voilà un jeu qui utilise les fonctions de transparence de XLib, y'a une différence notable au niveau des couleurs ? Pas la peine de tourner autours du pot je peux donner la réponse : non.

Parce que tes sprites sont des personnages vus de dessus, ce qui fait qu'il n'y a pas de parties claires visibles.

PpHd
a écrit : Non regarde les chiffres. C'est encore le bench biaise !

Comment t'expliques-tu alors que genlib soit passé de 8470 à 9450?

Kevin Kofler
a écrit : Parce que tes sprites sont des personnages vus de dessus, ce qui fait qu'il n'y a pas de parties claires visibles.

Tu veux dire qu'il n'y a pas de "blanc" dessus... Mais j'aurais pu en mettre aussi, il suffit de changer la couleur de transparence

Mais avec des personnages vus de face, les couleurs sont plus variées, donc on voit nettement la différence quand tu n'en utilises que 3 (quelles qu'elles soient). Et puis, les sprites sont en général plus grands pour des personnages vus de face (x×2x plutôt que x×x), ce qui fait que la différence est visible plus nettement.

de toutes façons kevin tu parles de qqch que tu ne connais puisque tu ne sais pas faire de jeux à part des jeux de société, dc tu ne te rends pas compte des pb rencontrés

et paaann!

c'est clair.. vu comme l'ecran est baveux, t'as qu'a regarder un jeu qui tourne a 40 fps avec annimation et si tu vois la differences entre 4 et 3 niveau de gris, et bien c'est que t'as fumé ta beuze!

le nombre total de ndg que nous offre genereusement l'ecran avec son magnifique motion-blur integre d'origine () doit etre bien superieur a ce que revait de faire NSPIRIT (il av fait un truc soit disant en 16 ndg, ms ca clignottait a mort )
bon, ok qd RIEN ne bouge, ca se voit, ms generalement:
1/ les persos sont animes, dc ---> motion blur
2/ pour la map, pareil, a moins de s'asseoir pendant 5 min sans rien faire a regarder le decor
3/ pour les dialogues, heu moi je les lis, je cherche pas combien de ndg a le jeu
4/ genlib c bien
(xlib aussi )
(extgraph par conre... )

PpHd> Je réitère ma question pour que tu ne l'oublies pas : gl_draw_bwhline_b n'est-elle pas complètement équivalente à la fonction d'extgraph ?

Et puis aussi, il faudrait voir la source du bench.

jackiechan
a écrit : PpHd> Je réitère ma question pour que tu ne l'oublies pas : gl_bwdrawhline_b n'est-elle pas complètement équivalente à la fonction d'extgraph ?

Presque. Il y a le clipping en plus.

Et au cas où vous ne l'ayez pas remarqué, le message #131 n'est pas de moi.

Ça doit faire 4 tests, quand même, le clipping....
Je vais modifier ma fonction afin de gérer le clipping et je bencherai.

[edit]:en fait, mon astuce pour n'avoir que 4 tests ne marche pas, ça en fait 6

Bon, d'après vti (le prog plante sur ma TI ) :
ExtGraph clippé : 2964 TU (Time Unit)
gl_draw_bwhline_b : 2904 TU (+2
Genlib est en effet plus rapide, mais pas de beaucoup : 2%.
(i=240;i--;) HLineC_OR(i,0,j,LCD_MEM);

[nosmile]voici en gros le style du bench : 	for(k=10;k--;)
		for(j=128;j--;)
			for

attend vti ne respete pas du tout les cycles...

Bon, j'ai corrigé le prog (erreur bête de ma part) et il se lance correctement sur ma TI-89.
Donc le résultat est :
Genlib : 2055 TU
ExtGraph (modifiée) : 2215 TU

Donc genlib est finalement 7% plus rapide que la fonction modifiée d'extgraph pour gérer le clipping.

As-tu mis un clipping vertical? Si oui, vire-le, il ne sert à rien pour une ligne horizontale. Il vaut mieux mettre le test en macro, comme ça GCC pourra le virer en optimisant.

Oui, j'ai mis un clipping vertical et je ne pense pas que ce soit inutile.
Au fait, sans le clipping, je suis quand même 12% plus rapide que genlib .
Si tu veux, j'ai fait un test sans clipping vertical :
Genlib : 2059 TU
ExtGraph (modif) : 2094 TU
Donc Genlib serait 1.7% plus rapide qu'extgraph mais il faut voir si PpHd a lui aussi omis le clipping vertical.

Au fait, j'ai relu la source et je pense qu'avec un bon brainstorming on pourrait optimiser la fonction d'extgraph, c'était une des premières fonctions que j'avais écrites en ASM pur (XDanger m'avait aidé aussi).

Genlib gere le clipping vertical.

> Genlib gere le clipping vertical.
A ce moment-là, il faut le laisser dans ExtGraph...

jackiechan: quelles idées as-tu, toi, pour optimiser la fonction de dessin de lignes horizontale ? Je pense à l'instant à une à base de jmp 2(pc,dn.w) où la table à 2(pc) contiendrait les adresses de la sous-routine OR, celle de la routine EOR et celle de la routine AND. Mais rien ne dit que c'est fin...

> Il vaut mieux mettre le test en macro, comme ça GCC pourra le virer en optimisant.
Pourrais-tu donner le code qui le fait, Kevin ? Je n'ai pas réussi à faire une telle chose pour une macro que j'ai faite il y a plusieurs mois pour les fonts (les noms ne sont plus comme ça...). Ca vient peut-être du fait que le {...} est utilisé ?
#define _FastLittleString(x,y,s,p,m) \
({ if (m==A_NORMAL) _DrawLittleString(x,y,s,p); \
else if (m==A_XOR) _InvertLittleString(x,y,s,p); \
else if (m==A_REVERSE) _ReverseLittleString(x,y,s,p); \
else if (m==A_REPLACE) _ReplaceLittleString(x,y,s,p);})

XDanger a écrit :
> Genlib gere le clipping vertical. A ce moment-là, il faut le laisser dans ExtGraph...

Je l'ai remis. De toute façon, même si il n'était pas dans Genlib, je trouve plus prudent de le laisser quand même.
Au pire, on peut encore faire des versions différentes : une avec le clip. horizontal seulement et une autre avec le clip. vertical et horizontal...
Enfin, ça va devenir lourd peut-être...

jackiechan: quelles idées as-tu, toi, pour optimiser la fonction de dessin de lignes horizontale ? Je pense à l'instant à une à base de jmp 2(pc,dn.w) où la table à 2(pc) contiendrait les adresses de la sous-routine OR, celle de la routine EOR et celle de la routine AND. Mais rien ne dit que c'est fin...

Je n'ai pas vraiment d'idée précise, mais j'ai l'impression qu'on peut améliorer l'implémentation (j'ai regardé le code l'autre jour et j'ai eu l'impression qu'il pouvait être optimisé, mais je ne me suis pas vraiment attardé dessus).
Sinon, pour ton idée, je ne sais pas si ce sera vraiment plus rapide que ce qu'on fait actuellement et en plus, si j'ai bien compris ton idée, le comportement serait complètement indéterminé si on passe un argument MODE incorrect.

> Enfin, ça va devenir lourd peut-être...
Très lourd... Ceux qui critiquent déjà bien trop comme ça, seraient très contents si le truc était très complexe et qu'on nous le fasse remarquer...

> si j'ai bien compris ton idée, le comportement serait complètement indéterminé si on passe un argument MODE incorrect.
Si on ne fait pas attention, bien sûr. Mais on peut choisir arbitrairement que A_REVERSE = A_REVERSE, A_XOR = A_XOR et tout le reste A_NORMAL (ce qui permet ceci dit en passant de gérer A_REPLACE et A_OR), ce qui peut être fait en quelques instructions. C'est déjà fait dans FastFilledRect et FastDrawVLine.

Ben je n'ai pas du comprendre ton idée, alors.
Si on met 12 comme paramètre mode, il se passe quoi ?

Si mode est supérieur ou égal à trois (puisque A_REVERSE = 0, A_NORMAL = 1, A_XOR = 2), on transforme le mode en A_NORMAL... 12 sera transformé en A_NORMAL.

XDanger a écrit :
> Genlib gere le clipping vertical. A ce moment-là, il faut le laisser dans ExtGraph...

Pourquoi pas le mettre en macro? Comme ça GCC le virera lors de l'optimisation quand il ne sert pas.

> Il vaut mieux mettre le test en macro, comme ça GCC pourra le virer en optimisant. Pourrais-tu donner le code qui le fait, Kevin ?

#define HLine_OR_hvclip(y,x1,x2,p) ({short __y=(y);if (__y>=0&&__y<128) HLine_OR_hclip(__y,(x1),(x2),(p));})

Je n'ai pas réussi à faire une telle chose pour une macro que j'ai faite il y a plusieurs mois pour les fonts (les noms ne sont plus comme ça...). Ca vient peut-être du fait que le {...} est utilisé ?
#define _FastLittleString(x,y,s,p,m) \
({ if (m==A_NORMAL) _DrawLittleString(x,y,s,p); \
else if (m==A_XOR) _InvertLittleString(x,y,s,p); \
else if (m==A_REVERSE) _ReverseLittleString(x,y,s,p); \ else if (m==A_REPLACE) _ReplaceLittleString(x,y,s,p);})

Hmmm, bizarre. Il devrait vraiment optimiser ça en fonction de la valeur de m. Essaye avec un switch ou avec des ?:.

> Pourquoi pas le mettre en macro? Comme ça GCC le virera lors de l'optimisation quand il ne sert pas.
Bonne idée. La macro ne sera pas accessible dans un programme en ASM pur, mais qui programme en ASM pur avec ExtGraph ?

> #define HLine_OR_hvclip(y,x1,x2,p) ({short __y=(y);if (__y>=0&&__y<128) HLine_OR_hclip(__y,(x1),(x2),(p));})
OK.

> Hmmm, bizarre. Il devrait vraiment optimiser ça en fonction de la valeur de m. Essaye avec un switch ou avec des ?:.
OK, j'essaierai. J'utilise TIGCC 0.94 Beta 20, mais ça ne vient certainement pas de là...

XDanger
a écrit : mais qui programme en ASM pur avec ExtGraph ?

Si tu penses vraiment que personne ne programme en ASM pur avec ExtGraph, ce n'est pas la peine de garder le mode __stkparm__ "pour la compatibilité".

> #define HLine_OR_hvclip(y,x1,x2,p) ({short __y=(y);if (__y>=0&&__y<128) HLine_OR_hclip(__y,(x1),(x2),(p));}) OK.

Dans quel cas GCC sera suffisemment doué pour se rendre compte que la macro est inutile ??? (À part si on l'appelle avec des valeurs immédiates)

> À part si on l'appelle avec des valeurs immédiates
Je crois qu'il n'y a que ce cas-là.

> Si tu penses vraiment que personne ne programme en ASM pur avec ExtGraph, ce n'est pas la peine de garder le mode __stkparm__ "pour la compatibilité".
Si, parce que ça pourrait aussi (éventuellement) breaker des programmes en C. J'avais essayé de mettre -mregparm dans les options de compilation de TIGCC, ça ne marchait pas du tout (crash presque immédiat). C'était il y a quelques mois. Je ne sais plus quelle version de TIGCC 0.94 j'utilisais.