Comme je l'ai écrit plus haut, l'inconvénient de la méthode avec l'union Color telle que je l'avais décrite est qu'il faut mettre les couleurs sur 5 ou 6 bits, ce qui est donc moins pratique, et aussi (potentiellement) que l'endianness pourrait interférer avec ce qu'on veut faire (je n'ai pas vérifié ce deuxième point).
C'est pour ça que je n'ai pas suggéré de nouveau cette méthode dans mon précédent post, qui faisait suite à un post où tu utilisais des couleurs 8 bits
Est-ce que tes routines sont clippées (= n'écrivent pas en-dehors de l'écran) ? C'est plutôt plus facile à faire avec 16 bpp qu'avec 4 bpp. EDIT: oui, la plupart des routines sont clippées par setPixel.
EDIT: attention, avec des tests CX / non CX dans setPixel, qui peut potentiellement être appelée des milliers de fois, toutes tes routines seront lentes
A la relecture de ta liste dans le premier post, et en admettant qu'on utilise le même vocabulaire, il me semble qu'il y a un manque important: les routines de sprite
Les routines de tile sont un cas particulier des routines de sprite, où les valeurs de x et y sont multiples de 8; les routines de sprite n'ont pas cette contrainte. Sans routines de sprite, entre bien d'autres programmes qui sont impossibles, pas de jeux de plate-forme à la Mario.
Là encore, c'est plus facile à faire avec 16 bpp qu'avec 4 bpp, d'autant plus que les contraintes d'alignement sont plus désagréables sur ARM que sur 68000.
Il est important de prévoir une suite de tests dès le début d'une librairie. ExtGraph n'en a pas vraiment eu jusqu'à devenir monstrueuse, et bien que la création tardive de code de tests m'ait permis de corriger un certain nombre de bêtises, la couverture de tests reste (et restera) assez basse...