Bon, c'est parti pour un topic de merde, mais là j'en ai marre de ne pas répondre (c'était pour éviter ce genre de débat stérile).
trust
:
ouai super malin je te donne la reponse a ton topic et tu me kikes merci! (super mentalité..)
Tu ne donnes absolument aucune réponse :
si Xlib l'utilise c'est que c'est justifié 
remaruqé, reprennez directement les fonctions d'XLib c'est plus rapide
Il n'y a aucun élément de réponse à ma question de départ. Et tu le sais très bien.
bon pour ce qui est du 8x8 je le repete encore une fois:
1 fonction 8x8 ca prend de la place
Oui, elle prend de la place, mais ta fonction 16x16 prend aussi de la place. Si on veut permettre à des utilisateurs d'utiliser des sprites de 8 pixels de large on doit réécrire les fonctions pour le permettre. Donc ça prend de la place, mais on peut tout à fait faire ce que tu fais avec Xlib avec ExtGraph, donc on ne prend pas du tout plus de place qu'Xlib.
2 c'est plus lent que du 16x8
OK, ça c'est vrai.
apres le gas il a 50 sprites 8x8 ca fait 400 octet de perdu en XSmall si il enregistre comme un barbar en XSmall dans son prog (il peut le transformer en ram)
Oui, il peut, mais ça prendra toujours moins de place d'utiliser un vrai format 8x8 avec de vraies fonctions qui vont avec.
donc je perd 400 octets, mais j'utilise la meme fonction que 16x16 donc a la fin je perd sizeof(fonction8x8)-400 oc ce qui est >> 0 dans XLib donc tout benef, gain en place et gain en rapidité.
OK, mais on peut tout à fait faire pareil avec ExtGraph.
Et par exemple, dans le cas où un utilisateur n'a que des sprites 8x8 ça prendra moins de place d'utiliser le vrai format de sprite 8x8 et la routine 8x que d'utiliser la routine 16x avec le format 16x8.
sur ce je vais rien apporté a ce topic puisqu'on ma kiker, et j'aime pas les gas qui disent des conneries alors qu'ils ont prog que 2 / 3 routines graphique!
N'importe quoi.
parce que sur tigcc il y en aurait long niveau critique alors stp ne lance pas des arguments comme ca.
Tu viens de lancer exactement le même argument que celui que tu lui reproches...
de plus tu sais tres bien que la routine de EXTGRAPHLIB est au MINIMUM 30 % plus lente que Xlib (les shift c'est pas pour les chiens...). et que je pourais augmenter encore plus ce pourcentage et ce sans derouler les boucles.
Mais bien sûr... Sans prendre de place en plus. Tu es trop fort. Juste une question : pourquoi tu ne le fais pas alors ?
deja une lib graphique c'est pas qu'un simple mode XOR et mask , ya les transparence derriere, et le clipping
Tout ça est fait.
mais faut voir aussi que tes aguments se contredisent suivant les debats... je cherche a gagner 2 octet sur une fonction mais j'en pert 100 pour refuser une idee qui me plait pas...
Où est-ce qu'on en perd 100 ? J'ai l'impression que ton "argument" est totalement injustifié, comme à ton habitude.
XPic XSprite XSmalll XLong (nouveau format) out ca c'est gerer par une meme sous fonction.. donc le gain de place est enorme, meme si les boucle sont deroulé 1 fois.
Déjà, tes boucles sont déroulées 4 fois, ne mens pas. En plus, ça ne veut rien dire, dérouler 1 fois...
Ensuite, si tous ces formats sont gérés par la même sous-fonction, c'est qu'ils utilisent la même largeur de sprite, donc avec ExtGraph, ce serait pareil, on utiliserait non pas la même sous-fonction, mais la même fonction. Sauf pour le XPic, c'est vrai.
Donc tu n'as aucun gain de place... C'est tout à fait normal que ces formats soient gérés par les mêmes sous-fonctions.
et peut etre que votre routine est optimisé au cycle pres niveau ecriutre, niveau algo elle vaux 0. et cela a cause de la mentalité que vous voulez adopter pour cette lib.
Ben justement, puisqu'on ne veut pas se permettre de dérouler ou de faire deux boucles différentes pour optimiser le shifting, on est obligé d'améliorer l'algo. C'est ce qu'on essaie de faire en tout cas, je ne dis pas que c'est le cas, et que les algos de nos fonctions sont ce qu'il y a de plus rapide, mais je voulais dire que notre mentalité ne nous empêche pas d'avoir de bons algos, au contraire.
Ou alors on n'a pas la même notion d'algo.
au fait la taille de votre lib archive montre bien que niveau place c'est tres gourmand!
Quelle mauvaise foi.
Oui, c'est gourmand ! Mais c'est une lib statique je te rappelle.
Et le fait de proposer plusieurs fonctions permet d'augmenter la flexibilité de la lib, il y a une fonction pour chaque cas de figure d'utilisation. Donc chaque utilisateur n'utilisera guère plus de 2-3 fonctions, selon ses besoins.
Tu viens de lancer exactement le même argument que celui que tu lui reproches...
Je ne comprends pas ce que tu as voulu dire.
