DrawPix optimisé - Page 2

Nerick a écrit :
le bit à allumer, c'est bien 7 - (x & 7)... je ne vois pas pourquoi not.b x donnerait ce résultat (même si effectivement ça marche ).

7-(x&7) <=> ~(x%8).
Mais comme le bset fait automatiquement un modulo 8, ce n'est pas la peine de la faire, tu peux te limiter au not.

Tiens c'est bizarre elle me rappelle quelque chose cette routine de pixel

XDanger: oué, mais bon, une MACRO c vite chiant quand mm, faut mieux utiliser une fonction je trouve ... surtout qu'avec des fonctions optimisées, on s'approche de la rapidité de la macro

jackiechan> merci

héhé

> surtout qu'avec des fonctions optimisées, on s'approche de la rapidité de la macro
En effet.
Mais si on utilise une fonction non inlinée, il y a l'overhead du jsr ou bsr et du rts. C'est à dire que c'est à la fois plus gros et plus lent, si la fonction n'est pas inlinée.
Si on veut la vitesse maximum et qu'on se fiche de la taille, on inline (dans la limite d'un certain nombre de SetPixel, quand même)...
Mais ça fait peu de différence avec une macro qui peut, elle, être optimisée si les paramètres sont constants...

On peut utiliser __builtin_constant_p, c'est fait pour ça...

> On peut utiliser __builtin_constant_p, c'est fait pour ça...
En effet. Mais à ce moment-là, quelle est la différence avec une macro ?

Et est-ce que c'est supporté par GTC ? Parce que c'est utile...
Mais c'est vrai que des choses utiles ne sont pas / ne sont pas encore supportées par GTC...

[Attention, mon but n'est pas de lancer un débat GTC/TIGCC ici].

> En effet. Mais à ce moment-là, quelle est la différence avec une macro ?
Je veux dire pour définir une macro de pixel, on peut tester si les coord sont constantes (ou l'une des deux), et alors inliner l'appel avec une macro, et si elles ne sont pas constantes, on peut utiliser la fonction "classique"

> Et est-ce que c'est supporté par GTC ? Parce que c'est utile...
Oui oui ("Other built-in functions")