Pollux
: A votre place, je ferais du code auto-modifiant pour pas avoir à me trimballer toutes les fonctions AND, XOR & co (et, à la rigueur, tout supprimer pour ne garder que OR+AND+XOR pour le noir & blanc, MASK et BLIT pour les grays). Et puis ne plus supporter que Sprite8/Sprite16/SpriteNx16... (on peut passer de 8 à 16 par un simple patch) Bien sûr, ça demande un changement de l'API...

Mais j'ai peur que le linking conditionnel à l'utilisation réelle va en souffrir. Comme Sasume l'a déjà dit, le code auto-modifiant et les librairies statiques ne vont pas bien ensemble. Et puis ça sera aussi un problème pour l'intégration à TIGCCLIB, parce que Zeljko veut le moins de code automodifiant possible (il trouve que c'est sale, et il n'a pas tout à fait tort). (Cela dit, j'ai déjà réussi à faire rentrer plusieurs fonctions automodifiantes sans me faire attraper. Heureusement que Zeljko a autre chose à faire que contrôler tous les ajouts à TIGCCLIB, sinon il m'aurait déjà gueulé dessus. )

Et en plus, ça sensibilise l'utilisateur de la lib au fait que les puissances de 2 (ou à la rigueur puissance de 2 fois 3), c'est Bien, alors autant en profiter

L'utilisateur utilise ce qu'il veut! C'est ça le but d'une librairie flexible: c'est à la librairie de s'adapter à son utilisateur, pas l'inverse!